1347370 - Spinners rapidly blink in all tabs with gray spinners (sometimes)

Status: NEW

(Firefox :: Tabbed Browser, defect)

Description

[684sigma]

Attachment: Spinners rapidly blink, by reporter.webm

I have a problem with Firefox Beta 53. It doesn't happen in Firefox ESR 45 and Firefox Beta 52.
Sometimes spinners start rapidly blinking in all tabs with gray spinner. Originally encountered on developer/compact theme, but it happens on default theme too.
It happens unpredictably, however, I noticed one specific scenario when it happens

1. Open preferences, close all other tabs
2. Open this url in a new tab:
data:text/html,<script>setTimeout('document.open()',100)</script>
3. Open this url in a new tab (3 tabs total):
data:text/html,<title>hello world</title><iframe src='data:text/html,<script>onload=function(){setTimeout(`document.open()`,50);}</script>'>
4. Keep reloading (Ctrl+Shift+R) the last tab with an interval of 1 second, until you see the bug

Result: spinners in all tabs with gray spinners blink
Expected: spinners shouldn't blink

Comment 1

[684sigma]

Another issue found with urls from the first comment is filed as Bug 1347389

Comment 2

[Stefan [:StefanG_QA]]

[Tracking Requested - why for this release]:

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:55.0) Gecko/20100101 Firefox/55.0

I have tested the reported behavior on Beta 53 and Firefox release, but could not reproduce it. However I was able to reproduce it on Developer Edition and Nightly with ease. When reload the page, spinners in all tabs with gray spinners blink as shown in the video provided by the reporter.

Comment 3

[Nathan Froyd [:froydnj]]

[Tracking Requested - why for this release]: If we're going to track for 53 (see comment 2), we might as well track for subsequent releases as well.  Comment 2 also indicates the regression might be easier to reproduce on 54 and 55 anyway (?).

Comment 4

[Marcia Knous [:marcia]]

Tracking 53/54/55+ so we can track down this visible regression.

Comment 5

[Vlad Bacia-Mociran [:VladB]]

I used MozRegression to find the regression range:
INFO: Narrowed inbound regression window from [c04f84af, 253395be] (3 revisions) to [c04f84af, b4ade2b0] (2 revisions) (~1 steps left)
INFO: Oh noes, no (more) inbound revisions :(
INFO: Last good revision: c04f84afb1bd6b3ea372164012735de6c8f2d582
INFO: First bad revision: b4ade2b0841c5825968f34752d86ee09507a0a9f
NFO: Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=c04f84afb1bd6b3ea372164012735de6c8f2d582&tochange=b4ade2b0841c5825968f34752d86ee09507a0a9f

INFO: Looks like the following bug has the  changes which introduced the regression:
https://bugzilla.mozilla.org/show_bug.cgi?id=1314133

@David, can you please take a look at this?

Comment 6

[Randell Jesup [:jesup] (needinfo me)]

dvander: I think gpu process is nightly only; this has been seen in aurora and beta.

sigma - can you provide about:support data?  and verify you see it in Beta 53? thanks

Comment 7

[684sigma]

Attachment: spinners rapidly blink on beta 53, by reporter.webm

Comment 8

[684sigma]

Attachment: about config section on beta 53 (crash reports removed), by reporter.txt

Comment 9

[684sigma]

Maybe important: I recorded the video in a new profile on Beta 53, and pref "layers.gpu-process.enabled" was set to "true".

Comment 10

[David Anderson [:dvander] - inactive, e-mail if emergency]

If you set layers.gpu-process.enabled to false, and gfx.direct2d.disabled to true, does the problem reproduce?

Comment 11

[684sigma]

(In reply to David Anderson [:dvander] from comment #10)
> If you set layers.gpu-process.enabled to false, and gfx.direct2d.disabled to
> true, does the problem reproduce?

The default value of layers.gpu-process.enabled is "true", and default value of gfx.direct2d.disabled is "false" in Beta 53 and Nightly 55.
When I change them as you suggested, the bug is still reproducible in both versions.
When I change only layers.gpu-process.enabled to "false", the bug is not reproducible in both versions.

Comment 12

[Randell Jesup [:jesup] (needinfo me)]

dvander: any chance of a late 53-beta fix for this?  or live with it for a release?

Comment 13

[Liz Henry (:lizzard) (relman/hg->git project)]

I think 54 is more reasonable here, it may need more investigation and we are about to ship the 53 release candidate tomorrow.

Comment 14

[David Anderson [:dvander] - inactive, e-mail if emergency]

The STR in comment #0 are quite good. I can reproduce this without the GPU process, and with direct2d off, so it is probably a Skia issue. It looks like every other frame of the animation gets stuck using an old texture, the grayscale version of the animation is fine but the blue one is a still image.

Mason, this ni? is just for you to triage, there isn't any indication this is widespread.

Comment 15

[Mason Chang [Inactive] [:mchang]]

I can reproduce this with the GPU process + d2d. I can also reproduce this with Cairo. It's actually much easier with cairo than Skia / d2d.

Comment 16

[Mason Chang [Inactive] [:mchang]]

I can also still reproduce this on Firefox 52 ESR with cairo. Can you please go to about:config:

1) Set the preference "gfx.content.azure.backends" to "cairo"
2) Set the preference "gfx.canvas.azure.backends" to "cairo"
3) Restart firefox
4) Try the STR fro comment 0. 

You can download Firefox 52 ESR here - https://ftp.mozilla.org/pub/firefox/releases/52.0esr/

Thanks

Comment 17

[684sigma]

The bug is also reproducible in ESR 52 with the non-default configuration from Comment 16.
I found the bug when opened a web page while another web page was infinitely loading. I often see that happening with ad frames, but it's unreliable. The "STR" is written this way, because unfortunately I don't have a handy infinitely loading page.

Although, is it correct that said configuration is considered common enough?
If it's not common, it makes sense to list Bug 1314133 in "See also" as a bug that caused most of occurrences of this bug.

Comment 18

[Gerry Chang [:gchang]]

Hi :mchang,
Any chances we can fix this in 54?

Comment 19

[Mason Chang [Inactive] [:mchang]]

(In reply to Gerry Chang [:gchang] from comment #18)
> Hi :mchang,
> Any chances we can fix this in 54?

I think this is a long standing bug that just started happening because more people were not on D2D. I've been able to reproduce this with Cairo going back a bit, across all backends. I'm not sure this is a gfx bug versus a front end bug.

Comment 20

[Gerry Chang [:gchang]]

Too late for 54 as we've built 54 RC. Mark 54 won't fix.

Comment 21

[Liz Henry (:lizzard) (relman/hg->git project)]

Dropping tracking here, I think this is now backlog since it's hard to reproduce and intermittent.