Last Comment Bug 626096 - [OS X] [Hardware acceleration off] Switching between active/inactive causes toolbar/statusbar to not repaint properly in certain windows
: [OS X] [Hardware acceleration off] Switching between active/inactive causes t...
Status: REOPENED
: regression
Product: Core
Classification: Components
Component: Graphics (show other bugs)
: Trunk
: All Mac OS X
: -- major with 2 votes (vote)
: mozilla2.0
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
: 630506 (view as bug list)
Depends on:
Blocks: 615870
  Show dependency treegraph
 
Reported: 2011-01-15 10:50 PST by Stefan [:stefanh]
Modified: 2013-01-16 22:13 PST (History)
7 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
-


Attachments
screenshots (top-->bottom: step 2, 3 and 4 in comment #0) (215.26 KB, image/png)
2011-01-15 10:50 PST, Stefan [:stefanh]
no flags Details
screenshot from Sm 2.1b3pre 20110322 build (153.29 KB, image/png)
2011-03-26 04:36 PDT, Adrian Kalla [:adriank]
no flags Details

Description Stefan [:stefanh] 2011-01-15 10:50:32 PST
Created attachment 504148 [details]
screenshots (top-->bottom: step 2, 3 and 4 in comment #0)

STR:

1) Launch a seamonkey nightly (Mac)
2) Click anywhere beside the window, so the window loses focus

--> Title bar changes to "non-focused" gradient, but the toolbar doesn't

3) Keep window non-focused and hover over the url bar
--> background around the url bar changes to "non-focused" color

4) Keep window non-focused and hover over the content area
--> parts of the background in the status bar changes to "non-focused" gradient

Markus, this obviously doesn't look like it's theme-related, but I filed in in seamonkey:themes, since I'm a little bit lost in tracking the cause of this and I can't seem to reproduce this in Firefox or Thunderbird. I have tried to remove all kinds of extra bindings to the toolbar/status bar, but that didn't seem to help.
Comment 1 Stefan [:stefanh] 2011-01-15 10:51:53 PST
I'm on 10.6.6 btw
Comment 2 Stefan [:stefanh] 2011-01-15 10:55:06 PST
Hmm, I guess this is related to bug 621762.
Comment 3 Markus Stange [:mstange] 2011-01-16 07:05:21 PST
Both bug 621762 and bug 623852 are now fixed, can you test again?
Comment 4 Stefan [:stefanh] 2011-01-16 09:30:57 PST
(In reply to comment #3)
> Both bug 621762 and bug 623852 are now fixed, can you test again?

Unfortunately, it's still there in the latest nightly, built from m-c changeset 413eb50d4b81.
Comment 5 Markus Stange [:mstange] 2011-01-16 10:10:10 PST
OK...
Is the window hardware accelerated? (about:support should tell you, if it works in SeaMonkey)
Does turning hardware acceleration on / off change anything? Can you look for a regression range?
Comment 6 Markus Stange [:mstange] 2011-01-16 10:17:53 PST
I can reproduce this when I turn off hardware acceleration.
Comment 7 Stefan [:stefanh] 2011-01-16 10:57:19 PST
In both Firefox and SeaMonkey "Direct2D Enabled" and "DirectWrite Enabled" are false in about:support. At the same time "layers.acceleration.disabled" and "layers.acceleration.force-enabled" are set to false in about:config.

For the record, this is how the "Graphics" looks like in about:support:
Adapter Description 0x24000,0x20400
Vendor ID: 0000
Device ID: 0000
Adapter RAM
Adapter Drivers
Driver Version
Driver Date
Direct2D Enabled: false
DirectWrite Enabled: false
WebGL Renderer: Intel Inc. -- Intel GMA 950 OpenGL Engine -- 1.4 APPLE-1.6.26
GPU Accelerated Windows: 0/1

(I have an old mac mini)

We should probably move this bug to a better component. What's odd is that I don't see this in Firefox...

I should hopefully be able to get a regression range during the coming week.
Comment 8 Stefan [:stefanh] 2011-01-16 14:15:42 PST
The problem exists in the 2010122800 build, but not in the 2010122700 build.

The 2010122800 build was built from m-c changeset e928817fb4e9 which is 19 changesets after the last bits from bug 615870 landed. So, my guess is that this  have existed all the time since then, but the symptoms have been mixed up with bug 621762.

The issue manifests itself slightly different in the 2010122800 build, once I have clicked outside the window, the title bar gets the inactive gradient. If I then move my mouse from the left over the main toolbar, the toolbar gets the correct background once I reach the url bar with the mouse. At the same time, part of the status bar gets a inactive background (like step 4 in comment #0)
Comment 9 Markus Stange [:mstange] 2011-01-17 04:10:27 PST
Bug 615870 sounds like a good candidate for causing this.
Comment 10 Timothy Nikkel (:tnikkel) 2011-01-17 11:06:38 PST
Is this like the mac version of bug 622542 maybe?
Comment 11 Markus Stange [:mstange] 2011-01-17 11:25:47 PST
Could be!
Comment 12 Stefan [:stefanh] 2011-01-19 12:46:17 PST
(In reply to comment #10)
> Is this like the mac version of bug 622542 maybe?

Interestingly, the problem seems to go away if:
1) The cursor is in a textfield
2) Text (in the displayed page) is selected
Comment 13 Timothy Nikkel (:tnikkel) 2011-01-19 12:54:17 PST
Probably because those things trigger invalidation. (blinking cursor or color change in selected text between active/inactive windows).
Comment 14 Stefan [:stefanh] 2011-01-19 14:16:47 PST
(In reply to comment #13)
> Probably because those things trigger invalidation. (blinking cursor or color
> change in selected text between active/inactive windows).

Ah, now I understand why I didn't noticed this in Firefox's DOM Inspector. DOMi loads the current webpage and focus the top DOM node in the left tree. If I click anywhere in the right panel and set the window in an inactive state I can see the issue (because there's no color change then)
Now I also understand why I couldn't see this in Firefox - it's all the :-moz-window-inactive rules in browser.css. Removing those rules, makes the issue appear.
Comment 15 Joe Drew (not getting mail) 2011-01-20 15:26:00 PST
I'd take a patch, but I'd release with this bug.
Comment 16 Stefan [:stefanh] 2011-01-23 09:24:17 PST
Timothy,

If I understand it right, the fix for this isn't widget-specific. Is there any chance this will be fixed by bug 622542?
Comment 17 Timothy Nikkel (:tnikkel) 2011-01-23 20:39:24 PST
It could be, not sure.
Comment 18 Stefan [:stefanh] 2011-01-24 14:34:55 PST
Markus, I guess one work-around to this is to add a bogus -moz-window-inactive style rule to, let's say, the toolbar element (changing the background-color)? I played a bit with it in SeaMonkey and even though it doesn't have any visual effect it seemed to obscure the issue. I think we should consider something like this if this doesn't gets fixed for 2.0, since this will make gecko look bad to a lot of consumers (anyone on a mac with gma950 graphics and possibly others)
Comment 19 Markus Stange [:mstange] 2011-01-24 20:15:09 PST
I think it's very likely that this will get fixed by bug 622542, which is a hard blocker. Let's wait until bug 622542 is fixed before we talk about a workaround.
Comment 20 Adrian Kalla [:adriank] 2011-02-01 05:28:06 PST
*** Bug 630506 has been marked as a duplicate of this bug. ***
Comment 21 Adrian Kalla [:adriank] 2011-02-05 09:46:22 PST
(In reply to comment #19)
> I think it's very likely that this will get fixed by bug 622542, which is a
> hard blocker. Let's wait until bug 622542 is fixed before we talk about a
> workaround.

Looks like the fix for bug 622542 did fix this issue too.
Comment 22 Joe Drew (not getting mail) 2011-02-05 10:33:25 PST
Sounds good to me!
Comment 23 Adrian Kalla [:adriank] 2011-03-26 04:32:31 PDT
in the past few days I saw the issue again. Now I've got a screenshot of it as well as steps to reproduce it (at least on my Mac).

The problem happens, when I open ChatZilla on my Polish SeaMonkey 2.1 trunk build. Before CZ opens, I get a warning, that the Polish ChatZilla langpack was done for version 0.9.86 and I'm using 0.9.86.1 (which seems to be a bug itself, as the Chatzilla language pack identifies itself in the add-on manager as 0.9.86.1... Probably an update issue?). When I click ok, ChatZilla opens - and the theme of the browser window breaks like shown in the following screenshot.
Comment 24 Adrian Kalla [:adriank] 2011-03-26 04:36:38 PDT
Created attachment 522086 [details]
screenshot from Sm 2.1b3pre 20110322 build

Here the screenshot.

I'm not sure if the problem existed before and just the ChatZilla bug(?) brought it up to my attention, or not... The first time I saw it happening again is around a week or two ago...
Comment 25 Stefan [:stefanh] 2011-03-26 06:49:03 PDT
Hmm. The b3 builds are now made from the 2.0 branch. Can you check whether the build at http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/latest-comm-2.0/ exhibits the same problem?
Comment 26 Adrian Kalla [:adriank] 2011-03-27 14:24:40 PDT
(In reply to comment #25)
> Hmm. The b3 builds are now made from the 2.0 branch. Can you check whether the
> build at
> http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/latest-comm-2.0/
> exhibits the same problem?

tested with todays Polish build from the 2.0 branch: the same problem.

Small hint: the ChatZilla-warning-bug was caused by the "locale.version" entity in chatzilla.properties being set to 0.9.86 on the Polish ChatZilla language pack instead of 0.9.86.1: https://mxr.mozilla.org/l10n-central/source/pl/extensions/irc/chrome/chatzilla.properties#72
To reproduce the bug here, I had to revert that back to 0.9.86.
Comment 27 Stefan [:stefanh] 2011-05-14 14:02:20 PDT
Adrian,

Can you still reproduce this? I have never seen any repaint issues after bug 622542 was fixed - perhaps what you see is related to something else (is the warning you mention a sheet?)?
Comment 28 Stefan [:stefanh] 2011-05-15 05:09:27 PDT
OK, so I actually noticed this a couple of hours after I posted comment #27. The warning mentioned in comment #23 is a sheet that appears before the chatzilla window opens. If I have a browser window open when the sheet appears, I can see the issue. Now, the sheet is not attached to the browser window - the parent is probably the hidden window since it opens off-screen.

This looks to me like an edge-case - it only happens when a sheet opens and none of the open/visible windows are the parent of the sheet.
Comment 29 Adrian Kalla [:adriank] 2011-05-23 13:31:41 PDT
Stefan: I guess it won't happen anywhere in SeaMonkey itself, but I bet, that one or more extension authors will hit this sooner or later...
Comment 30 Andrea Govoni 2013-01-13 01:00:32 PST
I'm experiencing this bug since I installed SeaMonkey 2.15. It was not present in SeaMonkey 2.14.1. SeaMonkey 2.16 Beta 1 doesn't solve the issue and I cannot reproduce it with Firefox 18.0.
What I'm seeing is more or less the "original" version described by Stefan, not the edge case described by Adrian Kalla in comment #26 (which I didn't try to reproduce, though).
If I click outside an active (foremost) browser window, only the title bar gets the inactive gradient. If I then move my mouse over the URL bar or over a launch icon in the left side of the status bar, the tool bar and the status bar get the correct background.
I'm seeing the issue also in the other way. If I click inside an inactive browser window, only the title bar gets the active gradient. Then when I move the mouse over a text field, a tab or an area that make the pointer change its shape, the tool bar and the status bar get the correct background.
I'm seeing the problem with hardware acceleration on or off, so maybe this should go in a new bug report.
My system is a Mac mini Server (Middle 2010) with Mac OS X 10.7.5 (11G63). This model comes with an NVIDIA GeForce 320M 256 MB graphic card.
Comment 31 Trane Francks 2013-01-14 04:31:05 PST
(In reply to Andrea Govoni from comment #30)
> I'm experiencing this bug since I installed SeaMonkey 2.15. It was not
> present in SeaMonkey 2.14.1.

I can confirm this with a mid-2007 MacBook2,1 (GMA 6950 video) on OS X 10.6.8.
Comment 32 Trane Francks 2013-01-14 04:33:01 PST
(In reply to Trane Francks from comment #31)

> I can confirm this with a mid-2007 MacBook2,1 (GMA 6950 video) on OS X
> 10.6.8.

Fingers with a mind of their own: GMA 950 graphics with browser hardware acceleration at default settings.
Comment 33 Andrea Govoni 2013-01-15 21:57:14 PST
I've just filed bug 831160 to specifically address the issue described in comment 30 and confirmed by comment 31 since it seems to be SeaMonkey only and unrelated to the hardware acceleration setting.
Comment 34 Stefan [:stefanh] 2013-01-16 02:44:50 PST
Andrea & Trane:

Can you reproduce comment #14? That is, do you see the issue in DOM inspector running Firefox? Note also my comment regarding the CSS.
Comment 35 Trane Francks 2013-01-16 03:00:34 PST
I don't see the problem in any of its guises in Firefox. So far, only SeaMonkey has been plagued by repaint issues in the last stable release.
Comment 36 Stefan [:stefanh] 2013-01-16 08:52:38 PST
(In reply to Trane Francks from comment #35)
> I don't see the problem in any of its guises in Firefox. So far, only
> SeaMonkey has been plagued by repaint issues in the last stable release.

What happens if you try this:

1) Open DOM inspector in Firefox
2) Click anywhere in the right panel in order to move focus away from the textfield
3) Click outside the DOMi window (to make the window inactive)
Comment 37 Trane Francks 2013-01-16 12:43:27 PST
(In reply to Stefan [:stefanh] from comment #36)

> What happens if you try this:
> 
> 1) Open DOM inspector in Firefox
> 2) Click anywhere in the right panel in order to move focus away from the
> textfield
> 3) Click outside the DOMi window (to make the window inactive)

On this system, Firefox behaves as would be expected. Regardless of whether or not using the DOM Inspector (and ensuring a non-entry object selected), causing FF to lose focus exhibits correct repaint behaviour.

I've only seen the incorrect repaint in SeaMonkey, and with that only in v2.15.
Comment 38 Andrea Govoni 2013-01-16 22:13:19 PST
I installed the DOM Inspector 2.0.13 addon in Firefox 18.0 and it DOES exhibit the repaint issue.
Stefan, please tell me how to remove the CSS rules from Firefox and I'll perform that test, too.

Note You need to log in before you can comment on or make changes to this bug.