Closed Bug 1707154 Opened 4 years ago Closed 4 years ago

Broken rendering of elements with clip-path on Wayland Linux

Categories

(Core :: Graphics: WebRender, defect)

Product:
Core
Component:
Graphics: WebRender
Version:
Firefox 88
Platform:
x86_64
Linux
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
90 Branch
Tracking Flags:
Tracking Status
firefox-esr78 --- unaffected
firefox88 --- wontfix
firefox89 --- wontfix
firefox90 --- verified

People

(Reporter: lutoma, Assigned: gw)

References

(Regression)

Details

(Keywords: regression)

Attachments

(5 files)

Testcase from reporter.
191 bytes, text/html
Details
full mozregression output
15.52 KB, text/plain
Details
macOS wide window.png
786.60 KB, image/png
Details
clip-path_ff88.png
4.00 MB, image/png
Details
Bug 1707154 - Use surface device pixel scale for image mask rects
48 bytes, text/x-phabricator-request
pascalc
: approval-mozilla-beta-
Details | Review

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:88.0) Gecko/20100101 Firefox/88.0

Steps to reproduce:

Attempt to render this test file:

<!doctype html>
<div></div>
<style>
body {
height: 200vw;
}

div {
background: rebeccapurple;
height: 100vh;
clip-path: polygon(50vw 0, 100vw 50vh, 50vw 100vh, 0 50vh);
}
</style>

Actual results:

A broken partial rendering of the element, with flickering when scrolling/switching tabs/otherwise interacting with it.

Screenshots (External host since I can only attach one in Bugzilla it seems):

Expected results:

A stable render of the element. This used to work in Firefox 87 with Wayland enabled, so this is a regression.

Keywords: regression
OS: Unspecified → Linux
Hardware: Unspecified → x86_64

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → Widget: Gtk
Product: Firefox → Core

It works as expected here on Nightly (with and without wayland).

Is there any chance you could install mozregression (with pip install --user mozregression) and run mozregression --good 87 --bad 88 -a https://bugzilla.mozilla.org/attachment.cgi?id=9217938, to figure out what broke this for you?

Alternatively, can you attach the contents of your about:support page? Thanks!

Flags: needinfo?(hello)

Final lines of the mozregression output:

7:48.12 INFO: Narrowed integration regression window from [3e627b12, 14fac67d] (3 builds) to [3e627b12, c7760ee4] (2 builds) (~1 steps left)
7:48.12 INFO: No more integration revisions, bisection finished.
7:48.12 INFO: Last good revision: 3e627b1236768fa8fa9fe915c7fdab32f96670ab
7:48.12 INFO: First bad revision: c7760ee4f8e2f5f2d263067b7a206c976a188d0b
7:48.12 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=3e627b1236768fa8fa9fe915c7fdab32f96670ab&tochange=c7760ee4f8e2f5f2d263067b7a206c976a188d0b

Looking at the commit in question, it does change some WebRender gfx code to fix bug #1696301, so it seems plausible to me that it could case the issue (but I know nothing about Firefox internals).

During testing I've also noticed that the issue only seems to appear if the Firefox window is wider than ~2000 pixels (window.outerWidth) / ~4000 rendered pixels (High-DPI screen).

Flags: needinfo?(hello)

Yeah, that sounds like a patch that could cause this, I think. Glenn is on PTO, Brad, any chance you could take a look since you reviewed the change? Thanks!

Component: Widget: Gtk → Graphics: WebRender
Flags: needinfo?(bwerth)
Regressed by: 1696301
Has Regression Range: --- → yes

(I could repro by making a giant window, indeed :))

Status: UNCONFIRMED → NEW
Ever confirmed: true

I noticed the commit in question talks about device pixel ratios, so I fiddled with my window manager (Gnome 40) settings a bit and noticed this bug only happens when fractional scaling is used. I usually use 150% scaling with my 4K screen. If I change that to 100% or 200% the issue disappears.

Set release status flags based on info from the regressing bug 1696301

status-firefox88: --- → affected
status-firefox89: --- → affected
status-firefox90: --- → affected
status-firefox-esr78: --- → unaffected
Severity: -- → S3
Attached image macOS wide window.png —

Confirmed I can replicate on macOS with a window wider than the screen. No manipulation of screen scaling seems to be necessary.

I've confirmed that the bad behavior starts as soon as the surface_device_pixel_scale passed to ClipBatcher::add drops below 1.0 (and the global scale is at 1.0, in my case).

Same here, OS X Big Sur, FF 88.0 & 88.0.1
Happens on a 4K screen if the window is bigger than ~2000px

Attached image clip-path_ff88.png —

Example
Source: https://www.salz.ch/en

Glenn will probably need to determine the right fix for this.

Flags: needinfo?(bwerth) → needinfo?(gwatson)

I have been unable to reproduce this so far on a mac (+/- external 4k screen) and an ubuntu wayland + 4k and kde + 4k setup with the current nightly. Are there any tricks / interactions that make it more likely to occur? Can anyone else confirm it's still occurring for them with a current nightly?

Flags: needinfo?(gwatson) → needinfo?(hello)

I can still reproduce on macOS using 2x scaled 1920 x 1200 resolution with these steps:

  1. View attachment 9217938 [details].
  2. Resize the window as wide as you can while still fitting on the screen.
  3. Move the window partially off the screen to the right.
  4. Widen the window further by dragging the left side of the window.

Ah, yes I can reproduce locally with those steps. I'll take a look today, thanks!

Flags: needinfo?(hello)
Assignee: nobody → gwatson
Status: NEW → ASSIGNED
Pushed by gwatson@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/0550c8167462 Use surface device pixel scale for image mask rects r=gfx-reviewers,bradwerth

https://hg.mozilla.org/mozilla-central/rev/0550c8167462

Status: ASSIGNED → RESOLVED
Closed: 4 years ago
status-firefox90: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → 90 Branch

The patch landed in nightly and beta is affected.
:gw, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.

Flags: needinfo?(gwatson)

Comment on attachment 9221474 [details]
Bug 1707154 - Use surface device pixel scale for image mask rects

Beta/Release Uplift Approval Request

  • User impact if declined: Rendering glitch under certain circumstances. This is a fairly small patch to uplift, but it's also fairly rare, so it's not critical to uplift if we're getting close to merge day.
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: Yes
  • If yes, steps to reproduce: Per bug
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Change is very small and only affects a small number of configurations.
  • String changes made/needed:
Flags: needinfo?(gwatson)
Attachment #9221474 - Flags: approval-mozilla-beta?
Flags: qe-verify+
QA Whiteboard: [qa-triaged]

Comment on attachment 9221474 [details]
Bug 1707154 - Use surface device pixel scale for image mask rects

We have only one beta left and this is fixing an edge case for a subset of our end users, I think it is a good candidate to ride the 90 train, thanks.

Attachment #9221474 - Flags: approval-mozilla-beta? → approval-mozilla-beta-

I can confirm the bug on Fx 88.0.1 using Ubuntu 18.04 Wayland and MacOS 11.2.3 on 4k monitor(webrender on).
Verified -Fixed in the latest Nightly 90.0a1 using Ubuntu 18.04 Wayland and MacOS 11.2.3 on 4k monitor(webrender on).

Status: RESOLVED → VERIFIED
QA Whiteboard: [qa-triaged]
status-firefox90: fixed → verified
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: