If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Massive tooltips (OS theme change related?)

VERIFIED FIXED in mozilla1.9



Widget: Win32
10 years ago
9 years ago


(Reporter: faaborg, Assigned: Kai Liu)


({dogfood, polish, regression})

Windows Vista
dogfood, polish, regression
Bug Flags:
blocking1.9 -

Firefox Tracking Flags

(Not tracked)



(4 attachments)



10 years ago
Created attachment 313754 [details]
Massive tool tip

I don't know how to reproduce, but I had been changing my OS theme a lot with the same window open before I encountered this.  The issue effects all tool tips, see a the attached screen shot for an example.  Closing an reopening the browser brings the tool tips back to normal.


10 years ago
Summary: Massive Tool tips → Massive tooltips (OS theme change related?)
Created attachment 313865 [details]
Thunderbird Big Tooltip

seen in Thunderbird 20080402 and some prior nightlies.
certainly a regression, but unable to determine range - can't always repro immed. after start of new instance.

environment is thunderbird windows XP, accessed via remote desktop from vista.
Keywords: qawanted
pretty sure the regression is <2weeks
Keywords: regression
Alex, can you give some idea of a regression range?

I can't make it fail on demand, so the best I have so far is
- fails version 3.0a1pre (2008032602)
- testing version 3.0a1pre (2008032002)
- perhaps doesn't fail on 080228

See this mouse over any toolbar icon, or folder or message field with tooltip.
When it kicks in, makes thunderbird trunk near unusable => dogfood
Severity: normal → major
Keywords: dogfood

Comment 4

10 years ago
>Alex, can you give some idea of a regression range?

I've only encountered the issue once, and it was right before I filed, using the latest nightly build.
Windows-specific? I don't seem to see this on the Mac, compiled-today debug trunk Thunderbird.
windows-specific certainly possible - will really help if we can get any of the following:
* other trunk users to confirm (windows or otherwise) 
* steps
* regression range

The difficultly for me, and I assume Alex too, is it's not 100% repro until it starts happening and we don't have steps to reproduce.

Alex have you still not seen it again?

Comment 7

10 years ago
I have only seen it happen once.  I had just changed my OS theme about 15 times right before seeing it (testing the UI with different os themes, including the larger high contrast ones).
I can reproduce this fairly repeatably using today's latest-trunk in Windows Vista by doing the following:
 1. Open the "Appearance Settings" (Right-click desktop, choose "Personalize", and then pick "Window Color & Appearance".)
 2. Choose "Windows Classic" look, and hit apply
 3. Start Firefox
 4. Hover over a bookmark on the Firefox Bookmarks Toolbar, to make its tooltip appear. (I'm using the default "Getting Started" bookmark.)
 5. Switch to "Windows Vista Basic" appearance, and hit apply
 6. Hover over the bookmark again, to make a Vista-themed tooltip appear
 7. Switch back to "Windows Classic" appearance, and hit apply
 8. Hover over the bookmarks-toolbar bookmark one last time.

This final hover gives me a huge gray tooltip like the one in attachment 313754 [details].

If I close & reopen firefox at this point, the tooltips are fine again.  But if I repeat the process, then I once again get broken tooltips.

Regarding the regression range -- I see this in Firefox 3b5, so it dates back at least that far.  I'll get some more builds to see if I can get a better regression range.
Flags: blocking1.9?
Created attachment 318897 [details]
screenshot: related bug (tooltip gray instead of yellow)

Using the steps in comment 8, I wasn't always able to reproduce the massive-tooltip bug, but I could reproduce a related gray-tooltip-with-no-borders bug. (see screenshot -- tooltip should be yellow, with a border.)

This gray-tooltip-with-no-borders bug is very reproducible (again, using the steps from comment 8), and it regressed between these build IDs:

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b4pre) Gecko/2008022806 Minefield/3.0b4pre
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b4pre) Gecko/2008022906 Minefield/3.0b4pre

Bonsai link: http://tinyurl.com/6dww4p
Maybe a regression from bug 418552 or bug 419383 ?

Comment 10

10 years ago
Was talking screenshots on Vista, for the reviewers guide, and noticed this, and thank God found this bug. I checked with Vista, FF3b5, new profile. I am now checking with trunk recent. 

Comment 11

10 years ago
YEs, really tough to reproduce again. The thing I know is that this was a machine of my girlfriend, she probably never changed her OS theme, and yes, I changed the theme before testing. So probalby if you get a fresh Vista, you can reproduce this I dont know why. 
Been running a few days with thunderbird version 3.0a1pre (2008042303) and I've not seen it.  And so far, also not with version 3.0a1pre (2008050103).  But can't say for sure if it's gone
Might this have something to do with the way we use -moz-system-metric(default-windows-theme)? Either way, people flipping between classic and non classic isn't a big deal.

FWIW, I've ever only seen this in ||s, and assumed it was due to that. Are any of you seeing this with Windows running natively?
Flags: blocking1.9? → blocking1.9-
(In reply to comment #13)
> FWIW, I've ever only seen this in ||s, and assumed it was due to that. Are any
> of you seeing this with Windows running natively?

Yes, I've seen both issues with Windows running natively.  (I've also seen both when connected remotely via rdesktop, fwiw)

(By "both issues" I mean the original "huge tooltip" issue and the "gray-tooltip-with-no-borders" issue mentioned in comment 9)
IMHO, if we don't block on this, we should at least try to get it fixed for 1.9.0.x.  Requesting 'wanted' status
Flags: wanted1.9.0.x?

Comment 16

10 years ago
>Are any of you seeing this with Windows running natively?

Yeah, this attachment 313754 [details] shows it with windows running naively


10 years ago
Duplicate of this bug: 432771

Comment 18

10 years ago
The lack of borders on the huge gray tooltip means that it's attempting a native rendering (which disables the borders that would otherwise have been drawn by the CSS for tooltips), and the lack of a background and the bogus size suggests that the calls to uxtheme are failing.  I think what may be going on here is the tooltip theme handle (which Firefox caches) had become invalid.  Right now, if an invalid (but non-null) handle is used, there's no check to see if an error had occurred.  A quick-fix would be to add such a check, and to try to get a new handle if it looks like the old one is invalid.  But we should also find out why it's entering an invalid state in the first place; the spotty reproducibility and the fact that nobody is reporting this problem with any of the other widgets (whose theme handles are also similarly cached) is interesting.

Comment 19

10 years ago
There is a very quick way to test this bug if you want to go into windows classic mode in vista. Hold Alt-Left Shift-PrtSc and it will switch to high contrast mode, essentially a really dark windows classic. I've been having problems with this bug for a few weeks now, I am glad I finally pinpointed the problem to theme changes so I don't have to be scared of the massive tooltips ever surprising me.  It should be a block, a huge tooltip that blocks the entire screen is a pretty critical issue, and makes the product look really buggy.

Comment 20

10 years ago
Created attachment 319936 [details] [diff] [review]

Okay, I see the problem.  The big tooltip problem is actually the result of a typo.  When Firefox receives a theme change notification, it closes all of its cached theme handles, but thanks to a typo, it's closing the toolbar theme handle twice and not ever closing the tooltip theme handle, which means that there's a chance upon every theme change that the tooltip's theme handle will become invalid (and which is why reproduction is sporadic).

Also, while looking through the code to see why this problem would manifest itself on XP (bug 161600 forced XP/2K3 to render the tooltip classically), I noticed that only the actual drawing on XP was taking the classic code path, while everything else was taking a themed code path, which is why the problem was able to manifest itself on XP (see comment 1), so this patch also addresses that oversight.
Assignee: nobody → kliu
Attachment #319936 - Flags: review?(vladimir)


10 years ago
Keywords: qawanted → polish
Whiteboard: [has patch][needs review]


10 years ago
Attachment #319936 - Flags: superreview?(roc)
Attachment #319936 - Flags: superreview?(roc)
Attachment #319936 - Flags: superreview+
Attachment #319936 - Flags: review?(vladimir)
Attachment #319936 - Flags: review+

Comment 21

10 years ago
Comment on attachment 319936 [details] [diff] [review]

Low-risk fix for a big (literally ;)) UI bug
Attachment #319936 - Flags: approval1.9?


10 years ago
Whiteboard: [has patch][needs review] → [has patch][has review]
Blocks: 419383


10 years ago
Attachment #319936 - Flags: approval1.9? → approval1.9+


10 years ago
Keywords: checkin-needed
Whiteboard: [has patch][has review] → [has patch][has review][has approval]
mozilla/widget/src/windows/nsNativeThemeWin.cpp 	3.126 
Last Resolved: 10 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Whiteboard: [has patch][has review][has approval]
Target Milestone: --- → mozilla1.9
I cannot reproduce it anymore with Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9) Gecko/2008051206 Firefox/3.0 => Verified.
Flags: wanted1.9.0.x?
You need to log in before you can comment on or make changes to this bug.