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.
I'm on 10.6.6 btw
Hmm, I guess this is related to bug 621762.
(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.
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?
I can reproduce this when I turn off hardware acceleration.
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.
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)
Component: Themes → Graphics
Product: SeaMonkey → Core
QA Contact: themes → thebes
Summary: Switching between active/inactive causes toolbar/statusbar to not repaint properly → [OS X] [Hardware acceleration off] Switching between active/inactive in SeaMonkey causes toolbar/statusbar to not repaint properly
Bug 615870 sounds like a good candidate for causing this.
blocking2.0: --- → ?
Hardware: x86 → All
Is this like the mac version of bug 622542 maybe?
(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
Probably because those things trigger invalidation. (blinking cursor or color change in selected text between active/inactive windows).
(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.
Summary: [OS X] [Hardware acceleration off] Switching between active/inactive in SeaMonkey causes toolbar/statusbar to not repaint properly → [OS X] [Hardware acceleration off] Switching between active/inactive causes toolbar/statusbar to not repaint properly in certain windows
I'd take a patch, but I'd release with this bug.
blocking2.0: ? → -
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?
It could be, not sure.
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)
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.
(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.
Sounds good to me!
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → WORKSFORME
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.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Target Milestone: --- → mozilla2.0
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?
(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.
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?)?
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.
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...
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.
(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.
(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.
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.
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.
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.
(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)
(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.
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.
Is this still reproducible with the current Firefox Nightly?
I can't reproduce this with 47, but I'm on 10.11 and on a different machine now. Andrea, can you reproduce this in a current nightly with hardware acceleration off (comment #38, see comment #36 for steps)?
Flags: needinfo?(stefanh) → needinfo?(xfox.mozilla)
I've just tested Firefox 48.0 on the same Mac mini Server (Middle 2010) and it behaves correctly now. I tried with DOM Inspector 220.127.116.11-signed with hardware acceleration in "Firefox" --> "Preferences" --> "Advanced" off. The only difference with the original configuration is that now it has OS X 10.10.5 (14F1909) instead of Mac OS X 10.7.5 (11G63). I see that in the meantime the software requirements for Firefox have been updated and the oldest OS X system it runs on is OS X 10.9 Mavericks… do you want that I setup a 10.9 system and repeat the test on it?  https://addons.mozilla.org/it/firefox/addon/dom-inspector-6622/
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.