37.40 KB, image/png
518.51 KB, image/png
931 bytes, patch
|Details | Diff | Splinter Review|
(also filed as bug 831160 in the SeaMonkey product) Seen on trunk, Mozilla 18 with: - Mac OS X 10.8.2, Mac Mini Mid-2011 (Intel HD 3000) - Mac OS X 10.7.5, Mac Mini server Mid-2010 (NVIDIA GeForce 320M 256 MB) - Mac OS X 10.6.8, Mac Mini 2007 (Intel GMA 950) Steps to reproduce: 1) Launch Firefox 2) Open the Error console 3) Click ouside the Error console window What happens: The titlebar in the Error console window becomes gray, but the toolbar remains dark. See screenshot. This can also be seen in DOMi: 1) Launch DOMi 2) Click the right panel (to focus it) 3) Click outside the DOMi window Nightly build, regression range (ftp://ftp.mozilla.org): Good: /pub/firefox/nightly/2012/09/2012-09-28-03-05-44-mozilla-central/ Bad: /pub/firefox/nightly/2012/09/2012-09-29-03-06-24-mozilla-central/ I tried to reduce the window further and it points to bug 539356: 9f476b4ac1e1 --> OK 035ed3e2d9d4 --> Not OK
(In reply to Stefan [:stefanh] from comment #0) >The titlebar in the Error console window becomes gray Erm, read that as "light gray"...
(In reply to Stefan [:stefanh] from comment #0) > > Seen on trunk, Mozilla 18 with: > - Mac OS X 10.8.2, Mac Mini Mid-2011 (Intel HD 3000) > - Mac OS X 10.7.5, Mac Mini server Mid-2010 (NVIDIA GeForce 320M 256 MB) > - Mac OS X 10.6.8, Mac Mini 2007 (Intel GMA 950) If that last one references my input, it's a mid-2007 MacBook (MacBook2,1). That said, a mini of that generation uses the same GMA 950, so should be entirely reproducible.
I can also reproduce this (testing on a Retina MacBook Pro running OS X 10.7.5). Stefan tells me "DOMi" is the DOM Inspector :-)
I was able to reproduce the FF/DOMi bug on my mid-2007 MacBook2,1 @ 10.6.8. GMA 950. So, definitely not just a SeaMonkey issue after all.
Happens on the main window too, Nightly 21.0a1 (2013-01-25).
(In reply to Alex Limi (:limi) — Firefox UX Team from comment #5) > Created attachment 706625 [details] > Screen shot of corrupted main window > > Happens on the main window too, Nightly 21.0a1 (2013-01-25). Hmm, do you see it in the nightly from 2012-09-29 (comment #0) too?
This sounds like a potential duplicate of bug 820839?
(In reply to :Gavin Sharp (use email@example.com for email) from comment #7) > This sounds like a potential duplicate of bug 820839? It looks related - but this issue seems to be reproducible with nightlies after bug 820839 was fixed.
Attachment #707986 - Flags: review?(roc) → review+
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla21
This led to a ~10% regression on the Linux and Linux64 "Paint" Talos test. That doesn't seem totally unexpected, but may be worth looking into...
I think that's definitely worth looking into!
The Paint talos test has a primary window, and then times how long it takes to launch a second window. The regression is because the primary window changes state, and we repaint all it's contents. Previously this wasn't happening. Pre-DLBI we wouldn't have had the issue either, because we would have waited until the next OS paint event before repainting layers rather than doing this immediately.
Maybe we should defer the repainting of the primary window until the new window is fully painting? We don't want painting of the primary window to slow down the appearing of the new window.
Yeah, I've been thinking about how that would work. We have no way of knowing (I think?) that one of the windows is obscured by the other. And if they were side by side, would we still want to delay repainting the old one until the new one was fully open?
I think so.
You need to log in before you can comment on or make changes to this bug.