495184 - current drag operation (dropEffect) is not updated while dragging outside the application

Status: VERIFIED FIXED

(Core :: Widget: Gtk, defect)

Description

[Karl Tomlinson (back June 29 :karlt)]

Linux version of bug 494795 (Mac) and bug 455884 (MS).

STR:

Create 3 tabs in Firefox, drag the center tab along the tab bar to the left or
right, release somewhere outside the browser that will not accept the drop.
(Task bar or another Firefox instance/process is a good candidate drop
location.)

Expected results: Tab is detached.
Actual results: Tab is not detached.

This results from not following step 2.4 for when "the current target element
is not a DOM element" in Section 7.10.4 here:

http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html#current-drag-operation

Comment 1

[Karl Tomlinson (back June 29 :karlt)]

Attachment: patch

The current drag operation for not-DOM-element targets is only used for
dragend events, so we need only calculate these current drag operations at
drag end.  This patch does that.

The situation for cancelled drags is also changed (as a side effect).

Previously the dropEffect for cancelled drags was the last DOM current drag
operation.  This patch makes the dropEffect during dragend for cancelled drags
"none" (even for when the current target element is a DOM element).

Strictly, according to the spec "if the user ended the drag-and-drop operation
by canceling it (e.g. by hitting the Escape key)" the current drag operation
would not be the drag operation from the last target element (DOM or not).

However, we may consider the behavior with this patch to be following the spec
if we think of the user pressing Esc as indicating a null user selection
(followed by a drag-and-drop cancel).  Also if "the drag operation failed",
then it would seem unusual to still have a non-"none" current drag operation.

I think the behavior in this patch is consistent (for dropEffect) with the
behavior of the code for MS Windows.

Comment 2

[Karl Tomlinson (back June 29 :karlt)]

Comment on attachment 380050 [details] [diff] [review]
patch

Is this wanted for 1.9.1(.0)?

Comment 3

[Mike Beltzner [:beltzner, not reading bugmail]]

Karl: so you're saying this makes it so that if I've dragged a tab outside of the browser, and haven't yet released the mouse button, pressing ESC will cancel the action?

Comment 4

[Karl Tomlinson (back June 29 :karlt)]

(In reply to comment #3)
> Karl: so you're saying this makes it so that if I've dragged a tab outside of
> the browser, and haven't yet released the mouse button, pressing ESC will
> cancel the action?

It will ensure the action is "none" (cancelling any current action) in this situation, but it doesn't set "mozUserCancelled" (bug 479995).
When action is "none" and "mozUserCancelled" is not set, tabs get torn off into new windows.

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+2]]

With this fixed we need to update https://litmus.mozilla.org/show_test.cgi?id=7578

Comment 6

[Karl Tomlinson (back June 29 :karlt)]

http://hg.mozilla.org/mozilla-central/rev/cbfafc498ae8

(Note that https://litmus.mozilla.org/show_test.cgi?id=7578 only works with some window managers due to bug 495189)

Comment 7

[Bjarne (:bjarne)]

Please note that nsWindow.h is missing the empty #define LOGDRAG(args) in the case of not MOZ_LOGGING

Comment 8

[Karl Tomlinson (back June 29 :karlt)]

Attachment: LOGDRAG when not MOZ_LOGGING

Comment 9

[Karl Tomlinson (back June 29 :karlt)]

Comment on attachment 383554 [details] [diff] [review]
LOGDRAG when not MOZ_LOGGING

(In reply to comment #7)
> Please note that nsWindow.h is missing the empty #define LOGDRAG(args) in the
> case of not MOZ_LOGGING

Thanks for reporting that.  Added here:
http://hg.mozilla.org/mozilla-central/rev/89f53e5b3186

Comment 11

[Karl Tomlinson (back June 29 :karlt)]

Comment on attachment 380050 [details] [diff] [review]
patch

This fixes a flaw in one of Firefox-3.5's most proclaimed features.  The flaw was considered serious enough to block Firefox-3.5, when it existed on Mac.

Comment 12

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Verified fixed with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090708 Minefield/3.6a1pre ID:20090708031411

Comment 13

[Samuel Sidler (old account; do not CC)]

Comment on attachment 383554 [details] [diff] [review]
LOGDRAG when not MOZ_LOGGING

Approved for 1.9.1.2. a=ss for release-drivers

Please land on mozilla-1.9.1 and use the ".2-fixed" option of the "status1.9.1" flag.

Is there a bug for getting an automated test written for this bug?

Comment 14

[Karl Tomlinson (back June 29 :karlt)]

status-1.9.1.2-fixed:
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/ddd572669d0e
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/2c91b9ce0a8a

(In reply to comment #13)
> Is there a bug for getting an automated test written for this bug?

I don't really have a good picture of how an automated test for this might work.
Simulating a drag would require sending native pointer motion and button events.

Comment 15

[Henrik Skupin [:whimboo][⌚️UTC+2]]

I don't think that this is possible. After I have verified the fix with tomorrow build I will update the Litmus testcase: https://litmus.mozilla.org/show_test.cgi?id=7578

Adding .2-fixed flag.

Comment 16

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Verified fixed with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.2pre) Gecko/20090728 Shiretoko/3.5.2pre ID:20090728032218

Litmus test has been updated. Marking in-litmus+.