427173 - Massive tooltips (OS theme change related?)

Status: VERIFIED FIXED

(Core :: Widget: Win32, defect)

Description

[Alex Faaborg [:faaborg] (Firefox UX)]

Attachment: 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.

Comment 1

[Wayne Mery (:wsmwk)]

Attachment: 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.

Comment 2

[Wayne Mery (:wsmwk)]

pretty sure the regression is <2weeks

Comment 3

[Wayne Mery (:wsmwk)]

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

Comment 4

[Alex Faaborg [:faaborg] (Firefox UX)]

>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.

Comment 5

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Windows-specific? I don't seem to see this on the Mac, compiled-today debug trunk Thunderbird.

Comment 6

[Wayne Mery (:wsmwk)]

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

[Alex Faaborg [:faaborg] (Firefox UX)]

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).

Comment 8

[Daniel Holbert [:dholbert]]

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.

Comment 9

[Daniel Holbert [:dholbert]]

Attachment: 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

[/\/\arcio Galli]

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

[/\/\arcio Galli]

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. 

Comment 12

[Wayne Mery (:wsmwk)]

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

Comment 13

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

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?

Comment 14

[Daniel Holbert [:dholbert]]

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

Comment 15

[Daniel Holbert [:dholbert]]

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

Comment 16

[Alex Faaborg [:faaborg] (Firefox UX)]

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

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

Comment 18

[Kai Liu]

<Speculation>
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.
</Speculation>

Comment 19

[mixxster]

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

[Kai Liu]

Attachment: fix

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.

Comment 21

[Kai Liu]

Comment on attachment 319936 [details] [diff] [review]
fix

Low-risk fix for a big (literally ;)) UI bug

Comment 22

[:Gavin Sharp [email: [e-mail]]]

mozilla/widget/src/windows/nsNativeThemeWin.cpp 	3.126 

Comment 23

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

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.