Open Bug 1780627 Opened 5 months ago Updated 1 month ago

Elements with border-radius sporadically paint with background missing

Categories

(Core :: Graphics: WebRender, defect)

Firefox 102
defect

Tracking

()

Tracking Status
firefox-esr91 --- unaffected
firefox-esr102 --- wontfix
firefox104 --- wontfix
firefox105 --- wontfix
firefox106 --- wontfix
firefox107 --- wontfix
firefox108 --- wontfix

People

(Reporter: scott.glazer, Unassigned)

References

(Regression)

Details

(Keywords: regression)

Attachments

(1 file)

Steps to reproduce:

  1. Visit this jsfiddle https://jsfiddle.net/wa8jh2r6/4/

Or make a new jsfiddle with the following sources
--- HTML ---
<p>
Try moving your mouse into and out of the circle. If it shows with a white fill, that seems like a browser bug.
</p>
<div class="circle">
--- CSS ---
.circle {
width: 50px;
height: 50px;
border-radius: 25px;
border: 2px solid #222;
background-color: #00A;
}

.circle:hover {
border: 2px solid #223;
}

Move the mouse cursor in an out of the circle. You may have to reload the page to see the issue, or be patient experimenting moving the mouse around in different ways.

Notes:
I have used the mozregression tool to track down when this started happening. Here are the results from that:

app_name: firefox
build_date: 2021-12-13 21:46:15.245000
build_file: C:\Users\scottg.mozilla\mozregression\persist\d6e8528f0a93-shippable--autoland--target.zip
build_type: integration
build_url: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/Yt8I41RESluJZRk39F2RMw/runs/0/artifacts/public%2Fbuild%2Ftarget.zip
changeset: d6e8528f0a936df88369c71f4e390e31a4d621a1
pushlog_url: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=383986e2f5cb835a55c47bbd6e15d81035ca0784&tochange=d6e8528f0a936df88369c71f4e390e31a4d621a1
repo_name: autoland
repo_url: https://hg.mozilla.org/integration/autoland
task_id: Yt8I41RESluJZRk39F2RMw

I looked into that a little and it appears it happened when Fission was enabled. And indeed, if I disable fission by setting my about: config fission:autostart value to false, the bug no longer reproduces.

(I have a slightly more complex version of this involving a transform as well as border-radius that does still reproduce with fission disabled. I still wanted to report this very simple case first. I will attempt further bisection runs to see if that is a regression as well, and either write up an additional bug or amend this one.)

Actual results:

The circle sometimes loads with a white fill. Usually it loads OK, but sometimes it flashes white as you mouse over it. Sometimes it remains white for more than just a flash, too.

Expected results:

The circle should always render with a blue fill, never white

Summary: Elments with border-radius sporadically paint with background missing → Elements with border-radius sporadically paint with background missing

Additional information:

Just adding a simple CSS transform to the transform causes it to remain broken even with fission disabled. See https://jsfiddle.net/tke0r45d/ for that version, or simply add transform: translate(5px, 5px); to the CSS. (I didn't have luck trying to bisect this one, which seems to go back years and can take a long effort to reproduce especially in older builds).

This bug is affecting our product/page and any workaround for it would be greatly appreciated.

Looking at this a little more, the fact that jsfiddle uses an iFrame may be muddying the water some (and I suspect it's why fission being enabled changes things). Here's a self-contained HTML page that can demonstrate the problem, though I do find reproducing it with this to be a little harder than using the jsfiddle. Load this page in Firefox and try moving the mouse in and out and around the circle a lot, maybe trying some clicks too. Once in a while, the circle renders without the fill.

<html>
<head>
<style>
 .circle {
   width: 50px;
   height: 50px;
   border-radius: 25px;
   border: 2px solid #222;
   background-color: #00A;
   transform: translate(115px, 5px);
 }

 .circle:hover {
    border: 2px solid #223;
 }
</style>
</head>
<body>
<div class="circle">
</body>
</html>

Hi,

I wasn't able to reproduce the issue myself on Firefox 102 or Firefox Nightly 104.0a1 but I'm going to set a component in order to involve the development team in reviewing this issue.

Thank you for looking into the issue!

Status: UNCONFIRMED → NEW
Component: Untriaged → CSS Parsing and Computation
Ever confirmed: true
Product: Firefox → Core

I can't repro either, but this seems more of a graphics issue.

Component: CSS Parsing and Computation → Graphics: WebRender

The severity field is not set for this bug.
:gw, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(gwatson)

I also cannot reproduce at all on current release or nightly, so it seems that it's likely something very specific to your local installation, or hardware / OS / driver. Could you post the contents of your about:support here and also check if it occurs for you in a currently nightly build?

Flags: needinfo?(gwatson) → needinfo?(scott.glazer)
Attached file My about:support data
It does happen for me with the current nightly. Let me know if you'd like a link to a video of it. My co-workers also reproduce it, so while it might be specific to some configuration, it's not just some weirdness with my specific machine.

It does happen for me with the current nightly. Let me know if you'd like a link to a video of it. My co-workers also reproduce it, so while it might be specific to some configuration, it's not just some weirdness with my specific machine.

I have attached my about: support data to the issue.

Flags: needinfo?(scott.glazer)

Thanks. A video might be helpful, perhaps we're not doing the right steps to repro it (though it seems unlikely).

A couple of other things that would be useful information if you could test for us while we can't repro locally, and let us know if they have any effect:

  1. In about:config change gfx.webrender.compositor to false, then restart the browser, and see if it occurs (then reset that option and restart browser).

  2. In about:config change gfx.webrender.software to true then restart the browser, and see if it occurs (then reset that option and restart browser).

Flags: needinfo?(scott.glazer)

The bug still reproduces for me with gfx.webrender.compositor=false.
The bug does not reproduce for me with gfx.webrender.software=true.

Here's a video. If you skip to about 33 seconds there's a clear shot of the bug. https://www.loom.com/share/61ad4186add6454180e3103d0acff7bb

Flags: needinfo?(scott.glazer)

That suggests it might be a driver bug, if it only occurs when running hardware accelerated webrender, which might also explain why we're having trouble reproducing it.

Your about:support reports that it's a dual GPU system:

    "adapterDescription": "Intel(R) Iris(R) Xe Graphics",
    "driverVersion": "27.20.100.9749",
    "driverDate": "6-24-2021",
    "adapterDescription2": "NVIDIA GeForce MX450",
    "driverVersion2": "30.0.15.1169",
    "driverDate2": "2-1-2022",

It looks like the Intel GPU is what's active for Firefox in this case. Are your co-workers also running the same hardware (and driver version)?

The date on the Iris driver does seem a bit old - it's possible that updating the driver may fix this issue (though it can sometimes be difficult as Windows Update may not supply the latest manufacturer driver depending on the OEM).

Flags: needinfo?(scott.glazer)

Checking with one of my reproducing co-workers, yeah, he's running on the same Dell Laptop and does have those exact same graphics drivers. I can believe it's a driver bug. (I am relieved to know this issue isn't easily reproduced or widespread and so will likely not widely affect our customers.) I'm not up for the struggle to update my drivers right now.

Flags: needinfo?(scott.glazer)

My other coworker also has a Dell laptop and the same version of the Intel(R) Iris(R) Xe Graphics driver.

The severity field is not set for this bug.
:gw, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(gwatson)
Severity: -- → S4
Flags: needinfo?(gwatson)

Setting Regressed by field after analyzing regression range found by mozregression in comment #0.

Regressed by: 1732358

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

:nika, since you are the author of the regressor, bug 1732358, could you take a look?

For more information, please visit auto_nag documentation.

Not helpful bot.

Flags: needinfo?(nika)

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

You need to log in before you can comment on or make changes to this bug.