1791495 - Intermittent vertical lines in web content, tab titles, and address bar search suggestions (with SWGL)

Status: VERIFIED FIXED

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

Description

[Chris Peterson [:cpeterson]]

Attachment: tab_screenshot.png

Starting on 2022-09-17 and every day since, a few times an hour, I intermittently see a vertical white line in some tab titles and address bar search suggestions. See the attached screenshot of a tab title.

I don't have reliable STR, but the white line seems to appear when the tab is loaded (or reloaded) and sometimes disappears after a couple seconds.

I think this bug might be related to SWGL, but is SWGL used to render tab titles and address bar search suggestions? I usually run with gfx.webrender.software = true (to help dogfood test SWGL). After I saw the white line a couple times in just a few minutes today, I reset gfx.webrender.software = false (and restarted Nightly) and didn't see a white line for 15 minutes after that.

Comment 1

[Chris Peterson [:cpeterson]]

Correction: the lines aren't always white. They're white on tabs opened in the background (where their tab background color is dark) and they're dark on foreground tabs (where the tab background color is white).

Comment 2

[Chris Peterson [:cpeterson]]

This might not be a recent regression. I tried to bisect with mozregression, but I see this bug or a similar one in builds at least as old as Nightly 100.0a1 (build 2022-04-01). I can try to continue bisecting.

Here are STR to reproduce the bug:

1. Enable SWGL: set gfx.webrender.software = true and restart Firefox.
2. In about:addons, set the theme to "Alpenglow". (I can reproduce with other themes with a color background, but Alpenglow is conveniently preinstalled.)
3. Open a new window and open https://example.com/ in two tabs.
4. Cmd+click both tabs to select them.
5. Quickly reload the pages using the Cmd+R keyboard shortcut. After a few seconds, I see vertical lines in the tab titles. Sometimes the lines disappear quickly. Sometimes they remain until another tab is selected.

Comment 3

[Chris Peterson [:cpeterson]]

I see this bug on macOS but not Windows (even though I have SWGL enabled on both).

Comment 4

[Sotaro Ikeda [:sotaro]]

:lsalzman, can you comment to the bug?

Comment 5

[Pascal Chevrel:pascalc]

Glenn, could the priority and severity fields be set for this regression? Should we care for our releases in flight? Thanks!

Comment 6

[Glenn Watson [:gw]]

Lee, thoughts on what the priority / severity for this should be? Do we have any other similar reported SWGL bugs?

Comment 7

[Chris Peterson [:cpeterson]]

Attachment: about_support.txt

I can reproduce some variation of this bug at least as far back as Nightly 84 (November 2020). If this bug had been happening for two years, I probably would have reported it sooner, but I think I first noticed it only a few weeks ago. That's suspiciously close to when I updated my MacBook Air (M2) from macOS 12.5 to 12.6. The release date for macOS 12.6 was 2022-09-12 and I filed this bug on 2022-09-19 after having seen this bug for at least a few days. Perhaps there is a regression in macOS 12.6 related to SWGL's use of OpenGL?

Here is my about:support info.

EDIT: I just updated from macOS 12.6 to 13.0 and I can still reproduce this bug.

Comment 8

[Chris Peterson [:cpeterson]]

Attachment: button_screenshot.png

I found different STR for a similar "white line in content with SWGL" bug on macOS 12.6:

1. Set gfx.webrender.software pref = true and restart Firefox.
2. Load https://www.usaa.com/my/logon
3. Enter some text in the "Online ID" text field. (This step might not be necessary, but the bug is intermittent so it's hard to tell.)
4. Zoom the page to 110% using Cmd + =.
5. The green "Next" button might have a white line now.
6. If now, then try scrolling the page up and down using the touch pad swipe gesture.
7. Within a 5-10 seconds, the green "Next" button might have a white line now.

I tried bisecting this bug a few times using mozregression, but the results were inconsistent because the bug is intermittent. One time I ended on a 2021-02-27 regression range that included SWGL cs_clip_rectangle shader bug 1682194, which seems like it could be related to this bug.

Comment 9

[Lee Salzman [:lsalzman]]

(In reply to Chris Peterson [:cpeterson] from comment #7)

Created attachment 9297678 [details]
about_support.txt

I can reproduce some variation of this bug at least as far back as Nightly 84 (November 2020). If this bug had been happening for two years, I probably would have reported it sooner, but I think I first noticed it only a few weeks ago. That's suspiciously close to when I updated my MacBook Air (M2) from macOS 12.5 to 12.6. The release date for macOS 12.6 was 2022-09-12 and I filed this bug on 2022-09-19 after having seen this bug for at least a few days. Perhaps there is a regression in macOS 12.6 related to SWGL's use of OpenGL?

Here is my about:support info.

EDIT: I just updated from macOS 12.6 to 13.0 and I can still reproduce this bug.

Is it that you're building the binaries on macOS 12.6? i.e. if you took the binaries from there and tried running them on an older macOS version, does it repro? Or the reverse, is this the OS version that is the causative factor here and not the build toolchain?

I can't seem to get any of these to repro on Linux at all with SW-WR, for instance.

Comment 10

[Chris Peterson [:cpeterson]]

.

Comment 11

[Chris Peterson [:cpeterson]]

(In reply to Lee Salzman [:lsalzman] from comment #9)

EDIT: I just updated from macOS 12.6 to 13.0 and I can still reproduce this bug.

Is it that you're building the binaries on macOS 12.6? i.e. if you took the binaries from there and tried running them on an older macOS version, does it repro? Or the reverse, is this the OS version that is the causative factor here and not the build toolchain?

I'm running regularly Nightly builds, not my own local builds. I just meant that:

1. I think I first started seeing this bug after updating my OS from macOS 12.5 to 12.6. (comment 8)
2. And that I can still repro the bug after updating my OS to macOS 13.0, so it wasn't fixed by any Apple bug fixes in macOS 13.0.

I can't seem to get any of these to repro on Linux at all with SW-WR, for instance.

Even though this is a SW-WR, I think this bug is Mac only. I can reliably repro on Mac, but I can't repro on Windows. (I don't have a Linux machine to test.)

Comment 12

[Chris Peterson [:cpeterson]]

I was not able to repro with my STR from comment 2 on an Intel MacBook Pro running macOS 12.6. I think this suggests the bug might be related to some Intel vs ARM64 difference in macOS 12.6:

CPU Architecture	OS	Repro?
ARM64 (M2)	macOS 12.5	I don't remember, but I like to think I would have filed a bug back then if I had seen this problem with macOS 12.5.
ARM64 (M2)	macOS 12.6	Yes
ARM64 (M2)	macOS 13.0	Yes
Intel	macOS 12.6	No
Intel	Windows 11	No
ARM64 (Surface Pro X SQ1)	Windows 10	No
ARM64 (Surface Pro X SQ2)	Windows 11	Yes

Comment 13

[Chris Peterson [:cpeterson]]

Attachment: Alpenglow_tab_screenshot.png

Screenshot of the STR in comment 2.

Comment 14

[Shane Hughes [:aminomancer]]

I just tested on Windows 10 on a Surface Pro X with and without gfx.webrender.software and I don't see any lines.
Edit: To be clear, that device has a Microsoft SQ1, which is a Snapdragon 8cx variant. So this is a Windows ARM64 platform.

Comment 15

[Chris Peterson [:cpeterson]]

Hal Wine says he can repro this bug with gfx.webrender.software on his ARM64 Windows machine. He tested Firefox Nightly build ID 20221031095213 on a Microsoft Surface Pro X SQ2 running Windows 11.

Toggling gfx.webrender.software.d3d11 has no affect on the bug.

Comment 16

[Chris Peterson [:cpeterson]]

I added Shane's and Hal's test results to my table in comment 12.

Comment 17

[Shane Hughes [:aminomancer]]

Do the lines only appear in that specific location on the tab?

Edit: I mean like, in the text area

Comment 18

[Sören Hentzschel]

To copy my comment from https://bugzilla.mozilla.org/show_bug.cgi?id=1797622#c5 because the same applies here:

I can reproduce this issue if I run Windows 11 via Parallels Desktop on my M1 Pro MacBook Pro with macOS 13 (macOS 12 was also affected, I see this issue since the first day I use Parallels, June 30th), but only in Firefox 106.0.2, not in Firefox Nightly. And if I try mozregression I can not reproduce in builds that are older than 106a1. I can also not reproduce if I use the profile from 106.0.2 on Nightly. And I can also not reproduce directly on my MacBook Pro with Software WebRender.

Bug 1797622 has my output from about:support from the affected installation.

Comment 19

[Chris Peterson [:cpeterson]]

(In reply to Shane Hughes [:aminomancer] from comment #17)

Do the lines only appear in that specific location on the tab?

Edit: I mean like, in the text area

I usually see the lines in the tabs, usually on the right end of the right-most tab. See my screenshot in comment 13. (Maybe this is related to the tab's loading animation?)

But less frequently, I see some vertical lines in web content. See my screenshot in comment 8. I don't think I've seen the exact rendering issues shown in bug 1797622.

Comment 20

[Sören Hentzschel]

I usually see the lines in the tabs, usually on the right end of the right-most tab. See my screenshot in comment 13. (Maybe this is related to the tab's loading animation?)

For me the position of the lines depend on the position of the tabs in the tab strip. After moving the tabs other positions are affected. I also often see the lines on the left side, sometimes there are even two lines in one tab.

Comment 21

[Sören Hentzschel]

I captured my screen to demonstrate what I wrote in my last comment:
https://www.youtube.com/watch?v=7FQGAmynJ6o

Comment 22

[Lee Salzman [:lsalzman]]

Jeff, are you able to repro this on an ARM64 machine? Release vs. nightly?

Comment 23

[Jeff Muizelaar [:jrmuizel]]

Yeah, I can reproduce this using the STR in comment 2. It's been around as far back as 89 (when Proton was enabled in bug 1700109)

Comment 24

[Lee Salzman [:lsalzman]]

Attachment: Bug 1791495 - Check for zero sqrt on ARM. r?jrmuizel

For SWGL on ARM, we implement sqrt(N) as N * inversesqrt(N). This means we don't
properly handle zero unless we explicitly check for it. Otherwise, a NaN ends up
getting produced erroneously.

Comment 25

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/0e49af3e735f
Check for zero sqrt on ARM. r=jrmuizel

Comment 26

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/0e49af3e735f

Comment 27

[Chris Peterson [:cpeterson]]

Verified fixed on macOS in Nightly build 20221103095349. I don't have an ARM64 Windows machine to test.

Comment 29

[Ryan VanderMeulen [:RyanVM]]

Please nominate this for ESR102 approval when you get a chance. It grafts cleanly.

Comment 30

[Lee Salzman [:lsalzman]]

Comment on attachment 9301698 [details]
Bug 1791495 - Check for zero sqrt on ARM. r?jrmuizel

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: Visual artifacts in page content and browser chrome.
• User impact if declined: Visual artifacts.
• Fix Landed on Version: 108
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky):

Comment 31

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9301698 [details]
Bug 1791495 - Check for zero sqrt on ARM. r?jrmuizel

Approved for 102.6esr.

Comment 32

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr102/rev/afca188a6ea5

Comment 33

[Ina Popescu, Desktop QA]

I was able to reproduce the issue with Firefox Nightly 106.0a1 on macOS Ventura 13.1 by following the STR provided in Comment 2.
The issue is fixed and no longer reproduceable on Firefox 108.0b9 and Firefox 102.5.0esr under the same system.