1787010 - Throbber/spinner image has an unexpected fringe, in DevTools debugger "Find in all files"

Status: NEW

(Core :: Graphics: WebRender, defect)

Description

[Daniel Holbert [:dholbert]]

Attachment: screenshot (notice the square around the throbber-circle in the searchbar)

What were you doing?

1. Visit https://us.gozney.com/blogs/recipes/
2. Open devtools debugger (e.g. F12 and then click "Debugger" tab)
3. Press the key-combo for "Find in all files" (ctrl+shift+f for me)
4. Type a string like "def" and hit Enter. ("def" is nice because it triggers lots of hits for "default")

What happened?

A circular throbber spinner-image appears at the right edge of the searchbar; it renders with an unexpected square "frame" around it (which also spins). See attached screenshot (and upcoming screencasts).

What should have happened?

No square frame.

Anything else we should know?

• I'm using Nightly 106.0a1 (2022-08-24) (64-bit) on Ubuntu 22.04
• I don't have any pixel scaling (not high-DPI/retina). i.e. my window.devicePixelRatio is 1. Haven't tested with other DPI configurations / pixel ratios yet; but I can imagine this might go away with higher pixel ratios (otherwise I imagine we would have noticed & fixed this by now).
• I can reproduce in a fresh profile. It's a bit more noticeable with a dark theme, but you can see it very-clearly with a light theme as well.
• This seems to be a regression. In builds from before the regression, I occasionally see a very tiny amount of a similar fringey artifact, but it's just a few pixels rather than a full square.

Comment 1

[Daniel Holbert [:dholbert]]

Regression range:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=683c2a81d1a3230a9b2ae93162277244a99d4921&tochange=33143ef17c70c76f39ac75fe51d3ae9342365845

Nothing there jumps out as obviously-related. I don't see anything devtools related, but I do see this which looks like it might have changed our invalidation behavior in a way that could conceivably have caused something like this:

Glenn Watson — Bug 1706801 - Invalidate dirty rect state when an external compositor surface is removed r=gfx-reviewers,lsalzman

If that is the relevant commit, I'm not sure offhand whether that means this is a Gecko/WebRender bug vs. a frontend bug in our styling for this throbber-image that just became more-obvious; e.g. if we're not specifying a sufficiently tight crop on some sprite-sheet or something like that.

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: screencast of bug

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: screencast of expected behavior (before regression)

Comment 4

[Daniel Holbert [:dholbert]]

Attachment: more-severe screencast of bug

Comment 5

[Daniel Holbert [:dholbert]]

Yeah, looks like this is probably a WebRender bug, likely a regression from bug 1706801. --> Reclassifying as such.

Conveniently, the first-bad Nightly (2021-04-22) is from back when WebRender was still configurable via about:config. And if I launch that Nightly with WebRender force-disabled, I can't repro the issue.

Specifically, I can repro the bug if I launch Firefox like so:

mozregression --pref "security.sandbox.content.level:0" \
  --launch 2021-04-22 -a https://us.gozney.com/blogs/recipes/

...but I cannot repro if I launch like so (adding "gfx.webrender.force-disabled:true"):

mozregression --pref "security.sandbox.content.level:0" "gfx.webrender.force-disabled:true" \
  --launch 2021-04-22 -a https://us.gozney.com/blogs/recipes/

(Side note: if you're wondering about the security.sandbox.content.level:0 incantation: that's necessary on my system at least, in order to make old Nightlies run on Ubuntu without insta-crashing their content processes, due to some sort of impedence mismatch between modern OS sandboxing libraries vs. old Firefox sandboxing code. It's unrelated to this issue; just explaining it since I know it looks odd.)

Comment 6

[BugBot [:suhaib / :marco/ :calixte]]

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

:gw, since you are the author of the regressor, bug 1706801, could you take a look?
For more information, please visit auto_nag documentation.

Comment 7

[Glenn Watson [:gw]]

Is that regression bug definitely correct?

It seems unlikely from a quick skim of the patch - though, it does affect partial present, so it might also affect whether the bug shows up without being the root cause of the bug.

Comment 8

[Daniel Holbert [:dholbert]]

The specific bug is a guess, based on the observation that this is webrender-specific.

The range (a day of commits) is definitely correct RE when the issue started reproducing.

Comment 9

[Timothy Nikkel (:tnikkel)]

I actually get a different regression range (on mac) a few days earlier than dholberts

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=7bc2dd06085f53993037b4fc78ee651c5afc7671&tochange=0ea49daf534fcd9a49708717b3864a4ebc73c20d

(I double checked the range above to make sure)

Maybe bug 1682195?

Comment 10

[Daniel Holbert [:dholbert]]

(In reply to Timothy Nikkel (:tnikkel) from comment #9)

I actually get a different regression range (on mac) a few days earlier than dholberts

Interesting! I just re-confirmed my range on Ubuntu, using mozregression --launch for 2021-04-21 and 2021-04-22. (2021-04-21 is "good", 2021-04-22 is "bad" for me.)

Comment 11

[Daniel Holbert [:dholbert]]

On my macbook pro, I get the same range as tnikkel (nearly 2 weeks earlier than the Ubuntu range). And... hg.m.o is telling me the pushlog is empty for some reason [it's good now; I hit some temporary hg.m.o issues]. So: seems like on mac, 2021-04-09 is last-good and 2021-04-10 is first-bad.

2:40.07 INFO: Last good revision: 7bc2dd06085f53993037b4fc78ee651c5afc7671 (2021-04-09)
2:40.07 INFO: First bad revision: 0ea49daf534fcd9a49708717b3864a4ebc73c20d (2021-04-10)
2:40.07 INFO: Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=7bc2dd06085f53993037b4fc78ee651c5afc7671&tochange=0ea49daf534fcd9a49708717b3864a4ebc73c20d

Comment 12

[Glenn Watson [:gw]]

https://bugzilla.mozilla.org/show_bug.cgi?id=1682195 does sound like a plausible candidate.

Comment 13

[Daniel Holbert [:dholbert]]

Aha -- from checking about:support, it looks like my Ubuntu regression range is just when I went from WR being off-by-default (due to glxtest failing) to being on-by-default. Maybe that change was from bug 1695725 being fixed? (fixing a crash which I would naively guess might've been implicated in the glxtest failure) Not sure if it was that or something else, but in any case, that part's clearly not the true underlying; it's just WebRender becoming active for me.

Given that clue, I tried running mozregression with WebRender explicitly preffed on (gfx.webrender.enabled:true) and that gave me the same older regression range that tnikkel and I got for macOS.

So: that's more data supporting bug 1682195 (or something else from the same daylong pushlog) being the regressor.

Comment 14

[Daniel Holbert [:dholbert]]

(Further evidence for bug 1682195 being the root cause here: bug 1682195 had another regression, bug 1707798 ["Flickering outline around objects on [codepen animation demo"], whose description sounds quite similar to this bug here. Maybe/hopefully we can apply a similar fix here.)