While bookmark is dragged, the tooltip should not appear

VERIFIED FIXED in Firefox 6

Status

()

Firefox
Bookmarks & History
VERIFIED FIXED
7 years ago
6 years ago

People

(Reporter: Alice0775 White, Assigned: mak)

Tracking

({regression})

Trunk
Firefox 6
x86
Windows 7
regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [places-next-wanted][fixed-in-places])

Attachments

(1 attachment)

(Reporter)

Description

7 years ago
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)

Updated

7 years ago
Blocks: 560198
(Assignee)

Comment 1

7 years ago
looks like mine
Assignee: nobody → mak77
Status: NEW → ASSIGNED
(Assignee)

Comment 2

7 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?
(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

7 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

6 years ago
Whiteboard: [places-next-wanted]
(Assignee)

Comment 5

6 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?
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

6 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

6 years ago
Created attachment 526224 [details] [diff] [review]
patch v1.0 [checked-in]

Thank you Alice, your hint was really useful!
Attachment #526224 - Flags: review?(enndeakin)
Attachment #526224 - Flags: review?(enndeakin) → review+
(Assignee)

Comment 9

6 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

6 years ago
Whiteboard: [places-next-wanted] → [places-next-wanted][fixed-in-places]
(Assignee)

Comment 10

6 years ago
http://hg.mozilla.org/mozilla-central/rev/2980819aed55
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 6
(Assignee)

Comment 11

6 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 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-
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.