Closed Bug 1817240 Opened 1 year ago Closed 1 year ago

Dots will appear on the box-shadow

Categories

(Core :: Graphics, defect)

Firefox 111
x86_64
Windows 10
defect

Tracking

()

VERIFIED FIXED
112 Branch
Tracking Status
firefox-esr102 --- unaffected
firefox110 --- unaffected
firefox111 --- verified
firefox112 + verified

People

(Reporter: 6k64x4ma, Assigned: ErichDonGubler)

References

(Regression)

Details

(Keywords: regression)

Attachments

(8 files)

Attached file test.html

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/111.0

Steps to reproduce:

  • Load the attached file, then hover over the square.

Actual results:

  • Dots will appear on the box-shadow.

Expected results:

  • Nothing happens.

mozregression:

2023-02-17T00:17:54.687000: DEBUG : Found commit message:
Bug 1753349 (9/9): chore: update ANGLE to our fork's `firefox-111` branch r=jgilbert

Differential Revision: https://phabricator.services.mozilla.com/D162655

2023-02-17T00:17:54.693000: DEBUG : Did not find a branch, checking all integration branches
2023-02-17T00:17:54.693000: INFO : The bisection is done.
2023-02-17T00:17:54.693000: INFO : Stopped
Attached image screenshot.png
Attached file about_support.json
Keywords: regression
OS: Unspecified → Windows 10
Regressed by: angle-111
Hardware: Unspecified → x86_64
Flags: needinfo?(jgilbert)
Flags: needinfo?(egubler)

The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.

Status: UNCONFIRMED → NEW
Ever confirmed: true

FWIW, I tried this on my Win10 machine (ThinkStation), and was unable to reproduce it; I guess it's related to certain cards/drivers/some other configuration-specific thing.

See Also: → 1817333
Severity: -- → S3

I also can't repro on Windows+AMD.
Can someone try Windows+Intel?

Flags: needinfo?(jgilbert)
Flags: needinfo?(egubler)
Flags: needinfo?(ahale)

I can try on gen8 and gen11 Intel but I don't have gen9, let's see if I can repro on those at least.

Rares, do you have HD520 hardware or similar? Are you able to reproduce this at all?

Flags: needinfo?(rares.doghi)
See Also: → 1818129

Hi @Glenn, Unfortunately we dont have an Intel HD 520 but we did manage to reproduce this issue on an Intel HD 530, we also tried to reproduce this issue on our side with an Nvidia GT 730, Intel HD 630, Intel HD 2500 but it does not happen there.

On the device with Intel HD 530 we were able to reproduce this issue in Beta and Nightly only. Unfortunately we couldnt get a regression range at this time but we will try to grab one until tomorrow.

Flags: needinfo?(rares.doghi)

I can also reproduce this on a HD 530

I can repro also:

GPU #1
Active Yes
Description Intel(R) HD Graphics P530
Vendor ID 0x8086
Device ID 0x191d
Driver Version 27.20.100.9664
Driver Date 6-1-2021
Drivers igdumdim64 igd10iumd64 igd10iumd64 igd12umd64 igdumdim32 igd10iumd32 igd10iumd32 igd12umd32
Subsys ID 06e51028
RAM 0

I'll be trying a few more experiments with this bug tomorrow, I'm going to try to tickle the bug (change its behavior) with several tweaks to how WebRender is binding textures, laying out blurred shadow images in the texture atlas, and other experiments to see if I can pinpoint which shader or API call is causing the breakage on this hardware. We're trying to make a decision around Tuesday next week on whether to rollback ANGLE in Beta branch, it's valuable to keep the new ANGLE running in Nightly for testing (users expect some occasional breakage in Nightly).

Assignee: nobody → egubler
Status: NEW → ASSIGNED
Attachment #9319860 - Attachment description: WIP: Bug 1817240: Revert recent ANGLE rebase (for Beta/Release only) r=jgilbert → Bug 1817240: Revert recent ANGLE rebase (for Beta/Release only) r=jgilbert

I took the apitrace of two versions of firefox on a critical frame where artifacts occur on Intel P530 on what I believe to be the ClearView API call, and canonicalized them (renamed addresses to make the diffs identical), here is the two apitraces if one wishes to compare the text. Not much different and certainly nothing that explains why ClearView would behave differently on a rect clear of {0, 0, 364, 364}.

Here is how the artifact looks after ClearView has been called on a render target before the red rectangle is rendered into the render target, it appears to have incorrect edge masking on the right side for this rect of {0, 0, 364, 364} which instead cleared {0, 0, 360, 364} and partially mangled {360, 0, 368, 364}.

Flags: needinfo?(ahale)
Flags: qe-verify+

This issue is verified as fixed in our latest Beta Builds 111.0b7 but it still occurs in Nightly.

The bug is marked as tracked for firefox112 (nightly). However, the bug still has low severity.

:bhood, could you please increase the severity for this tracked bug? If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit auto_nag documentation.

Flags: needinfo?(bhood)

This issue is in the recent ANGLE update. That update has been removed from Beta (Fx111), and will have a fix applied to it in Nightly (Fx112).

Flags: needinfo?(bhood)

Also fix update-angle.py:

  • Use shell=True to get ninja to run
  • Don't record "/PDBSourcePath:" because it depends on configuration of
    the vendoring machine and is otherwise unused, and so uselessly causes
    blame noise.
Pushed by jgilbert@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/d7be17cdae33
Cherry-pick ANGLE skylake clearview fix. r=gfx-reviewers,lsalzman
Status: ASSIGNED → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → 112 Branch

This issue is verified as fixed in our latest Nightly 112.0a1 (2023-03-07).

Status: RESOLVED → VERIFIED
Flags: qe-verify+
Duplicate of this bug: 1817333
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: