Closed Bug 941559 Opened 6 years ago Closed 6 years ago
On OSX inactive windows are only partially repainted when :-moz-window-active changes, affecting Australis private inactive windows
53.09 KB, image/png
52.02 KB, image/png
1.04 KB, patch
|Details | Diff | Splinter Review|
2.66 KB, patch
|Details | Diff | Splinter Review|
No description provided.
Sorry, hit ENTER too soon without giving a text... STR: - Open a new private window - Switch to another window (e.g. open About Nightly), while the private window is still visible, but inactive in the background. --> Colors aren't correct as the screenshots depict, neither in normal nor in native full-screen mode.
Nils, I can't reproduce it :( Which version of OSX are you using?
Status: NEW → UNCONFIRMED
Ever confirmed: false
Hmm, I can see it flashing, but it looks OK after a repaint.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OSX Lion. Latest nightly the update service spit at me: Built from http://hg.mozilla.org/mozilla-central/rev/597287004ff5
(In reply to Mike de Boer [:mikedeboer] from comment #3) > Hmm, I can see it flashing, but it looks OK after a repaint. It doesn't just flash for me. It stays that way till the window gets focus again.
Turns out this seems to be a layout bug that is very similar to bug 833033. I think stuff regressed in the meantime. Just scheduling a paint of the frame is not enough when the window active state changes to inactive. Unless something else triggers invalidation, the repaint will only redraw parts of the window where there is affected "content", but not the actual window background. One way to deal with this is to just invalidate the whole frame if the window state changes to inactive.
Component: Theme → Layout
Product: Firefox → Core
Summary: On OSX inactive private Australis windows use the wrong colors for some elements. → On OSX inactive windows are only partially repainted when :-moz-window-active changes, affecting Australis private inactive windows
Invalidating the rect works for me. However, I'm a total layout n00b and have no clue what I'm actually doing here ;)
Attachment #8336013 - Flags: review?(roc)
Why is the window background change not being picked up? Do we need to restyle, not just schedule a paint?
That patch basically reverts bug 532828, which should not be the goal here :) I see the same problem when I set style="background-color: red" on the private browsing window using the DOM Inspector, with no focus change involved. Seems more like a DLBI problem to me.
I got curious, and found a way to reproduce the partial paint without relying on focus changes: If you do the following: - Open a new regular browser window - DOM Inspector it - Set #main-window background-color to red (to make it more obvious) - Set #titlebar -moz-appearance to none Then the whole area gets redrawn as expect. But if you switch the order: - Open a new regular browser window - DOM Inspector it - Set #titlebar -moz-appearance to none - Set #main-window background-color to red (to make it more obvious) Then the area only gets partially redrawn where there are other frames, same way as in my screenshots. Making the window active or inactive actually does nothing. To figure out if the defining thing is #titlebar -moz-appearance, or just a non-transparent #titlebar background in general I furthermore tried the following: - Open a new regular browser window - DOM Inspector it - Set #titlebar -moz-appearance to none - Set #titlebar background-color green - Set #main-window background-color to red (to make it more obvious) - Remove #titlebar background-color again. Turns out this makes it display correctly as well. So the problem here seems to be that a window will not invalidate the areas not covered by something else when the background-color of the window (root frame/layer/display item/whatever?) itself is changed.
Attachment #8336013 - Flags: review?(roc) → review-
This is odd, there's nothing particularly special about the root background as far as DLBI is concerned, as far as I know.
And this bug doesn't seem to affect Linux.
This is because the display item that is changing colour isn't a nsDisplayThemedBackground, it's an nsDisplaySolidColor. The frame that we use to compute this background color (in PresShell::UpdateCanvasBackground) isn't the same as the frame we use for the nsDisplaySolidColor (in PreShell::AddCanvasBackgroundColorItem). DLBI can't know that the former being marked as invalid should invalidate the pixels for the latter. I'm not sure how (or if we even want) to fix this, so I'll just make nsDisplaySolidColor compare the colour that it's going to draw, and invalidate if it changes. Sound good?
The frame we're using for the style is nsDocElementBoxFrame*, and the nsDisplaySolidColor is created for the ViewportFrame*
Comment on attachment 8336576 [details] [diff] [review] Invalidate for color changes with nsDisplaySolidColor Fixes the drawing for me.
Attachment #8336576 - Flags: feedback+
Attachment #8336576 - Flags: review?(roc) → review+
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla28
Comment on attachment 8336576 [details] [diff] [review] Invalidate for color changes with nsDisplaySolidColor Bug 950224 alerted me to the fact that this bug is still present on the 27 branch, we should try to get the fix uplifted. [Approval Request Comment] Bug caused by (feature/regressing bug #): bug 532828 User impact if declined: strange titlebar appearance in private browsing windows when changing window focus Testing completed (on m-c, etc.): three weeks on mozilla-central Risk to taking this patch (and alternatives if risky): low String or IDL/UUID changes made by this patch: none
Attachment #8336576 - Flags: approval-mozilla-beta?
Attachment #8336576 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Add missing nsColor.h #include to nsDisplayListInvalidation.h to fix bustage. https://hg.mozilla.org/releases/mozilla-beta/rev/7736d6971bc3
Whiteboard: [Australis:P1] → [Australis:P1][good first verify]
You need to log in before you can comment on or make changes to this bug.