After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 644642 - xdnd: Dragging item between workspaces in overview mode skips workspaces in the middle
xdnd: Dragging item between workspaces in overview mode skips workspaces in t...
Status: RESOLVED FIXED
Product: gnome-shell
Classification: Core
Component: general
2.91.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2011-03-13 14:33 UTC by MT
Modified: 2011-03-14 21:03 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
XDND: Fix dragMonitor leak in WorkspacesDisplay (2.23 KB, patch)
2011-03-13 18:53 UTC, drago01
needs-work Details | Review
XDND: Fix dragMonitor leak in WorkspacesDisplay (1.39 KB, patch)
2011-03-14 16:19 UTC, drago01
reviewed Details | Review
XDND: Fix dragMonitor leak in WorkspacesDisplay (1.51 KB, patch)
2011-03-14 20:48 UTC, drago01
committed Details | Review

Description MT 2011-03-13 14:33:14 UTC
I was trying out GNOME shell in the latest OpenSUSE Live CD (0.1.0). I tried to perform the task of dragging a piece of text in a window in workspace 1, taking it to the top-left corner to expose the activities overview, and then trying to drop it onto another window in workspace 2. I found that it was impossible to scroll and stop at the second workspace, instead, the view rapidly scrolled down to the last workspace. While dragging an object, I could only move between the first and last workspace, and found myself unable to stop at any workspace in between, which I believe is a bug.

I also found that trying to choose a workspace to drop to through the selector on the right of the screen only works if a part of a window is visible on the partly exposed workspace selector. While dragging an object over the workspace selector, the widget should expose itself completely.
Comment 1 Owen Taylor 2011-03-13 15:50:56 UTC
Reproduced both problems.
Comment 2 drago01 2011-03-13 18:53:23 UTC
Created attachment 183288 [details] [review]
XDND: Fix dragMonitor leak in WorkspacesDisplay

WorkspacesDisplay removes its dragMonitor in _dragEnd, but
this was never called in when a xdnd drag ended causing
dragMonitors to stack up and handling events multiple times.

Fix that by making sure that _dragEnd is called when xdnd ends.
Comment 3 drago01 2011-03-13 18:54:35 UTC
(In reply to comment #0)
> I was trying out GNOME shell in the latest OpenSUSE Live CD (0.1.0). I tried to
> perform the task of dragging a piece of text in a window in workspace 1, taking
> it to the top-left corner to expose the activities overview, and then trying to
> drop it onto another window in workspace 2. I found that it was impossible to
> scroll and stop at the second workspace, instead, the view rapidly scrolled
> down to the last workspace. While dragging an object, I could only move between
> the first and last workspace, and found myself unable to stop at any workspace
> in between, which I believe is a bug.

This one should be fixed by the attached patch.

> I also found that trying to choose a workspace to drop to through the selector
> on the right of the screen only works if a part of a window is visible on the
> partly exposed workspace selector. While dragging an object over the workspace
> selector, the widget should expose itself completely.

This should be fixed once we land the patch from 643945
Comment 4 Owen Taylor 2011-03-14 16:01:13 UTC
(In reply to comment #3)
> > I also found that trying to choose a workspace to drop to through the selector
> > on the right of the screen only works if a part of a window is visible on the
> > partly exposed workspace selector. While dragging an object over the workspace
> > selector, the widget should expose itself completely.
> 
> This should be fixed once we land the patch from 643945

Ah, forgot that hadn't landed.
Comment 5 Owen Taylor 2011-03-14 16:10:20 UTC
Review of attachment 183288 [details] [review]:

Hmm, not obvious to me

::: js/ui/overview.js
@@ +266,3 @@
                                                 this.hideTemporarily();
                                                 this._lastHoveredWindow = null;
+                                                this.endItemDrag(dragEvent.targetActor);

so in this case we emit item-drag-end

::: js/ui/workspacesView.js
@@ +109,3 @@
+
+        this._xdndDragEndId = Main.xdndHandler.connect('drag-end',
+                                                      Lang.bind(this, this._dragEnd));

Here we have paired connections to item-drag-begin/item-drag-end and window-drag-begin/window-drag-end - if xdnd shows up as item-drag-begin, shouldn't it uniformly show up as item-drag-end?
Comment 6 drago01 2011-03-14 16:19:16 UTC
(In reply to comment #5)
> Review of attachment 183288 [details] [review]:
> 
> Hmm, not obvious to me
> 
> ::: js/ui/overview.js
> @@ +266,3 @@
>                                                  this.hideTemporarily();
>                                                  this._lastHoveredWindow =
> null;
> +                                               
> this.endItemDrag(dragEvent.targetActor);
> 
> so in this case we emit item-drag-end
> 
> ::: js/ui/workspacesView.js
> @@ +109,3 @@
> +
> +        this._xdndDragEndId = Main.xdndHandler.connect('drag-end',
> +                                                      Lang.bind(this,
> this._dragEnd));
> 
> Here we have paired connections to item-drag-begin/item-drag-end and
> window-drag-begin/window-drag-end - if xdnd shows up as item-drag-begin,
> shouldn't it uniformly show up as item-drag-end?

Yeah makes sense.
Comment 7 drago01 2011-03-14 16:19:33 UTC
Created attachment 183354 [details] [review]
XDND: Fix dragMonitor leak in WorkspacesDisplay

WorkspacesDisplay removes its dragMonitor in _dragEnd, but
this was never called in when a xdnd drag ended causing
dragMonitors to stack up and handling events multiple times.

Fix that by making sure that _dragEnd is called when xdnd ends.
Comment 8 Owen Taylor 2011-03-14 20:35:13 UTC
Review of attachment 183354 [details] [review]:

::: js/ui/overview.js
@@ +267,3 @@
                                                 this.hideTemporarily();
                                                 this._lastHoveredWindow = null;
+                                                this.endItemDrag();

Why don't we drag-end from xdndHandler in this case? if we do, I don't think users should have to worry about unpaired item-drag-begin/item-drag-end calls - we should avoid doing item-begin-drag/item-end-drag/item-end-drag. If the issue is that Workspaces doesn't remove it's monitor if it's destroyed before item-drag-end is emitted, I think it would be cleanest to make it clean up properly if destroyed during a drag - if (_inDrag) this._dragEnd() or whatever.
Comment 9 drago01 2011-03-14 20:48:28 UTC
Created attachment 183384 [details] [review]
XDND: Fix dragMonitor leak in WorkspacesDisplay

WorkspacesDisplay removes its dragMonitor in _dragEnd, but
this was never called in when a xdnd drag ended causing
dragMonitors to stack up and handling events multiple times.

Fix that by making sure that _dragEnd is called when xdnd ends.

-----

(In reply to comment #8)
> Review of attachment 183354 [details] [review]:
> 
> ::: js/ui/overview.js
> @@ +267,3 @@
>                                                  this.hideTemporarily();
>                                                  this._lastHoveredWindow =
> null;
> +                                                this.endItemDrag();
> 
> Why don't we drag-end from xdndHandler in this case? if we do, I don't think
> users should have to worry about unpaired item-drag-begin/item-drag-end calls -
> we should avoid doing item-begin-drag/item-end-drag/item-end-drag. If the issue
> is that Workspaces doesn't remove it's monitor if it's destroyed before
> item-drag-end is emitted, I think it would be cleanest to make it clean up
> properly if destroyed during a drag - if (_inDrag) this._dragEnd() or whatever.

No reason ... and it makes sense to not emit "item-drag-end" twice.
Comment 10 Owen Taylor 2011-03-14 20:55:52 UTC
Review of attachment 183384 [details] [review]:

Looks good (I've assuming you've retested the original bug with the new revision)
Comment 11 drago01 2011-03-14 21:03:36 UTC
Attachment 183384 [details] pushed as 29d473f - XDND: Fix dragMonitor leak in WorkspacesDisplay