555474 - While bookmark is dragged, the tooltip should not appear

Status: VERIFIED FIXED

(Firefox :: Bookmarks & History, defect)

Description

[Alice0775 White]

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)

Comment 1

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

looks like mine

Comment 2

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

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

[Neil Deakin]

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

Comment 4

[Alice0775 White]

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>

Comment 5

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

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

[Neil Deakin]

If a drag starts, then the mousemove event that triggers it stops propagating.

It shouldn't be affected by calling stopPropagation within dragstart though.

Comment 7

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

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.

Comment 8

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

Attachment: patch v1.0 [checked-in]

Thank you Alice, your hint was really useful!

Comment 9

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

Comment on attachment 526224 [details] [diff] [review]
patch v1.0 [checked-in]

http://hg.mozilla.org/projects/places/rev/2980819aed55

Comment 10

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

http://hg.mozilla.org/mozilla-central/rev/2980819aed55

Comment 11

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

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.

Comment 12

[Johnny Stenback (:jst)]

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.

Comment 13

[Simona Badau, Desktop QA]

Verified fixed on:  Mozilla/5.0 (Windows NT 6.1; rv:6.0a1) Gecko/20110421 Firefox/6.0a1