Closed Bug 495184 Opened 11 years ago Closed 11 years ago

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

Categories

(Core :: Widget: Gtk, defect)

x86
Linux
defect
Not set

Tracking

()

VERIFIED FIXED
mozilla1.9.2a1
Tracking Status
status1.9.1 --- .2-fixed

People

(Reporter: karlt, Assigned: karlt)

References

Details

(Keywords: platform-parity, verified1.9.1)

Attachments

(2 files)

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
Flags: wanted1.9.1?
Attached patch patchSplinter Review
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.
Assignee: nobody → mozbugz
Status: NEW → ASSIGNED
Attachment #380050 - Flags: superreview?(roc)
Attachment #380050 - Flags: review?(enndeakin)
Attachment #380050 - Flags: review?(enndeakin) → review+
Attachment #380050 - Flags: superreview?(roc) → superreview+
Attachment #380050 - Flags: approval1.9.1?
Comment on attachment 380050 [details] [diff] [review]
patch

Is this wanted for 1.9.1(.0)?
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?
(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.
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)
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Please note that nsWindow.h is missing the empty #define LOGDRAG(args) in the case of not MOZ_LOGGING
Attachment #383554 - Flags: review?(roc)
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
Attachment #383554 - Flags: approval1.9.1?
Duplicate of this bug: 499489
Attachment #380050 - Flags: approval1.9.1? → approval1.9.1.1?
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.
Attachment #383554 - Flags: approval1.9.1? → approval1.9.1.1?
Keywords: pp
Blocks: 479995
Verified fixed with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090708 Minefield/3.6a1pre ID:20090708031411
Status: RESOLVED → VERIFIED
Flags: wanted1.9.1?
Target Milestone: --- → mozilla1.9.2a1
blocking1.9.1: --- → needed
Flags: wanted1.9.1.x?
Flags: wanted1.9.1.x+
Flags: blocking1.9.1.1?
Flags: blocking1.9.1.1-
Attachment #380050 - Flags: approval1.9.1.1? → approval1.9.1.2+
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?
Attachment #383554 - Flags: approval1.9.1.1? → approval1.9.1.2+
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.
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.
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+.
Flags: in-litmus? → in-litmus+
Keywords: verified1.9.1
blocking1.9.1: needed → ---
Depends on: 721762
You need to log in before you can comment on or make changes to this bug.