Created attachment 657720 [details] tb_tooltip.jpg User Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20100101 Firefox/15.0 Build ID: 20120824154833 Steps to reproduce: Currently using TB 15, but this began a few versions ago, perhaps TB 13. When a user hovers over the Write button, a tooltip is displayed after about a second, which says "Create a new message". Moving the mouse, or clicking the Write button makes the tooltip disappear. Actual results: If, however, the user clicks the Write button before the tooltip is displayed -- which is probably what most long-term users do, since they can hit the button with their eyes closed -- then the tooltip comes up after the Message Compose Window is created, and is displayed on that window, instead. There is, of course, no reason for the tooltip after the user has started a new message. The real problem is this: depending on the size and shape of the user's message composition window, the tooltip appears directly over the first "To" address and persists when the user types an e-mail address, making it impossible to see the address being typed. See the attached image for an example. To duplicate this placement, start a new message, maximize the composition window, then close the window (or send someone an e-mail) and start the process again. The tooltip will likely display as shown in the attached image. Other window size/placements may generate different results. Expected results: The tooltip should not be displayed on the Message Compose Window. This behavior began all of a sudden, a few versions back, and has been consistent since then. Perhaps the 1-second delay to display the tooltip was added in TB12 or 13? In any case, it looks like the tooltip is not being destroyed under one condition in which it should be: the user has already clicked the button to which the tooltip is attached.
I can confirm this on Win XP. However it does happen also for other buttons on the toolbar that open a window, e.g. Addressbook.
Status: UNCONFIRMED → NEW
Component: Message Compose Window → Toolbars and Tabs
Ever confirmed: true
This bug persists in TB 16 as well.
Summary: The "Create a new message" persists on the new message window → The "Create a new message" tooltip persists on top of the "New message" window
Regression window(common-central) Good: http://hg.mozilla.org/mozilla-central/rev/9df0849fa705 http://hg.mozilla.org/comm-central/rev/2df0e948f73b Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0a1) Gecko/20110701 Thunderbird/7.0a1 ID:20110701030155 Bad: http://hg.mozilla.org/mozilla-central/rev/b7f03b37cf0c http://hg.mozilla.org/comm-central/rev/9f8456bb68f6 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0a1) Gecko/20110703 Thunderbird/7.0a1 ID:20110703030028 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9df0849fa705&tochange=b7f03b37cf0c http://hg.mozilla.org/comm-central/pushloghtml?fromchange=2df0e948f73b&tochange=9f8456bb68f6 Regressed by: Bug 664058 - Kill AddEventListenerByIID/RemoveEventListenerByIID from layout
Version: 15 → 7
Turns out this bug affects more than just the "Create a new message window" or the other buttons on the toolbar. I received a message with an attachment. Hovering over the attachment generates a tooltop that says "Open the attached file". But clicking on the attachment, which opens it, does the same thing as clicking on the "write" button -- the tooltip opens a second or two later. In this case, the tooltip appears on top of Microsoft Word and remains there, unless clicked. I tool a snapshot of this, and opened a picture editor, and the tooltip was sitting on top of the picture editor, too. I'm adding a second attachment, showing the tooltop sitting on top of a picture of the tooltip sitting on top of Word.
Created attachment 661900 [details] Image of a different tooltip, persisting on top of two other application windows
Summary: The "Create a new message" tooltip persists on top of the "New message" window → Tooltips persist on top of the windows drawn by TB and by other applications
You need to log in before you can comment on or make changes to this bug.