Last Comment Bug 555474 - While bookmark is dragged, the tooltip should not appear
: While bookmark is dragged, the tooltip should not appear
Status: VERIFIED FIXED
[places-next-wanted][fixed-in-places]
: regression
Product: Firefox
Classification: Client Software
Component: Bookmarks & History (show other bugs)
: Trunk
: x86 Windows 7
: -- normal (vote)
: Firefox 6
Assigned To: Marco Bonardo [::mak]
:
Mentors:
Depends on:
Blocks: 544047 560198
  Show dependency treegraph
 
Reported: 2010-03-27 11:38 PDT by Alice0775 White
Modified: 2011-04-22 05:09 PDT (History)
6 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
patch v1.0 [checked-in] (1.59 KB, patch)
2011-04-15 05:32 PDT, Marco Bonardo [::mak]
enndeakin: review+
jst: approval‑mozilla‑aurora-
Details | Diff | Splinter Review

Description Alice0775 White 2010-03-27 11:38:23 PDT
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] 2010-05-05 19:34:57 PDT
looks like mine
Comment 2 Marco Bonardo [::mak] 2010-05-12 06:50:57 PDT
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 (away until Oct 3) 2010-05-12 07:27:59 PDT
(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 2011-02-09 20:36:16 PST
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] 2011-03-16 08:39:35 PDT
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 (away until Oct 3) 2011-03-16 08:56:43 PDT
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] 2011-04-14 17:26:13 PDT
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] 2011-04-15 05:32:19 PDT
Created attachment 526224 [details] [diff] [review]
patch v1.0 [checked-in]

Thank you Alice, your hint was really useful!
Comment 9 Marco Bonardo [::mak] 2011-04-15 07:46:54 PDT
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] 2011-04-18 06:04:33 PDT
http://hg.mozilla.org/mozilla-central/rev/2980819aed55
Comment 11 Marco Bonardo [::mak] 2011-04-18 06:05:39 PDT
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, jst@mozilla.com) 2011-04-19 15:54:40 PDT
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 B [:simonab ] 2011-04-22 05:09:57 PDT
Verified fixed on:  Mozilla/5.0 (Windows NT 6.1; rv:6.0a1) Gecko/20110421 Firefox/6.0a1

Note You need to log in before you can comment on or make changes to this bug.