Closed
Bug 555474
Opened 14 years ago
Closed 13 years ago
While bookmark is dragged, the tooltip should not appear
Categories
(Firefox :: Bookmarks & History, defect)
Tracking
()
VERIFIED
FIXED
Firefox 6
People
(Reporter: alice0775, Assigned: mak)
References
Details
(Keywords: regression, Whiteboard: [places-next-wanted][fixed-in-places])
Attachments
(1 file)
1.59 KB,
patch
|
enndeakin
:
review+
jst
:
approval-mozilla-aurora-
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a4pre) Gecko/20100327 Minefield/3.7a4pre ID:20100327035846 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a4pre) Gecko/20100327 Minefield/3.7a4pre ID:20100327035846 While bookmark is dragged, the tool tip should not appear. When I drag bookmark, a tooltip appears, and bookmarks menu popup is closed at the moment when a mouse pointer hover on the tool tip. Reproducible: Always Steps to Reproduce: 1. Start Minefield with new profile 2. Click "Bookmarks" on the Menubar. 3. Click "Mozilla Firefox" sub folder. 4. Drag start a bookmark item in the sub folder. [move mouse slowly] 5. Dragging it until tooltip appear. 6. Drag over the tooltip. Actual Results: Bookmarks menu popup is closed at the moment when a mouse pointer hover on the tool tip. Expected Results: While bookmark is dragged, the tool tip should not appear. The menu popup should not be closed unless a mouse pointer is located in the outside of the menu popup while dragging. regression wiondow: works: http://hg.mozilla.org/mozilla-central/rev/f3687d491693 Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a2pre) Gecko/20100223 Minefield/3.7a2pre ID:20100223070107 fails: http://hg.mozilla.org/mozilla-central/rev/c3b327ad051a Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a2pre) Gecko/20100223 Minefield/3.7a2pre ID:20100223120428 change set: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f3687d491693&tochange=c3b327ad051a candidate bug: Bug 544047 - Places drop indicators are not dismissed on drop (revise code to get rid of nsDragAndDrop in Places)
Assignee | ||
Comment 2•14 years ago
|
||
hm, bug 312852 fixed the case where dragstart fires after a tooltip opens. but here i see tooltips opening when i dragover, ideally no tooltip should open at all during any drag session. Enn, do you know if the old d&d API was handling tooltips differently from the new API?
Comment 3•14 years ago
|
||
(In reply to comment #2) > hm, bug 312852 fixed the case where dragstart fires after a tooltip opens. but > here i see tooltips opening when i dragover, ideally no tooltip should open at > all during any drag session. The patch in that bug doesn't look like it would have fixed that bug. > Enn, do you know if the old d&d API was handling tooltips differently from the > new API? Drag/drop code doesn't deal with tooltips in any special way. Are you receiving a mouse event after the drag has started? Specifically a mousemove, mouseover or mouseout?
Reporter | ||
Comment 4•13 years ago
|
||
When remove event.stopPropagation(); in dragstart method, this problem is gone. I am glad if I become the hint of the solution. browser/components/places/content/menu.xml <handler event="dragstart"><![CDATA[ if (!event.target._placesNode) return; let draggedElt = event.target._placesNode; // Force a copy action if parent node is a query or we are dragging a // not-removable node. if (!PlacesControllerDragHelper.canMoveNode(draggedElt)) event.dataTransfer.effectAllowed = "copyLink"; // Activate the view and cache the dragged element. this._rootView._draggedElt = draggedElt; this._rootView.controller.setDataTransfer(event); this.setAttribute("dragstart", "true"); - event.stopPropagation(); ]]></handler>
Assignee | ||
Updated•13 years ago
|
Whiteboard: [places-next-wanted]
Assignee | ||
Comment 5•13 years ago
|
||
Neil, does the above suggestion make sense based on mouse events that happen on DND? so stopPropagation of dragStart let other mouse events to pass as if we are not in a drag session?
Comment 6•13 years ago
|
||
If a drag starts, then the mousemove event that triggers it stops propagating. It shouldn't be affected by calling stopPropagation within dragstart though.
Assignee | ||
Comment 7•13 years ago
|
||
My suspicion is that stopPropagation prevents the fix from bug 312852 to work. That just added a dragstart listener to nsXULTooltipListener.cpp, if we are somehow registered before that listener we can easily eat dragstart and that code will be uneffective. And no, after dragstart I don't see any mousemove, out, over events. So I think the drag is delayed and the tooltip has enough time to show up before the drag starts. The patch in bug 312852 should have added a capture listener rather than a bubbling one. Will try this change and attach a patch in case it works.
Assignee | ||
Comment 8•13 years ago
|
||
Thank you Alice, your hint was really useful!
Attachment #526224 -
Flags: review?(enndeakin)
Updated•13 years ago
|
Attachment #526224 -
Flags: review?(enndeakin) → review+
Assignee | ||
Comment 9•13 years ago
|
||
Comment on attachment 526224 [details] [diff] [review] patch v1.0 [checked-in] http://hg.mozilla.org/projects/places/rev/2980819aed55
Attachment #526224 -
Attachment description: patch v1.0 → patch v1.0 [checked-in]
Assignee | ||
Updated•13 years ago
|
Whiteboard: [places-next-wanted] → [places-next-wanted][fixed-in-places]
Assignee | ||
Comment 10•13 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/2980819aed55
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 6
Assignee | ||
Comment 11•13 years ago
|
||
Comment on attachment 526224 [details] [diff] [review] patch v1.0 [checked-in] I'd like to port this really simple fix to Aurora. The current behavior makes drag&drop of bookmarks a pain.
Attachment #526224 -
Flags: approval-mozilla-aurora?
Comment 12•13 years ago
|
||
Comment on attachment 526224 [details] [diff] [review] patch v1.0 [checked-in] Not going to take this for 5, we'll get this in 6.
Attachment #526224 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora-
Comment 13•13 years ago
|
||
Verified fixed on: Mozilla/5.0 (Windows NT 6.1; rv:6.0a1) Gecko/20110421 Firefox/6.0a1
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•