This seems a little counterintuitive. How could a dragenter event fire
if nothing's being dragged? Well, if something's dragged into the
document (i.e. from the desktop or another window), a dragenter event
will be fired even though (as far as we're concerned), nothing is being
dragged. Rather than trying to handle this class of events specially in
the dock, we simply limit our listening to when something is being
dragged. Since we have a single source of truth for this information,
this should be resilient to future changes in logic.
This fixes#16769, which described an issue whereby trying to drop into
a closed dock would cause the dock to repeatedly open and close.
I tried to describe in comments why this was happening and how we can
make sure to avoid it.
The solution adds another DOM measurement which I'm not too thrilled
about but I profiled and it didn't seem to be an issue.
Previously, we would assign dock elements a minimum width/height of 2
pixels so that we could detect when the mouse approached the edge of a
hidden dock in order to show the chevron buttons. This, however, was
causing confusion for users, who expected that extra space to be
clickable in order to scroll editors located in the center dock.
With this commit we will instead register a global `mousemove` event on
the window right when attaching the workspace element to the DOM (the
event handler is debounced, so this shouldn't have any performance
consequence). Then, when mouse moves, we will programmatically detect
when it is approaching to the edge of a dock and show the chevron button
accordingly. This allows us to remove the `min-width` property from the
dock container element, which eliminates the confusing behavior
described above.
We're updating Atom to disallow editors in docks. As a result, we need
to remove Dock::getTextEditors(). Normally, we would deprecate a method
before removing it, but this method is broken and has never worked:
atom.workspace.getLeftDock().getTextEditors()
(unknown) Uncaught TypeError: this.paneContainer.getTextEditors is not a function
at Dock.getTextEditors (/Applications/Atom.app/Contents/Resources/app/src/dock.js:590:37)
at <anonymous>:1:30
Since the method is broken, we know that nobody is relying on it.
Instead of deprecating the method, we can just remove it.
We're updating Atom to disallow editors in docks. As a result, we need
to remove Dock::observeTextEditors(callback). Normally, we would
deprecate a method before removing it, but this method is broken and has
never worked:
atom.workspace.getLeftDock().observeTextEditors(console.log)
(unknown) Uncaught TypeError: this.paneContainer.getTextEditors is not a function
at Dock.getTextEditors (/Applications/Atom.app/Contents/Resources/app/src/dock.js:590:37)
at Dock.observeTextEditors (/Applications/Atom.app/Contents/Resources/app/src/dock.js:396:41)
at <anonymous>:1:30
getTextEditors @ <embedded>:29933
observeTextEditors @ <embedded>:29739
(anonymous) @ VM1941:1
Since the method is broken, we know that nobody is relying on it.
Instead of deprecating the method, we can just remove it.
Previously, we would get the initial size every time we didn't have an
explicit one. With this commit, we only get the initial size when we
deserialize and when we go from 0 -> 1 pane items.
Also, if the dock doesn't already have an explicit size, we'll use the
preferred size of the item being dragged when peaking the dock. That
way, dropping it won't cause it to change size.
Currently, the absolutely positioned element is the only thing with a
size. That means that it'll cover the center. With this change, we give
a size to the (relatively-positioned) atom-dock element so that closed
docks take up canvas space instead.
I think @simurai mentioned this problem before but I wasn't following
and then forgot about it. 😖
