718199 - Inactivating a window doesn't update all parts of certain widgets (title bar, toolbar, status bar)

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect)

Description

[Stefan [:stefanh]]

Attachment: Screenshot of issue

Recent trunk, Mac OS 10.7.2.

It looks like we don't repaint a window's toolbar/title bar when the window loses focus. For me, this happens all the time with the Firefox Page Info window.

Steps to reproduce:
1) Launch Firefox
2) Open the pageInfo window (Tools --> Page Info)
3) If necessary, adjust the position of the Page Info window so it won't be covered by the browser window in the next step
4) Click the browser window

--> Parts of toolbar/title bar of Page Info window doesn't update background-color

Note: this is pretty much the same issue as described in bug 622542. The difference here is that it now happens when the windows are hw accellerated.



From the Graphics section in about:support
--------------------------------------------
WebGL Renderer
Intel Inc. -- Intel HD Graphics 3000 OpenGL Engine -- 2.1 APPLE-7.14.5

GPU Accelerated Windows
2/2 OpenGL

AzureBackend
skia
--------------------------------------------

CC:ing some people who might have a better idea on what this is about.

Comment 1

[Mats Palmgren (inactive)]

I can reproduce this in a 20120107 Nightly on OSX 10.7.2.

Comment 2

[Joe Drew (not getting mail)]

This is a dupe, I'm pretty sure, but I can't find the original. Definitely a known issue.

And very sad that it's not fixed in 10.7. :(

Comment 3

[Stefan [:stefanh]]

It makes us look really bad... Mats, what graphics hw do you have?

Comment 4

[Stefan [:stefanh]]

(In reply to Stefan [:stefanh] from comment #0)
> Note: this is pretty much the same issue as described in bug 622542. The
> difference here is that it now happens when the windows are hw accellerated.

Sorry, I mixed up the bug #. I meant bug 626096, which only happens if hw acc is off. This was supposed to be fixed in bug 622542, but then bug 626096 was reopened.

Maybe this is what Joe refer to in comment #2.

Comment 5

[Mats Palmgren (inactive)]

(In reply to Stefan [:stefanh] from comment #3)
> It makes us look really bad... Mats, what graphics hw do you have?

My graphics details is the same as yours in comment 0.

Comment 6

[Stefan [:stefanh]]

Attachment: Screenshot of partailly updated prefWindow

Comment 7

[Stefan [:stefanh]]

I see this with most utility windows (DOMi, Preferences, Download Manager etc)

I can also see this in the browser window and the places window, but the effect vanishes after a brief moment.

It seems that this only happens when the window is partially covered by another window (could be any window, like a Finder window).

Comment 8

[Steven Michaud [:smichaud] (Retired)]

Anyone have a regression window on this?

Comment 9

[Steven Michaud [:smichaud] (Retired)]

I just reproduced this on OS X 10.6.8 (with today's mozilla-central nightly).

Comment 10

[Jeff Muizelaar [:jrmuizel]]

(In reply to Steven Michaud from comment #8)
> Anyone have a regression window on this?

Afaik, it is caused by opengl layers and has been around since we turned that on.

Comment 11

[Stefan [:stefanh]]

I went through a bunch of old nightlies and the first time the issue appears is in a nightly from 2010-12-17. That leaves me with a regression window that looks like this:

2010-12-16 = OK (http://hg.mozilla.org/mozilla-central/rev/a5413c3c1013, rev 59394)
2010-12-17 = Not OK (http://hg.mozilla.org/mozilla-central/rev/d1da1005b6d6, rev 59443)

Comment 12

[Steven Michaud [:smichaud] (Retired)]

I can't reproduce Stefan's STR, even on OS X 10.7.2.  I find that the
problem occurs momentarily (for a fraction of a second) with both
nightlies.

But I also find that the problem gets worse recently -- that with
recent nightlies I see the problem happening "permanently", or for
several seconds.

On OS X 10.6.8 the problem gets significantly worse (in my tests) with
the following mozilla-central nightly:

2012-01-06-08-18-35-mozilla-central

and more specifically with the following patch:

http://hg.mozilla.org/mozilla-central/rev/2325e88b6026
Bug 711658. Move quirks triggering earlier. r=bgirard
author      Jeff Muizelaar <[e-mail]>
            Mon Dec 19 12:47:09 2011 -0500 (at Mon Dec 19 12:47:09 2011 -0500)

On OS X 10.7.2 I see the problem getting significantly worse earlier,
with the following nightly:

2011-09-27-03-08-45-mozilla-central

Tomorrow I'll check to see which patch is involved.

Sounds like this bug is going to be a real bear to fix ... or even to
describe properly.  I won't have much time for it until I've finished
working on other, more urgent bugs.

Comment 13

[Benoit Girard (:BenWa)]

That patch only make nightly behave more like a release version of firefox by triggering quirks.

I think this bug is related to bug 644494. When you reproduce bug 644494 (See comment 11), you can get an area of the window to update by moving any other window above it which creates an effect similar to the screenshot here.

Comment 14

[Stefan [:stefanh]]

I happen to have a 10.6 machine, so I made a build on 10.6 from m-c revision 59434 in order to further narrow the regression window (see comment #11). I couldn't reproduce the issue described in comment #0 with that build. I then made a build from revision 59443 and manually backed out Joe's 2 changesets from bug 611433. Unfortunatelly, the build failed for some reason. But this indicates that either the patches in bug 611433 or the patches in bug 604101 are the cause.

I've only tested this on Lion and then used the STR as described in comment #0. Just to clarify, in order to see the issue, the Page Info window have to partially cover the browser window. I also found out that I sometimes can see the issue in the browser window itself if I use the keyboard to switch focus from Page Info to browser.

Comment 15

[Steven Michaud [:smichaud] (Retired)]

(Following up comment #12)

> On OS X 10.7.2 I see the problem getting significantly worse
> earlier, with the following nightly:
>
> 2011-09-27-03-08-45-mozilla-central
>
> Tomorrow I'll check to see which patch is involved.

http://hg.mozilla.org/mozilla-central/rev/5c52fd250a41
Bug 687864 - Part 1: Add offline renderer awareness for Mac OGL in browser; r=jmuizelaar
author     Benoit Girard <[e-mail]>
           Wed Sep 21 15:20:40 2011 -0400 (at Wed Sep 21 15:20:40 2011 -0400)

Comment 16

[Jeff Muizelaar [:jrmuizel]]

(In reply to Steven Michaud from comment #15)
> (Following up comment #12)
> 
> > On OS X 10.7.2 I see the problem getting significantly worse
> > earlier, with the following nightly:
> >
> > 2011-09-27-03-08-45-mozilla-central
> >
> > Tomorrow I'll check to see which patch is involved.
> 
> http://hg.mozilla.org/mozilla-central/rev/5c52fd250a41
> Bug 687864 - Part 1: Add offline renderer awareness for Mac OGL in browser;
> r=jmuizelaar
> author     Benoit Girard <[e-mail]>
>            Wed Sep 21 15:20:40 2011 -0400 (at Wed Sep 21 15:20:40 2011 -0400)

This probably just impacts the OpenGL driver you're using. Try forcing it to a particular one using gfxCardStatus. i.e. if you force to integrated only you should it significantly worse even without that patch.

Comment 17

[Steven Michaud [:smichaud] (Retired)]

The string "gfxCardStatus" doesn't exist anywhere in the tree.

Comment 18

[Jeff Muizelaar [:jrmuizel]]

(In reply to Steven Michaud from comment #17)
> The string "gfxCardStatus" doesn't exist anywhere in the tree.

Try searching on the internet :)

Comment 19

[Steven Michaud [:smichaud] (Retired)]

> gfxCardStatus

Thanks!  Though you'd have saved me some time if you'd told me what it is.

In fact it's an app that, if you have more than one kind of video
hardware, allows you to accept the OS default (to automatically switch
between them) or to force apps to use one kind of video hardware or
another.  It's available at http://codykrieger.com/gfxCardStatus.
Beware that it's a little flaky, especially on OS X 10.6.8 --
sometimes Firefox doesn't obey when you	set gfxCardStatus to always
use a particular "video card" (even after restarting Firefox).	I find
this can be cured by rebooting the OS.

I have two kinds of graphics hardware on the 6-month-old MacBook Pro
with which I've been testing:

Built-in (aka integrated):

Intel HD Graphics 3000

PCIe:

AMD Radeon HD 6750M

Starting with the following mozilla-central nightly, I always see this
bug with the integrated	Intel "video card".  I never see it with the
AMD "video card".  This	is on both OS X	10.7.2 and 10.6.8.

firefox-2010-12-17-03-mozilla-central

So Stefan, I can now reproduce your regression range!

The patches I mentioned above changed my system's behavior by changing
which "video card" Firefox used -- by making it use the Intel "card".

Give me an hour and I'll find which patch in Stefan's range triggered
the bug.

Comment 20

[Steven Michaud [:smichaud] (Retired)]

> Give me an hour and I'll find which patch in Stefan's range triggered
> the bug.

Here it is:

http://hg.mozilla.org/mozilla-central/rev/ac8edf791852
Bug 604101 - Part 4 - Use UploadSurfaceToTexture in TextureImage. r=joe a=blocking2.0
author	Matt Woodrow <[e-mail]>
	Thu Dec 16 23:29:23 2010 -0800 (at Thu Dec 16 23:29:23 2010 -0800)

I have a guess about which part of this patch triggered the problem.  I'll try that out next.

Comment 21

[Steven Michaud [:smichaud] (Retired)]

> I have a guess about which part of this patch triggered the problem.
> I'll try that out next.

My guess was wrong.

Comment 22

[Stefan [:stefanh]]

I can't reproduce this my STR in comment #0 anymore on 10.8.2 or 10.6.8. I don't have 10.7 anymore, though.

Comment 23

[Stefan [:stefanh]]

I can't reproduce my STR in comment #0 anymore on 10.8.2 or 10.6.8. I don't have 10.7 anymore, though.

Comment 24

[Stefan [:stefanh]]

Resolving this per my previous comment and the fact that I still have the same hw.