Closed Bug 1451745 Opened Last year Closed Last year
Library Bookmarks visuals not painted correctly
[Affected versions]: - 59.0.2 RC, 60.0b9, 61.0a1 (2018-04-05) [Affected platforms]: - macOS 10.12.6 [Steps to reproduce]: 1. Start Firefox. 2. Open Library Bookmarks via Menu-Library-Bookmarks-Show All Bookmarks or by using (Shift+Command+B). 3. Hover the mouse over the toolbar buttons and "Search Bookmarks". [Expected result]: The visuals are loaded when library bookmarks shows up. [Actual result]: The visuals are poping up while hovering with the cursor over the buttons and search box. Check the video from the attachment. [Regression range]: I managed to find a regression for this issue: Last good 2017-12-14 First bad 2017-12-15 Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=ae78c4fe253ab2618972271350f304947b4d4994&tochange=5b18567e17374cee73f1a72ce4bbb513019c4f19 [Additional notes]: On macOS 10.13.3, this issue is not reproducible, but if using STR (1-2), the "Other Bookmarks" highlight is not rendered as it should, and by moving the mouse in Library window, the highlight gets rendered properly. On 10.10 and 10.11 the issue is not reproducible.
Here is the screencast with the actual result.
hmm, this looks like a paint invalidation issue... Not sure why it's only reproducible on OSX 10.12, but if my patch regressed it would just be uncovering a pre-existing bug.
Component: Layout: View Rendering → Layout: Web Painting
The way it's supposed to work is that DocumentStatesChanged schedules a paint if we've potentially changed our inactive state, and then during the next paint  should detect that different state and invalidate relevant themed areas. Based on the video it looks like that's not happened, and we're only invalidating the changed pixels when something else occupying the same area gets invalidated. Possibly something changes between DocumentStatesChanged and when we previously did the lazy update of mDocumentState? Or we're checking a different top-level window. I can't see how either of those are possible though.  https://searchfox.org/mozilla-central/source/layout/painting/nsDisplayList.cpp#4522
The problem is that mDocumentState is now initialized to 0 (which means active, since it doesn't include the inactive flag), even though IsTopLevelWindowInactive() is true. We paint in this state, drawing the inactive window theme colour, but DLBI records the result of GetDocumentState() (active). We then transition the new window to active, call DocumentStatesChanged, and leave mDocumentState unchanged (as active, correctly this time). The next paint now thinks that no invalidation is necessary, since the result of GetDocumentState() is unchanged between paints, and we instead slowly draw the active window theme colour as other unrelated invalidations trigger us to redraw the same pixels.
Assignee: nobody → matt.woodrow
Attachment #8968370 - Flags: review?(emilio)
Comment on attachment 8968370 [details] [diff] [review] initialize-document-state Review of attachment 8968370 [details] [diff] [review]: ----------------------------------------------------------------- Thanks for digging into this. Maybe mention in the commit message that SetContainer is the first place where IsTopLevelWindowInactive can possibly return something meaningful?
Attachment #8968370 - Flags: review?(emilio) → review+
Pushed by email@example.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/912d129db081 Initialize mDocumentState once we get a docshell. r=emilio
Please request Beta approval on this when you get a chance.
Comment on attachment 8968370 [details] [diff] [review] initialize-document-state Approval Request Comment [Feature/Bug causing the regression]: 1424816 [User impact if declined]: Incorrect colours on OSX chrome (inactive window colour instead of active) when opening new windows. [Is this code covered by automated tests?]: No. [Has the fix been verified in Nightly?]: Manually by me. [Needs manual test from QE? If yes, steps to reproduce]: No [List of other uplifts needed for the feature/fix]: None [Is the change risky?]: No. [Why is the change risky/not risky?]: Simple patch to just initialize the state when we create a window. [String changes made/needed]: None
Attachment #8968370 - Flags: approval-mozilla-beta?
Attachment #8968370 - Flags: approval-mozilla-beta? → approval-mozilla-release?
Comment on attachment 8968370 [details] [diff] [review] initialize-document-state simple patch to fix a painting issue, seems worth taking for 60 rc2
I managed to reproduce the issue using an older version of Nightly (2018-04-05) on macOS 10.12. I retested everything on the same platform using the latest Nihtly, esr60.0.0 - build 6 and Firefox 60.0 - build 2. The bug is not reproducing anymore.
You need to log in before you can comment on or make changes to this bug.