Open Bug 1347370 Opened 3 years ago Updated 3 years ago

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


(Firefox :: Tabbed Browser, defect)

53 Branch
Not set



Tracking Status
firefox53 + wontfix
firefox54 + wontfix
firefox55 + fix-optional


(Reporter: 684sigma, Unassigned)



(Keywords: regression, regressionwindow-wanted)


(3 files)

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:
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(``,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
Keywords: regression
Another issue found with urls from the first comment is filed as Bug 1347389
See Also: → 1347389
[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.
Ever confirmed: true
[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 (?).
Tracking 53/54/55+ so we can track down this visible regression.
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:

INFO: Looks like the following bug has the  changes which introduced the regression:

@David, can you please take a look at this?
Blocks: 1314133
Flags: needinfo?(dvander)
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
Flags: needinfo?(684sigma)
Flags: needinfo?(684sigma)
Maybe important: I recorded the video in a new profile on Beta 53, and pref "layers.gpu-process.enabled" was set to "true".
If you set layers.gpu-process.enabled to false, and gfx.direct2d.disabled to true, does the problem reproduce?
Flags: needinfo?(dvander)
Flags: needinfo?(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.
Flags: needinfo?(684sigma)
dvander: any chance of a late 53-beta fix for this?  or live with it for a release?
Flags: needinfo?(dvander)
I think 54 is more reasonable here, it may need more investigation and we are about to ship the 53 release candidate tomorrow.
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.
No longer blocks: 1314133
Flags: needinfo?(dvander) → needinfo?(mchang)
Flags: needinfo?(mchang)
Flags: needinfo?(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.
Flags: needinfo?(mchang)
I can also still reproduce this on Firefox 52 ESR with cairo. Can you please go to about:config:

1) Set the preference "" to "cairo"
2) Set the preference "" to "cairo"
3) Restart firefox
4) Try the STR fro comment 0. 

You can download Firefox 52 ESR here -

Flags: needinfo?(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.
Flags: needinfo?(684sigma)
Hi :mchang,
Any chances we can fix this in 54?
Flags: needinfo?(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.
Flags: needinfo?(mchang)
Too late for 54 as we've built 54 RC. Mark 54 won't fix.
Dropping tracking here, I think this is now backlog since it's hard to reproduce and intermittent.
You need to log in before you can comment on or make changes to this bug.