61.25 KB, image/png
104.42 KB, image/png
23.54 KB, image/jpeg
2.55 KB, patch
Mike Schroepfer: approval1.9+
|Details | Diff | Splinter Review|
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.
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.
pretty sure the regression is <2weeks
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
>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?
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.
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 ?
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.
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?
(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
>Are any of you seeing this with Windows running natively? Yeah, this attachment 313754 [details] shows it with windows running naively
<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>
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.
Created attachment 319936 [details] [diff] [review] 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 on attachment 319936 [details] [diff] [review] fix Low-risk fix for a big (literally ;)) UI bug
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.