312852 - Tooltip should not appear during a drag (e.g., dragging favicon results in tooltip, blocking part of the bookmarks toolbar)

Status: VERIFIED FIXED

(Core :: XUL, defect, P1)

Description

[Andy Ozment]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b5) Gecko/20051006 Firefox/1.4.1
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b5) Gecko/20051006 Firefox/1.4.1

Normal behaviour: drag a URL from the navigation bar to the bookmark toolbar;
when you release it, it appears as a bookmark.

However, with the latest two Mac alphas (perhaps older as well), this is
partially broken.

If you drag the URL to the portion of the bookmark toolbar immediately below the
URL space on thenavigation bar, a tooltip appears that states: "Drag and drop
this icon to create a link to this page"

That tooltip blocks the creation of a bookmark in that location. If you release
the URL, it is _not_ added as a bookmark. 

This problem is particularly frustrating if you are attempting to add a bookmark
to a folder located in that spot on the bookmark toolbar.

Reproducible: Always

Steps to Reproduce:
1. Drag URL from navigation bar to bookmark toolbar
2. Drag that URL onto the location of the bookmark toolbar that is immediately
below the URL location on the navigation toolbar.
3. Wait briefly for the tooltip "Drag and drop this icon to create a link to
this page" to appear.
4. Release the URL while your cursor is over the tooltip, so that a bookmark
should be created right under the tooltip.

Actual Results:  
No bookmark is created.

Expected Results:  
A bookmark should be created or the tooltip should move out of the way.

Comment 2 in bug 296057 mentions this problem as well:
<https://bugzilla.mozilla.org/show_bug.cgi?id=296057#c2>

However, bug 296057 describes a different problem and is not a dupe of this bug.

Comment 1

[zug_treno]

Duplicate of/related to Core bug 133064?

Comment 2

[Jesse Ruderman]

Marcia Knous and I see this bug too.  I'm using
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b5) Gecko/20051024 Firefox/1.5

Marcia says this doesn't happen in Firefox 1.0.x, so I doubt it's a dup of bug 133064.

Comment 3

[Jesse Ruderman]

This regressed on trunk between a 2005-06-20 build and a 2005-06-22 build.

Comment 4

[Jesse Ruderman]

I don't see any checkins during that period that reference tooltips or the proxy icon or dragging, but there were some event-handling changes, including:

* Bug 282940, Switch Mozilla/Firefox to CFRunLoopSource-based plevent handling.

* Bug 296704, Trusted event reinitialization allows data-theft.

Comment 5

[Marcia Knous [:marcia]]

As Jesse mentioned, I don't see this happening in 1.0.7. I think this is an annoying enough polish issue that it should be addressed for 1.5.

Comment 6

[Uri Bernstein]

*** Bug 329981 has been marked as a duplicate of this bug. ***

Comment 7

[Katja Schulz]

Just a reminder that this problem is still happening in version 1.5.0.3, and another vote for getting it fixed sooner rather than later.

Comment 8

[Phil Ringnalda (:philor)]

*** Bug 318772 has been marked as a duplicate of this bug. ***

Comment 9

[Mike Beltzner [:beltzner, not reading bugmail]]

Josh, is there a simple fix for this regression? I'm guessing that I'll be self-minusing this nomination in my next triage pass, but it's an annoying enough regression that we might want to fix it.

Comment 10

[Mike Beltzner [:beltzner, not reading bugmail]]

As predicted, we're not going to block on this, but if there's a small patch that can restore the Firefox 1.0 functionality, we'd love to take it.

Comment 11

[Charlie Schliesser]

*** Bug 345976 has been marked as a duplicate of this bug. ***

Comment 12

[Mark Mentovai]

I bet this is caused by not sending NS_MOUSE_EXIT to the last-pointed widget when beginning a drag.  That would be a pretty easy fix, but I'd want to verify the behavior against the win32 implementation.  I predict we'll be able to fix this regression for 2b2.

Comment 13

[Mark Mentovai]

Yeah, looks like that's what's going on.

Comment 14

[Mark Mentovai]

but it's not

Comment 15

[Phil Ringnalda (:philor)]

*** Bug 351718 has been marked as a duplicate of this bug. ***

Comment 16

[Phil Ringnalda (:philor)]

*** Bug 351791 has been marked as a duplicate of this bug. ***

Comment 17

[Håkan Waara]

This is really bad for first-time users of Firefox 2 (it seems to work on trunk). I think it should block Ff2.

Comment 18

[Charlie Schliesser]

also bad for users of Firefox 1.5.x....

Comment 19

[mfurman]

I agree with Håkan Waara: since this is the "first impression" when new user attempt to set up their links, it does not sit well for recommending to others.

Comment 20

[Phil Ringnalda (:philor)]

*** Bug 352076 has been marked as a duplicate of this bug. ***

Comment 21

[Phil Ringnalda (:philor)]

*** Bug 354640 has been marked as a duplicate of this bug. ***

Comment 22

[(not reading, please use [e-mail] instead)]

mark, fwiw, the trunk doesn't seem to have this problem

Comment 23

[Jake Olefsky]

I can confirm that this bug still exists in RC2 and it is very annoying.  The only work around is to drag the bookmark, but keep holding the mouse button down for 5 seconds until the tooltip goes away.

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1) Gecko/20061003 Firefox/2.0

Comment 24

[Marcia Knous [:marcia]]

I agree with earlier sentiments about this being rather annoying - still seen in Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0. Would like to see this addressed in one of the early follow up releases after we ship.

Comment 25

[Ann Randall]

I added my vote and remembered why I switched to Camino for several months. For people who have elaborate bookmark bars with multiple folders, this is extremely annoying. If the help balloon popped up above the address area, the problem would be solved. I'm using a MacBook running OS 10.4.8 and am using Mozilla 2.0

Comment 26

[Ann Randall]

Clarifications: That would be Mozilla Firefox 2.0 (Gecko/20061010 Firefox/2.0). And when I said "over" the address field, I meant above the address field.

Comment 27

[Håkan Waara]

A way to prevent this bug was even in the "top 8" list for firefox tweaks at this page: http://www.lifehacker.com/software/firefox-2/geek-to-live--top-firefox-2-config-tweaks-209941.php

I'd strongly suggest nominating this for a minor firefox 2-release.

Comment 28

[Phil Ringnalda (:philor)]

*** Bug 358708 has been marked as a duplicate of this bug. ***

Comment 29

[Oskar L-B]

> I'd strongly suggest nominating this for a minor firefox 2-release.

Strongly agree. Also note: in firefox 3.0.1a (latest trunk) there's a bug that won't let you drop proxy icons on the toolbar at all.

Comment 30

[Jesse Ruderman]

> Also note: in firefox 3.0.1a (latest trunk) there's a bug that
> won't let you drop proxy icons on the toolbar at all.

Bug 354958?

Comment 31

[Mike Connor [:mconnor]]

Yes, it sucks, but until we have an understanding of it, its not a blocker.

Comment 32

[Håkan Waara]

One possible way of getting this fixed would be not to not send out tooltip events during a drag. I don't think that is normal on mac anyways.

Comment 33

[Jesse Ruderman]

*** Bug 364959 has been marked as a duplicate of this bug. ***

Comment 35

[Ria Klaassen (not reading all bugmail)]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a3pre) Gecko/20070209 Minefield/3.0a3pre
I can see this on Windows too with some effort. Weird, for all duplicates are Macs.

Comment 36

[Tracy Walker [:tracy]]

(Mac)The tooltip appears on mouse-over of the favicon, just as a tooltip appears on mouse-over of any of the toolbar buttons.  The tooltip appears a set number of pixels below the pointer.  Is this coded the same for all the toolbar items, or can the tooltip for the favicon location be changed?  Over the location bar (and I mean covering the URL as opposed to above the field in the title bar; comment #26) is better than covering the bookmarks toolbar.

I've been programmed to just wait out the tooltip. 
Setting browser.chrome.toolbar_tips = false is also a workaround.

nominating for 3.0 in case it doesn't make a 2.0.0.x release.

Comment 37

[Phil Ringnalda (:philor)]

I suspect sspitzer's right, and this doesn't exist on the trunk, making it hard for it to block Fx3, but with bug 358446 not letting the drag actually work, it's hard to be certain.

Comment 38

[Tracy Walker [:tracy]]

You're right, this doesn't exist on trunk.  When the favicon is clicked for dragging, the tooltip goes away. Thus allowing d-n-d at the users leisure. Bug 358446 doesn't block creating a bookmark this way. d-n-d of the favicon to bookmarks toolbar works fine on trunk. On branch, one must wait out the tooltip if they want to drop the drag in tooltip covered area of the toolbar. 

I'd back out my 3.0 blocking request but don't have the power since it's been approved.

Comment 39

[Phil Ringnalda (:philor)]

Bah, you'd think while I was making sure the tooltip still didn't get in the way, I'd actually drop one, and see that it does now work.

beltzner: wanna rescind that blocking-firefox3+, so we don't have to mark this branch-only bug wfm for its trunk status?

Comment 41

[Mike Connor [:mconnor]]

Clearing blocking flag per prior comments.

Comment 43

[Alan]

The only work around for this is to not drop the link until the tool tip goes away. When the tool tip disappears, then the link can be dropped.  It's a "real" annoying problem, but that appears to be the only way around it.  It would be nice if the tooltip could be moved to a different location instead of right over the bookmark toolbar.

Comment 45

[Phil Ringnalda (:philor)]

Awesome: after all my protestations that it was fixed by Cocoa widgets, apparently I meant "fixed" - looks like prior to bug 395397 we were ignoring the event triggering the tooltip, rather than properly squelching it, so in 20070919 Firefox or Seamonkey, you can drag the page proxy icon, or selected text from the search bar, without a tooltip, but in 20070920 of both, we're back to having tooltips in the way of drags.

In fact, they are worse than I remember the Widget: Mac tooltips being, because they don't just go away - not only do they not time out the way they did in 1.8, they don't disappear until another event pushes them out of the way, so if you drag the page proxy for a cached page (a bug page won't work, but an mxr one will), get the tooltip, get tired of waiting, and just drop in the content window, you get a sticky tooltip until the next event you trigger.

Comment 47

[Josh Aas]

I don't see this problem. Does it still exist for others? Please renominate for blocking1.9 status after confirming that the bug exists and posting up-to-date repro steps.

Comment 48

[hacksaw]

Still same repro steps for Firefox 2.0.0.9 on Mac OS X 10.4.10

Comment 49

[Jesse Ruderman]

WFM on trunk.

Comment 50

[Tracy Walker [:tracy]]

I still see it with: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9a9pre) Gecko/2007110604 Minefield/3.0a9pre

STR:  
1) Hover over location bar favicon.  Notice tooltip covering a portion of bookmarks toolbar
2) click (tooltip goes away) and drag the favicon over the bookmarks toolbar. Notice tooltip covering a portion of bookmarks toolbar

The reappearing tooltip is the bug. If you want to dnd to a place that is covered by that tooltip, then you don't really know where you're dropping.  Only show the tooltip on hover over the favicon.

This has changed a bit, it seems.  Sometimes the tooltip will appear just low enough to expose some of the toolbar. Then you can see the dnd feed back, or if over a folder, it expands.

Comment 51

[Alan]

I still see it also on Mac OS X 10.4.10 using Firefox version 2.0.0.9.

Comment 52

[Damon Sicore (:damons)]

-'ing for 1.9.  Marking as wanted.  This has been around for a while.  

Comment 53

[Phil Ringnalda (:philor)]

So, Jesse, Josh: are you not-seeing it on 10.5, meaning that the second regression, from bug 395397, is 10.4-only?

Comment 54

[Jesse Ruderman]

I'm still using 10.4.

Comment 56

[marc.wirbeleit]

I can confirm this bug still exists for Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11 

Mac OS X is 10.4.11

The obvious solution would be to make the tool tip disappear once the cursor begins moving on drag-and-drop - after all, this is how the TITLE attribute "tool tip" behaves.

Comment 57

[Aaron]

Or perhaps just delaying the pop up tip to 3 or 5 seconds, instead of 1 second.

Comment 58

[Usama]

I was just going to report this problem but seems like it's been there forever.  if tool tip could show up below the bookmark menu bar it should solve the problem?

seems like the tool tip is covering / blocking URL to be bookmarked.

you can, however, drag it to either left or right of the tool tip to bookmark it..

well the problem is when you have a folder. it becomes two step process.  You have to add URL to the bookmark menu bar and then drag that into a folder.. when it is ideal to just be able to drag directly into a folder..

Comment 59

[Daniel Veditz [:dveditz]]

Don't see that anything has changed that makes this now a blocker for 2.0.0.12, but it's still "wanted" on the branch should anyone write a patch.

Comment 60

[Karl]

This Bug still exists in 3.0b2 (MacOSX 10.5.1) and it's still quite annoying.
Please, someone simply remove the ToolTip from the Proxy Icon, delay it's dispay for some secs
or hide tooltip at least as soon as the mouse starts moving after being inert for some secs.

Comment 61

[Henrik Skupin [:whimboo][⌚️UTC+2]]

This doesn't only happen under OS X. I wanted to file this issue for Windows a long time ago but forgot it. Now when adding a bookmark to the toolbar I saw it again with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4pre) Gecko/2008030206 Minefield/3.0b4pre ID:2008030206. You have to use the tiny space above or under the tooltip to place the bookmark into this folder.

Comment 62

[P Nienaber]

Still happening in FF3b3 -- this really should be a release blocker:  it's pretty embarrassing.  Perhaps just removing the tooltip until a better resolution can be found would be a good idea.  All the tooltip does at present is further annoy people who are already unable to drag&drop new bookmarks.

Comment 63

[Aleks Totic]

Second the removal of the tooltip. What good does it do if you can't drop the bookmark.

Comment 64

[Martijn Wargers (dead)]

Attachment: patch

This fixes it.

There is only one very small issue with the patch. When you drag something and you drop it on the same spot as where you started dragging the, the tooltip doesn't appear when mousemoving in that element. It does work again when mousing out and mousing over again.
I guess this could be fixed by adding a draggesture event handler for xultooltiplistener, but I think that's probably overkill for such a minor bug.

Comment 65

[Martijn Wargers (dead)]

Attachment: browser-chrome test I was working on

I was working on a browser-chrome test.
It works most of the time when you click the "Run All Tests" button quickly enough. But it doesn't work if you wait a little while. No idea why this happens.
It doesn't work at all with --autorun.

I did some digging, it seems like the mousemove event isn't fired at all.
It seems like some code in viewmanager.cpp is not allowing this event to fire:
http://lxr.mozilla.org/seamonkey/source/view/src/nsViewManager.cpp#1232
Perhaps this is caused by the patch for bug 248226?

Also, it seems like there is no way to bring an unfocused window to the front, which is also annoying.

Comment 66

[[e-mail]]

Comment on attachment 310472 [details] [diff] [review]
patch

I don't think this is going to work: we only listen to mouse down events after showing the tooltip. (Neil Deakin could confirm this for you.)

Comment 67

[Martijn Wargers (dead)]

Yes, I thought that too, when looking at the code, but that doesn't seem to be the case in practice, fwiw.

Comment 69

[Alan]

I think the bug is as Tracy Walker said in comment #50; the bug is that the tool tip reappears during d-n-d when the mouse is over the fav-icons bar.  It's the reappearance that's the problem.

The tool tip appears properly when the mouse hovers over the URL icon. Then when the button down event occurs, the tool tip correctly disappears, but when the dragging starts and the mouse moves over the fav-icons bar, the tool tip reappears. This reappearance is the bug. The Mac and Windows versions appear similar except for the Mac's re-appearance of the tool tip when the mouse is dragging the URL over the fav-icons bar.

I wonder if there is a tool tip trigger event on the bar or some layer under the bar that causes that toop tip to appear again.

The tool tip should not be appearing again.

Comment 73

[Ann Randall]

I think comment #69 is right on the money. There is some urgency to this bug. It is not just an annoyance; it is a dealbreaker. I'm not a programmer (except bits of php) but am an early adopter. I used an alternate browser for at least a year, maybe two, because of this bug. I finally figured out that if I held my cursor below the tooltip until it disappeared again, I could move my bookmark into the bookmark folder that had been obscured. Only then did I start using Firefox and its cousins again. How many non-tekkie users would go to that trouble?

Comment 75

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Dumb question: is the particular toolbar in question here (over the favicon, which currently says "Verified by: Equifax" or "This web site provides no identity information") even useful, given that clicking the favicon will provide the same information?

Comment 76

[Stephen Donner [:stephend] Not actively reading bugmail]

(In reply to comment #75)
> Dumb question: is the particular toolbar in question here (over the favicon,
> which currently says "Verified by: Equifax" or "This web site provides no
> identity information") even useful, given that clicking the favicon will
> provide the same information?

s/toolbar/tooltip?

Comment 77

[Martijn Wargers (dead)]

Attachment: working browserchrome test

This is a browserchrome test that works with the attached patch (and fails in various cases without it). This only tested with the --autorun method.

Although, it doesn't seem necessary, I still would very much like to know a way of bringing an unfocused window to the front.

Comment 81

[Timwi]

I'm not sure Bug 434502 is a duplicate of this. It doesn't really have anything to do with the bookmarks toolbar or with dragging URLs.

Also, the proposed fixed in this bug here appears to be to display the tooltip in a different position. I am extremely surprised at that. Why do you want the tooltip to appear at all while you're in the middle of dragging an element? Surely you want the tooltip to appear only if the mouse button is not pressed?

Comment 82

[Kai Liu]

(In reply to comment #81)

Well, the general problem is the same: that the tooltip is appearing during a drag-and-drop.  The correct solution is to correct the general tooltip behavior, which would solve both the general problem you described and the specific subcase that this bug was originally about.

Comment 85

[Yugo Nakai]

(In reply to comment #82)

Come on, devs!  This bug has been around since 2005-10-18, and there are several proposed patches and fixes right here in the comments!  Comment #82 looks like a good general solution (although I am not a FF hacker).  Point is, can we just get this fixed?  It can't be that hard!

Comment 86

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Martijn, is your patch somehow ready to send out for review? Further updating summary to make this bug better to find.

Comment 87

[Kai Liu]

Updating summary because the favicon tooltip problem is only one case of a general problem.  (Martijn's patch addresses the general problem and is not specific to the favicon tooltip)

Comment 88

[Brad Williamson]

Has anyone noticed that if you just wait a couple seconds, the tool tip disappears?

Comment 89

[Ann Randall]

Brad Williamson said: Has anyone noticed that if you just wait a couple seconds, the tool tip disappears?"

Yes. I alluded to that in my 2008-04-12 post. I just now counted the seconds, and  it's a 4-5 second wait for me.

Comment 90

[Timwi]

> Has anyone noticed that if you just wait a couple seconds, the tool tip
> disappears?

How is that at all relevant to this bug?

Comment 93

[[e-mail]]

Yeesh.

I would think that the code would be "easy" (semi-psuedocode):

if(click_event == URL button)
{
    while(mouse_button1_down == TRUE) // not a click event but dragging event
    {
        verified_tooltip = FALSE; // turn off tooltip & other dialogs**
        move_icon_drag_n_drop(); // or some such thing for mouse movement
    }
}
verified_tooltip = TRUE;

//note: I haven't written for windows yet so this is all guessing about 'code'.

** or flag for all pop-up texts like tooltip_text or verified_tooltip or whatever

That is, the "tooltip" dialog in Firefox 3.0 should not show up while in drag and drop "mode".  I'd swear this is a simple code modification / addition to do.  It applies to all tooltip like pop-up stuff except of course the X'd out one (invalid drag location) and similar -icon- not dialog.

I know the dialog box / text box disappears after 4-5 seconds but it shouldn't appear until AFTER the button_down stops.  I'd read the code but I'm 1st semester (and it's been a while) C++ and 4 years C long past.

Comment 94

[Kai Liu]

(In reply to comment #93)
> I would think that the code would be "easy"
> 
And it is.  Martijn's patch is a testament to the simplicity of the solution.  The problem is basically comment 66 and comment 67.

So we could either...

1) Adopt the patch in comment 64 and either ignore comment 66 or otherwise find out why comment 64 works despite the fact that reading the code strongly suggests that it shouldn't work

2) Go with a different approach, such as listening for draggesture and dragend as suggested in comment 64 or listening to drag (which would an even "easier" 4-line patch and wouldn't suffer from the problem of the tooltip not showing if the drag ends at the same spot as the start), but both of these methods involve adding a new listener, and Martijn expressed reservation over that in comment 64

Comment 98

[Ray Kiddy]

There is a new behavior with FF3 that trips this again. I went to drag a icon from the left-hand side of the location bar (which is possible, yeah!) and the darn 'This web site does not display identity information' tooltip (which BTW pops up way too often when a blank icon is enough) gets right in the way of my drag. Arg.

Comment 99

[Mike Beltzner [:beltzner, not reading bugmail]]

Johnath: would you be OK removing that tooltip? I think I might be ... if so, file that patch and ask for approval.

This doesn't block release. We've shipped many, many versions with this bug, I don't think it's all of a sudden increased in priority.

Comment 100

[Eddy Nigg (StartCom)]

OS field should be changed to MAC only. I can't confirm this bug on Linux (Maybe doesn't affect Windows/Vista either).

Comment 101

[Johnathan Nightingale [:johnath]]

(In reply to comment #99)
> Johnath: would you be OK removing that tooltip? I think I might be ... if so,
> file that patch and ask for approval.

Removing the tooltip on the site button doesn't solve the general case, which Martijn's patch does. I would prefer to find Neil or whomever we need to chime in on the questions in comment 66, and land the patch (with tests!) that already exists.  Is there a reason not to do that?

> This doesn't block release. We've shipped many, many versions with this bug, I
> don't think it's all of a sudden increased in priority.

I agree - it should be fixed, but given that it isn't a release blocker, I think it's worth fixing it properly.

Comment 102

[Hideo Oshima]

I can confirm comment 98 on Windows XP too.
Should I open another bug?

Comment 103

[Johnathan Nightingale [:johnath]]

(In reply to comment #102)
> I can confirm comment 98 on Windows XP too.
> Should I open another bug?

No, this bug should cover all platforms and should resolve this issue, once the right course of action is decided, and the appropriate changes are reviewed and landed.

Comment 104

[Hideo Oshima]

(In reply to comment #103)
> (In reply to comment #102)
> > I can confirm comment 98 on Windows XP too.
> > Should I open another bug?
> 
> No, this bug should cover all platforms and should resolve this issue, once the
> right course of action is decided, and the appropriate changes are reviewed and
> landed.

Thanks for your explanation.
I understand.

Comment 106

[[e-mail]]

I think this bug is falling into the realm of 'management decision'.  I'm going to investigate the 'command structure' (sorry, Star Trek fan) of Mozilla to see where I can get involved as I believe the company to be of the community orientation (having committees of unpaid public to decide things) rather than the pointy haired boss type of normal corporation and the requisite flaws as such.

There are many choices of how to handle this bug.  There is also a newsgroup that may be discussing it and I hope to discuss it there as people here should as well (and may be).  I used to be SQA and know the concepts but can't get too involved yet.

Just because of a problem like this that is popular unfortunately doesn't mean it will be fixed as that is a slippery slope and we would wind up with a "Homermobile" from the Simpsons TV show if you know what I mean! :-)

Comment 107

[Mads]

Never saw this tooltip "This web site provides no
identity information" in ff2 and it does indeed annoy me when I drag the icon for bookmarking to my toolbar's folder in ff3. What's the so called tip for anyway..

Comment 108

[John Karahalis]

I just realized that using about:config to disable browser.chrome.toolbar_tips also disables tooltips on images with the "title" attribute.

So, even with a workaround problems persist.

Comment 109

[[e-mail]]

Oh for God's sake!!
[head hits table]

This takes care of it.  No wonder there was never a patch as there is a setting flag for it!  It's not user changeable but it does fix it.

Note when you select that value the right click and select 'toggle' to change it's value.

Well, "case closed" although it should be user controlled but if you did that with all the features the options section (tabs and all) would be in the thousands overloading the user.  This after all needs to be user friendly.

I still say it needs that functional change that when the mouse location goes into 'drag mode' the tool tip should disappear and not on a timer.  But that can be debatable.  *sigh*

Thanks so much John for letting us know about it including about:config which I never knew about!

Comment 110

[P Nienaber]

The bottom line, though, is that functionality is broken, and unless the fix is the default state of the setting, things are still broken "out of the box", and that looks bad to new users.  Of course, if you do want the tooltips for some reason, then that feature is still broken, even if the default setting is changed, so obviously something still has to happen here (which seems to be where things are heading... eventually).

Comment 111

[John Karahalis]

Oh wow, I had no idea you guys didn't know about that setting. I read about it on a blog (http://phalkunz.com/2006/10/30/disable-annoying-firefox-tooltips/) and submitted a bug report requesting that this setting be modified (https://bugzilla.mozilla.org/show_bug.cgi?id=440890)

But anyway, as I said in my last post, disabling this setting also disables tooltips for images (and presumably other elements) that use the "title" attribute. For example, try hovering your mouse on any xkcd comic. A tooltip should appear with words of wisdom, but does not. So even with after modifying this setting in about:config, you will run into some annoying problems.

Comment 112

[John J. de Jong]

This behaveour is still observed in FF3 release on an XP machine... 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0

Clicking the icon already shows the security information, I don´t believe there are a lot of users that would want to see this information as well as a tooltip while dragging to the bookmarks toolbar...

Apart from stating the obvious (annoying!) I am unpleasantly surprised that something seemingly simple to fix has been around for so long without any action being taken apart from a patch that will never be found by the average mainstream user.

Devs, get your heads together and fix this!!!

Comment 113

[Paolo Loggia]

I become used to bookmark with d'n'd of the favicon in the personal bookmark tab on ff2 and worked flawlessly.
This simple thing on ff3 it's uneasy to obtain, I'm going back and use Ctrl-d most of the time.
This change of behavior is the most annoying for the experienced user and the most confusing for newcomers.
Either this bug is underrated or the functionality is overestimated, because you can have a very similar tooltip over the lock icon on the lower-right corner.
I would want to ask to disable the favicon tooltip asap and re-enabling it when it is ready, to make user experience more satisfactory.

Comment 117

[Marc Ott]

This has affected Windows also since FF3 betas. Very annoying; really should be a release blocker

Comment 119

[Adam Goldstein]

This is present and highly obstructive in FF 3.0.1 and above.

Attempting to drag the current URL opens the info box over the personal bookmarks toolbar, obscuring the intended folders and usually resulting in failed drops, or, dropping directly into the toolbar vs. the intended folder.

Quite simple options for fixes.. removing the infobox on drag, making it more transparent, or, making it pop-up -above- the pointer rather than below. 

Comment 122

[Jim Jeffery not reading bug-mail 1/2/11]

I no longer see the tooltip interfering with the latest trunk build.  As soon as you 'mouse-down' to start the drag on the FavIcon the tooltip goes away, no longer hiding the Bookmarks Toolbar.  

Not sure when this was fixed/corrected...

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b1pre) Gecko/20080904035000 Minefield/3.1b1pre Firefox/3.0 ID:20080904035000

Comment 123

[Henrik Skupin [:whimboo][⌚️UTC+2]]

This is not fixed yet. Still there with Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b1pre) Gecko/20080904035000 Minefield/3.1b1pre ID:20080904035000

Comment 124

[Ria Klaassen (not reading all bugmail)]

Still seeing this in the latest trunk build on Windows XP.

Comment 128

[Jacob]

Still not fixed yet, very annoying bug, glad I found out about browser.chrome.toolbar_tips.

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1a2) Gecko/20080829065003 Shiretoko/3.1a2

Comment 129

[Asaf Romano (gone)]

STR that reproduces this bug:
1. mouse move on say, Larry.
2. *before* the tooltips shows up, mouse down and star dragging
(-> Tooltip shows up.)

STR that does not reproduce this bug:
1. drag something on larry
2. wait
(-> no tooltip)

Comment 130

[Ria Klaassen (not reading all bugmail)]

There was also a regression on 23-24 Feb 2005, possibly caused by Bug 125386, where the favicon tooltip didn't disappear anymore on mouseout.
- Mousedown on favicon, drag a few pixels, the tooltip (re)appears, then as soon as you leave the image, the tooltip should disappear when the mouse enters a location where you can't drop it. Bug 125386 broke this, although I don't know if it was the last regression because I did only random checks.

Comment 131

[Gernot Hueller]

> Comment #125 From  Ria Klaassen (not reading all bugmail)
> 2008-09-08 13:00:54 PDT
> *** Bug 454150 has been marked as a duplicate of this bug. ***

I think that bug #454150 is NOT a duplicate of this bug, as 454150 specifically notes the website identity tooltip whereas this bug is about user info tips like "drag and drop this icon..."

please handle the WEBSITE IDENTITY TOOLTIP vs dragging to the bookmarks toolbar!

Comment 132

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(In reply to comment #131)
> I think that bug #454150 is NOT a duplicate of this bug, as 454150 specifically
> notes the website identity tooltip whereas this bug is about user info tips
> like "drag and drop this icon..."

It's the identity tooltip and not the identity panel! These are different things. The latter one will be opened by a mouse-up event. So it will not be affected by d&d. Resolving the bug as dupe was correct.

Comment 135

[Markus Stange [:mstange]]

Attachment: v2

I unbitrotted Martjin's patch and simplified the test.
Martijn's patch works as-is - the answer to comment 66 is:
nsXULTooltipListener::AddTooltipSupport adds a listener for the "mouseout" event, and since nsXULTooltipListener implements nsIDOMMouseListener, it gets MouseDown and MouseUp called, too.

Comment 136

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 344084 [details] [diff] [review]
v2

> nsXULTooltipListener::MouseMove(nsIDOMEvent* aMouseEvent)
> {
>-  if (!sShowTooltips)
>+  if (!sShowTooltips || mIsMouseDown)
>     return NS_OK;
Would it be enough to check here that nsIDragService::getCurrentSession doesn't return
any session?

Comment 137

[Markus Stange [:mstange]]

I just tried it, but it didn't work. Maybe mouse move events aren't fired anymore once the drag session has started?
I think the current patch works because there's a threshold before a drag session is started, during which the crucial mouse move event fires.

Comment 139

[Marco Bonardo [:mak]]

i'm asking blocking because actually we have tooltips on Places menus, when a tooltip appear while you are dragging, as soon as you touch the tooltip with the mouse the menus are dismissed due to dragleave. So dragging in menus has become really hard. If we can't fix this we should disable tooltips in Places menus again.

Comment 140

[Pedro Jiménez]

Just to note that this bug is still there, other than the tooltip disappearing after like 5 seconds, which is too much, you still get the yellow tooltip over the bookmark bar and can't place it on folders/bar.

Comment 141

[nipirc]

I am also having this issue, and it is driving me up the walls. I hope this gets fixed soon, because the workaround of disabling all tooltips is not an option for me. Too many sites I visit daily use tooltips to carry information I need.

Comment 143

[Mike Beltzner [:beltzner, not reading bugmail]]

Roc: while a minor nuisance, the use case from bug 467239 comment 0 is indeed quite irksome and a regression of sorts through the combination of this bug and the site identity panel. Not sure if that affects your prioritization.

Comment 144

[Markus Stange [:mstange]]

Attachment: v3

This works.

Comment 145

[Josh Aas]

I'd advocate for getting this into 1.9.1 if at all possible, thanks for the patch Markus.

Comment 146

[Olli Pettay [:smaug][[e-mail]]]

On linux dragging something from outside to a browser window doesn't
fire 'dragstart' (and I think that is ok per html 5).
'dragenter' and 'dragover' seem to work ok in that case. Would handling either
of those be enough to fix this bug?

Comment 147

[Markus Stange [:mstange]]

(In reply to comment #146)
> On linux dragging something from outside to a browser window doesn't
> fire 'dragstart' (and I think that is ok per html 5).

Is that a problem? As far as I can tell, the tooltip only appears if you start your drag gesture inside the browser window.

Comment 148

[Olli Pettay [:smaug][[e-mail]]]

(In reply to comment #147)
> Is that a problem?
It *might* be a problem. Tooltip appears after a timeout, so in some
very unlikely case user might have been able to start dragging before
tooltip is shown. I have no idea how to reproduce that though.
On linux window focus handling depends on user's setting - whether it follows
mouse or follows mouse after timeout or needs mouse click or whatever, so the
problem might be more likely there than elsewhere.
But MouseOut should handle at least most of the problematic cases.

Comment 149

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 350959 [details] [diff] [review]
v3

So r=me.
Would be great to change C-style casting to C++ static_cast<>.

Comment 150

[Markus Stange [:mstange]]

I'll replace the casts on checkin. There are 16 of them in that file.

(In reply to comment #148)
> (In reply to comment #147)
> > Is that a problem?
> It *might* be a problem. Tooltip appears after a timeout

I'm not sure I understand. The timeout is started on mouse move. But during a drag no mouse move events are fired.

I think this is what happens (with the patch) when the user moves his mouse to the button, presses the mouse button and drags away:

 1. User moves mouse over button
    -> Timeout is started.
 2. User presses the mouse button
    -> Timeout is killed. If the timeout has already fired the tooltip is
       killed, too.
 3. User starts dragging
    -> A mouse move event fires, timeout is started.
 4. User crosses dragstart threshold
    -> Dragstart event fires, timeout and tooltip are killed.
 5. User drags away
    -> No further mouse move events are sent, so no new timeout is started
       and no tooltip appears.

Comment 151

[Markus Stange [:mstange]]

pushed: http://hg.mozilla.org/mozilla-central/rev/56af7f8280af

Comment 152

[Johnathan Nightingale [:johnath]]

Is this something we can land on 1.9.1 branch as well?

Comment 153

[Markus Stange [:mstange]]

I think so, the patch should be fairly safe. But it won't hurt to let it bake for a while.

Comment 154

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 350959 [details] [diff] [review]
v3

a191=beltzner

Comment 155

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Verified with Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20081212 Minefield/3.2a1pre ID:20081212040742 and appropriate build on OS X.

Shouldn't the patch have tests to get allowed for check-in into 1.9.1 branch?

Comment 157

[Markus Stange [:mstange]]

pushed to mozilla-1.9.1:
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/0dc120ad2314

My first attempt at writing a test for this had failed.
I guess I'll try again.

Comment 158

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Verified on 1.9.1 with:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20081224 Shiretoko/3.1b3pre ID:20081224042714

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081225 Shiretoko/3.1b3pre ID:20081225020447

Comment 159

[Martijn Wargers (dead)]

Fwiw, I would have preferred the first patch as that would allow fixing bug 301482.

Comment 161

[Henrik Skupin [:whimboo][⌚️UTC+2]]

This bug has been flagged as wanted1.9.0.x. Markus, can we ask for approval on your latest patch?

Comment 163

[Samuel Sidler (old account; do not CC)]

Can we get an automated test for this? Markus?

Comment 164

[[e-mail]]

This bug is not fixed, 
http://i43.tinypic.com/eugb43.jpg

Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5
Windows XP Pro x64 Edition SP2 / Windows Vista x64 Home Premium Edtition


Work around is here:
browser.chrome.toolbar_tips = false

Comment 165

[Martijn Wargers (dead)]

It's not checked in the 1.9.0.x tree and that probably will not happen, because this is not a security problem or a stability problem.

Comment 166

[Ann Randall]

So is the bug fixed or not?

Comment 167

[Martijn Wargers (dead)]

Yes, the bug is fixed.

Comment 168

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(In reply to comment #166)
> So is the bug fixed or not?

To be a bit more specific. This bug will be fixed with the upcoming Firefox 3.1b3 and for Firefox 3.2.

Comment 170

[ac]

Attachment: this bug still not fixed in 3.05

still not fixed in 3.05

Comment 171

[Martijn Wargers (dead)]

(In reply to comment #170)
> still not fixed in 3.05

Yes, that's known.
The fix is only checked into the Firefox3.1 tree and current trunk.

Comment 172

[Samuel Sidler (old account; do not CC)]

(In reply to comment #170)
> still not fixed in 3.05

See comment 165.

This bug is fixed on trunk (for Firefox 3.2) and the 1.9.1 branch (for Firefox 3.1) but will likely *not* be fixed in Firefox 3.0.x any time soon, if at all. Please do not comment in this bug with reports that it's not fixed in 3.0.x. We know.

Comment 173

[Bill Walch]

(In reply to comment #169)
> *** Bug 474311 has been marked as a duplicate of this bug. ***
Please see my additional comments regarding bug 474311, that were really separate from the drag and drop issues.

Comment 174

[Daniel Veditz [:dveditz]]

Comment on attachment 350959 [details] [diff] [review]
v3

Approved for 1.9.0.7, a=dveditz for release-drivers.

Comment 176

[Markus Stange [:mstange]]

Checking in layout/xul/base/src/nsXULTooltipListener.cpp;
/cvsroot/mozilla/layout/xul/base/src/nsXULTooltipListener.cpp,v  <--  nsXULTooltipListener.cpp
new revision: 1.72; previous revision: 1.71
done

Comment 180

[Al Billings [:abillings - ex-MoCo]]

Verified fixed with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.7pre) Gecko/2009021704 GranParadiso/3.0.7pre.

Comment 184

[jaketmuss]

Bug still exists in Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2a1pre) Gecko/20090322 Minefield/3.6a1pre

Comment 186

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(In reply to comment #184)
> Bug still exists in Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2a1pre)
> Gecko/20090322 Minefield/3.6a1pre

Lets discuss the Linux part over in bug 482070.

Comment 187

[Martijn Wargers (dead)]

Does the first patch in this bug help for linux?

Comment 188

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(In reply to comment #187)
> Does the first patch in this bug help for linux?

We should move the discussion over to bug 482070. But as a final statement I don't know because I don't build on Linux. Probably worth to create a try server build.

Comment 191

[Qianqian Fang]

This bug was not fixed for Linux, please reopen it (see Bug 506783).

Comment 192

[Marco Bonardo [:mak]]

(In reply to comment #191)
> This bug was not fixed for Linux, please reopen it (see Bug 506783).

No, this bug is verified fixed, you should go to bug 482070 for Linux.