1693675 - WebRender reftest failures with non-native theme enabled

Status: RESOLVED FIXED

(Core :: Graphics: WebRender, defect, P2)

Description

[Stephen A Pohl [:spohl]]

With the non-native theme enabled, we're running into strange reftest failures.

513153-2a.html fails on Windows and macOS.
513153-2b.html fails on macOS.

Windows reftest analyzer links:
Windows 10 x64 WebRender opt
Windows 10 x64 WebRender debug
Windows 10 x64 WebRender debug

macOS reftest analyzer links:
OS X 10.14 WebRender opt
OS X 10.14 WebRender debug

I'm going to attach a test case that illustrates the issue shortly.

Comment 1

[Stephen A Pohl [:spohl]]

Attachment: 513153-2a.html with click listener

Comment 2

[Stephen A Pohl [:spohl]]

Attachment: 513153-2b.html with click listener

Comment 3

[Stephen A Pohl [:spohl]]

I have uploaded copies of the actual reftest, with the only difference being that we are now listening to click events instead of MozReftestInvalidate to help illustrate the problem. As the reftest analyzer links make clear, the issue seems to be that the text within the buttons is slightly shifted in the reference (or rather, the button itself has technically shifted, giving the impression of more padding before the text label in the reference than in the test). I have confirmed via the inspector that the padding and border values are correct for both the reference and the test. We have fuzzy-if declarations for both of these tests, but the reason why I didn't simply go ahead and adjust those for the non-native theme is because of the following:

1. Open test.
2. Click anywhere in the window, but not on the button itself.
3. Now hover your mouse over the button.

Notice how the button immediately shifts as soon as the button is hovered. I think that this might reveal an underlying issue with WebRender (possibly more, if the existing fuzzy declarations are hiding the issue on non-WebRender test scenarios). Markus, even though I can adjust the fuzzy declarations here, are you able to take a look and see if there is an underlying issue in WebRender? We could potentially unblock non-native theming by adding appropriate fuzzy declarations, but it seems to make sense to have this looked at from a WebRender perspective even if we make these tests pass for now.

Comment 4

[Markus Stange [:mstange]]

I'd say this is a fallback invalidation problem. WebRender caches the rendering of the button. Then the button moves, and ends up at a different fractional x coordinate. This affects snapping of the button drawing. However, WebRender does not invalidate the button and keeps the wrongly-snapped cached rendering.

Note that I cannot reproduce this at 100% zoom on a HiDPI display. I had to zoom out to 50% (simulating 1x rendering) before I could reproduce the bug.

Edit: replaced "blob invalidation" with "fallback invalidation", which is more accurate. Theme rendering doesn't go through the SVG blob invalidation path, it goes through the WebRenderCommandBuilder::GenerateFallbackData path.

Comment 5

[Jeff Muizelaar [:jrmuizel]]

Stephen, does this reproduce on Linux?

Comment 6

[Stephen A Pohl [:spohl]]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #5)

Stephen, does this reproduce on Linux?

Based on try runs, I don't believe so. There are also no fuzzy declarations in the reftest.list for these tests other than fuzzy-if(!nativeThemePref,0-1,0-4) == 513153-1a.html. I don't have a linux system set up to test it out locally. Do you want me to kick off a try build with that fuzzy-if declaration removed for 513153-1a.html to see if Linux is also affected in some way? The ranges of 0-1 and 0-4 make me think that the button probably never shifted as much as we're seeing on Windows and macOS.

Comment 7

[Markus Stange [:mstange]]

The amount by which the button is shifted once the text goes away depends on the width of the text, which depends on font metrics. I think it should be possible to make a testcase that fails on Linux by using a display: inline-block element instead of the text, and setting the correct fractional width on it.

Comment 8

[Jeff Muizelaar [:jrmuizel]]

A linux reproduction would very handy for debugging.

Comment 9

[Stephen A Pohl [:spohl]]

Attachment: Bug 1693675: Designate 513153-2a.html and 513153-2b.html as expected fails when the non-native theme is enabled while we investigate and fix the underlying webrender bug. r=mstange

Comment 10

[Stephen A Pohl [:spohl]]

I'll try to put together the test case mentioned in comment 7. In the meantime I think it makes sense to disable these two tests to unblock the landing of non-native theming, but we should revert this change once we have a fix here.

Comment 11

[Stephen A Pohl [:spohl]]

Actually, before I spend time doing so, could you check if attachment 9204085 [details] reproduces the issue for you on Linux? Maybe at different zoom levels? Thank you

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/88fd90058919
Designate 513153-2a.html and 513153-2b.html as expected fails when the non-native theme is enabled while we investigate and fix the underlying webrender bug. r=mstange

Comment 13

[Noemi Erli[:noemi_erli]]

https://hg.mozilla.org/mozilla-central/rev/88fd90058919