Improve performance of placing placeholder

[Ben3eeE]

Since atom/tree-view#525 is using code from the tabs package for placing the placeholder stealing the ideas from @BinaryMuse in atom/tree-view#525 (comment) seems to also work for tabs when there are many tabs open.

Before:

After:

To note is that the placeholder doesn't get removed when leaving the tab bar because of the change in the onDragLeave event also stolen from the tree-view PR.

Which is strange when dragging tabs to other panes:

[damir]

Can someone merge this? Dragging tabs is really slow and annoying.
Thank you.

[winstliu]

@Ben3eeE I believe I fixed the placeholder-not-disappearing issue you were experiencing. The entry.target is entry.currentTarget line you added isn't present in the Tree View PR and that check would always return true anyways except when dragging outside of the tab bar, serving no real benefit.

[Ben3eeE]

I believe I fixed the placeholder-not-disappearing issue you were experiencing.

Amazing 😍

The entry.target is entry.currentTarget line you added isn't present in the Tree View PR and that check would always return true anyways except when dragging outside of the tab bar, serving no real benefit.

Huh, I'm sure I didn't add anything when opening this. I must have been really confused if I did 😀

Edit: It is part of the original PR? https://github.com/atom/tree-view/pull/525/files#diff-22e094e871c347ed2946550500ecec83R56

And exists for this case:

On master doing ☝️ doesn't remove the placeholder.

[winstliu]

Ah you're right, I was only looking at the one comment's patch by accident.

[Ben3eeE]

I did the same thing and was confused why I had added the extra case 😀

[winstliu]

☝️ fixes most issues but I just encountered another one that I'm working on fixing.

[winstliu]

Looks like the resize handle is causing a dragleave event to be fired before the drag goes outside the tab bar since it's ~8px wide. What I would give for an event that fires when the element goes outside the area where the event handler is.

[ha404]

Any progress on this? It's been excruciating moving tabs around.

What I would give for an event that fires when the element goes outside the area where the event handler is.

Something like mouseleave? https://developer.mozilla.org/en-US/docs/Web/Events/mouseleave

[winstliu]

Ooh, that looks like it has potential. Thanks!

[ha404]

@50Wliu I should've read more into your actual problem. It looks like you need to use event.stopPropagation so that your events don't bubble up and trigger other events. This could be somewhat related: https://stackoverflow.com/questions/15902920/resizing-an-element-triggers-the-resize-event-of-the-window

[ha404]

You might want to do event.stopPropagation() here?

[winstliu]

dragLeave is uncancelable.

[winstliu]

@ha404 so yes, mouseleave is exactly what I need. The problem, of course, is that it doesn't get fired when a drag-and-drop operation is in progress. I discovered that in #523.

[winstliu]

I have a hunch that the relatedTarget attribute will be able to solve this problem as it refers to the new (current) target. Unfortunately, relatedTarget was always null until Chrome 60 (bug report). Atom is currently using Chrome 56, and the most recent stable Electron version (1.7.x) is using Chrome 58. Electron 1.8 beta is using Chrome 59. The update to Chrome 60 was skipped in favor of Chrome 61. Therefore it might take quite a while for Atom to pick up the required Chrome version 😕.

[zinkkrysty]

Any news on this? The sluggish drag and drop of tabs is extremely annoying. (in my case, the delay is about 5-10 seconds so my editor gets frozen for that amount of time!)

[Ben3eeE]

@zinkkrysty No news. This is still blocked #390 (comment)

[hansonw]

Bump - this seems like a pretty high-profile issue (and makes Atom look bad when it comes to performance). Is there an issue that doesn't require an Electron upgrade? It sounds like that would be several months out :(

[winstliu]

Ok, I think this should work. Requires at least Atom 1.27.0-dev-c5dea46ac or higher.

[Ben3eeE]

@50Wliu LGTM

[diaswrd]

Oh my god, this problem was triggering me in so many levels and for so long... @Ben3eeE THANK YOU!

[amilner42]

Did this get broken again? I'm on this version:

And moving tabs is brutally slow. Can give more information if I'm the only one experiencing this.

Edit: Disabled all community packages, no help.

Will reinstall Atom and post if that fixes it in this comment.

[bblack]

@amilner42 same here.

I'm experiencing this slowness on
atom 1.50.0
electron 5.0.13
chrome 73.0.3683.121
node v12.0.0

Quitting then opening in safe mode, the slowness goes away.

Quitting from safe mode, then opening normally, the slowness is still gone. So maybe the problem worsens the longer Atom is open?