Switching window between active/inactive causes toolbar/statusbar to not repaint properly

RESOLVED FIXED in mozilla21

Status

()

defect
RESOLVED FIXED
7 years ago
6 years ago

People

(Reporter: stefanh, Unassigned)

Tracking

Trunk
mozilla21
x86
macOS
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

Reporter

Description

7 years ago
(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
Reporter

Updated

7 years ago
Blocks: 831160
Reporter

Comment 1

7 years ago
(In reply to Stefan [:stefanh] from comment #0)
>The titlebar in the Error console window becomes gray

Erm, read that as "light gray"...

Comment 2

7 years ago
(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 :-)

Comment 4

7 years ago
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).
Reporter

Comment 6

7 years ago
(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?
Reporter

Comment 8

7 years ago
(In reply to :Gavin Sharp (use gavin@gavinsharp.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.
https://hg.mozilla.org/mozilla-central/rev/ab658aec6a28
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?
You need to log in before you can comment on or make changes to this bug.