Closed Bug 495184 Opened 11 years ago Closed 11 years ago
current drag operation (drop
Effect) is not updated while dragging outside the application
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
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.
Attachment #380050 - Flags: superreview?(roc) → superreview+
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.
11 years ago
With this fixed we need to update https://litmus.mozilla.org/show_test.cgi?id=7578
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) → review+
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?
Attachment #380050 - Flags: approval1.9.1? → approval126.96.36.199?
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? → approval188.8.131.52?
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
Target Milestone: --- → mozilla1.9.2a1
11 years ago
Attachment #380050 - Flags: approval184.108.40.206? → approval220.127.116.11+
Comment on attachment 383554 [details] [diff] [review] LOGDRAG when not MOZ_LOGGING Approved for 18.104.22.168. 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: approval22.214.171.124? → approval126.96.36.199+
status-188.8.131.52-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:184.108.40.206pre) Gecko/20090728 Shiretoko/3.5.2pre ID:20090728032218 Litmus test has been updated. Marking in-litmus+.
Flags: in-litmus? → in-litmus+
You need to log in before you can comment on or make changes to this bug.