Closed
Bug 495184
Opened 15 years ago
Closed 15 years ago
current drag operation (dropEffect) is not updated while dragging outside the application
Categories
(Core :: Widget: Gtk, defect)
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)
12.32 KB,
patch
|
enndeakin
:
review+
roc
:
superreview+
samuel.sidler+old
:
approval1.9.1.2+
|
Details | Diff | Splinter Review |
540 bytes,
patch
|
roc
:
review+
samuel.sidler+old
:
approval1.9.1.2+
|
Details | Diff | Splinter Review |
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?
Assignee | ||
Comment 1•15 years ago
|
||
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)
Updated•15 years ago
|
Attachment #380050 -
Flags: review?(enndeakin) → review+
Attachment #380050 -
Flags: superreview?(roc) → superreview+
Assignee | ||
Updated•15 years ago
|
Attachment #380050 -
Flags: approval1.9.1?
Assignee | ||
Comment 2•15 years ago
|
||
Comment on attachment 380050 [details] [diff] [review] patch Is this wanted for 1.9.1(.0)?
Comment 3•15 years ago
|
||
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?
Assignee | ||
Comment 4•15 years ago
|
||
(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.
Updated•15 years ago
|
Flags: wanted1.9.1.x?
Comment 5•15 years ago
|
||
With this fixed we need to update https://litmus.mozilla.org/show_test.cgi?id=7578
Flags: in-litmus?
Assignee | ||
Comment 6•15 years ago
|
||
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: 15 years ago
Resolution: --- → FIXED
Comment 7•15 years ago
|
||
Please note that nsWindow.h is missing the empty #define LOGDRAG(args) in the case of not MOZ_LOGGING
Assignee | ||
Comment 8•15 years ago
|
||
Attachment #383554 -
Flags: review?(roc)
Attachment #383554 -
Flags: review?(roc) → review+
Assignee | ||
Comment 9•15 years ago
|
||
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?
Assignee | ||
Updated•15 years ago
|
Attachment #380050 -
Flags: approval1.9.1? → approval1.9.1.1?
Assignee | ||
Comment 11•15 years ago
|
||
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.
Assignee | ||
Updated•15 years ago
|
Attachment #383554 -
Flags: approval1.9.1? → approval1.9.1.1?
Comment 12•15 years ago
|
||
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
Updated•15 years ago
|
Flags: blocking1.9.1.1?
Updated•15 years ago
|
blocking1.9.1: --- → needed
status1.9.1:
--- → wanted
Flags: wanted1.9.1.x?
Flags: wanted1.9.1.x+
Flags: blocking1.9.1.1?
Flags: blocking1.9.1.1-
Updated•15 years ago
|
Attachment #380050 -
Flags: approval1.9.1.1? → approval1.9.1.2+
Comment 13•15 years ago
|
||
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+
Assignee | ||
Comment 14•15 years ago
|
||
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•15 years ago
|
||
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•15 years ago
|
||
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
Updated•15 years ago
|
blocking1.9.1: needed → ---
You need to log in
before you can comment on or make changes to this bug.
Description
•