Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Temporary "drag" items don't get destroyed if not dropped #133

Closed
mattgodbolt opened this issue Sep 8, 2016 · 4 comments
Closed

Temporary "drag" items don't get destroyed if not dropped #133

mattgodbolt opened this issue Sep 8, 2016 · 4 comments

Comments

@mattgodbolt
Copy link
Contributor

I have a simple setup where I log when things are opened and closed. If I use an on("open") to register for events and match it with either on("close") or on("destroy") then for the temporary "drag" items I see an open, but no close or destroy.

I'm not seeing any close events (c.f. #106 ), but not even a destroy means I have zombie components hanging around causing trouble.

For example, if one edits the drag example codepen to put simple logging ( see https://codepen.io/mattgodbolt/pen/qadVZp ) :

container.on('open', function(){
    console.log(state.text + " was opened");
});
container.on('close', function(){
    console.log(state.text + " was closed");
});
container.on('destroy', function(){
    console.log(state.text + " was destroyed");
});

Open the codepen and then the JS console. Notice the opens for the existing panels are there. If you drag a new "You've added me!" over, you see the open, and if you drop it on the layout so it "sticks" you can close it and see a "close" event for it.

However, if you click and hold the "You've added me" text but then drop it right there (ie cancel the drag), you'll see no destroy or close event is emitted.

@mattgodbolt
Copy link
Contributor Author

Looks like the item is created in DragSource here when the drag begins, but if all the if checks fail in the onDrop call in DragProxy then no container "adopts" the item and it's leaked.

@mattgodbolt
Copy link
Contributor Author

the fix appears to be to add:

else this._contentItem._$destroy();

But I'll have to test some more

@mattgodbolt
Copy link
Contributor Author

That doesn't always work: I have a screen capture (attached)
Capture.zip which demonstrated some funky behaviour which might be further issues of this sort.

@mattgodbolt
Copy link
Contributor Author

With reference to my comment above: I realise that the capture is using an unpatched GoldenLayout and so is a separate issue, unrelated to this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant