1719328 - Seeing the tab throbber a lot

Status: RESOLVED FIXED

(Firefox :: Tabbed Browser, defect, P1)

Description

[Dave Townsend [:mossop]]

Since updating today (to https://hg.mozilla.org/mozilla-central/rev/1f7ab358eec6d8b8baed711b105742b8ca22dc90) I have been seeing the throbber when switching tabs a lot. Sometimes the tab never recovers and has to be closed and reopened.

I took a profile, in this case I switched to the failing tab just after starting the profile, it never displayed. It was slack running in process 11498.

https://share.firefox.dev/3hkXYcQ

Comment 1

[Andrew Overholt [:overholt]]

I'm experiencing the same thing and have a very similar profile to what Mossop captured.

Comment 2

[Chris Peterson [:cpeterson]]

Looks like a recent regression. We need a regression range.

kmag will look at comment 0's profile for clues.

Ironically, I hadn't seen this throbber problem until I switched away from this Bugzilla page. I was still able to use Bugzilla in other tabs, so the Bugzilla content process is not hung. (I'm using Fission so all my Bugzilla tabs share the same content process.)

I suspect the throbber problems are related to the "Firefox Translation" extension. I've seen slow script warnings about "Firefox Translation" on other pages today and the stuck throbber page's console has log messages about dom-translation-content-script.js:

The document has a total of 353 translation nodes, of which 342 are translation roots dom-translation-content-script.js:290:17
Object { documentTranslationStatistics: {…} }
dom-translation-content-script.js:1891:13
Detected language is in one of the user's accepted target languages. 
Object { acceptedTargetLanguages: (1) […] }
dom-translation-content-script.js:101:25
Source map error: Error: NetworkError when attempting to fetch resource.
Resource URL: moz-extension://cf39984c-1895-4387-85d4-ac7b17acbec8/dom-translation-content-script.js
Source Map URL: dom-translation-content-script.js.map

Comment 3

[Chris Peterson [:cpeterson]]

Florian, did Firefox Translation land any new code recently? People are seeing the tab switching throbber and slow script warnings from "Firefox Translation" extension today.

Comment 4

[Mark Banner (:standard8)]

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

Ironically, I hadn't seen this throbber problem until I switched away from this Bugzilla page. I was still able to use Bugzilla in other tabs, so the Bugzilla content process is not hung. (I'm using Fission so all my Bugzilla tabs share the same content process.)

I'm seeing this on non-Fission (I'd turned it off a while ago due to a different issue and forgot to turn it back on).

Regarding the content process: I saw the throbber just now, I right-clicked on the tab and selected "Reload Tab". The browser console showed that the page was reloading, even though the tab throbber remained.

Comment 5

[Andrew Overholt [:overholt]]

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

Florian, did Firefox Translation land any new code recently? People are seeing the tab switching throbber and slow script warnings from "Firefox Translation" extension today.

Andre might know.

Comment 6

[Shane Caraveo (:mixedpuppy)]

I do not have translations running and am having this happen to me for slack and facebook. I haven't noticed it for anything else. I also disabled addons on slack to see if that was the issue, still running into it.

Comment 7

[Ryan VanderMeulen [:RyanVM]]

Pushlog range between the 20210705213049 and 20210706094632 Nightly builds:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=fbce34355e3f&tochange=1f7ab358eec6d8b8baed711b105742b8ca22dc90

And between 20210705095222 & 20210705213049:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=095ea66cb9a1&tochange=fbce34355e3f80a1954e59b0d3643ed930670089

I'm wondering about bug 1717983 maybe?

Comment 9

[Daniel Veditz [:dveditz]]

I'm seeing this a ton today but do not have "Firefox Translations" enabled (it is installed/disabled, though).

Perhaps it's coincidence, but it's only happened on pages that I've been editing (adding bugzilla comments, GDocs)

Comment 10

[Chris Peterson [:cpeterson]]

Emilio, could your PresShell activeness changes from bug 1717983 could cause these throbber problems?

Maybe the slow script warnings for the "Firefox Translations" extension are a different issue.

Comment 11

[Brian Birtles (:birtles, Feb 26~ parental leave)]

I'm seeing this in Fission for Gmail tabs and GitHub tabs. I can still click things in the tab even while the spinner is showing it seems.

If I minimize the window and restore it, it works for a while, but then after switching to other tabs and back it often reverts to the spinner (after which minimizing and restoring temporarily fixes it).

Comment 12

[Dave Townsend [:mossop]]

I do not have Firefox Translation enabled so that might be a red herring.

Comment 13

[Emilio Cobos Álvarez (:emilio)]

Does anyone see it on non-macOS?

Comment 14

[Emilio Cobos Álvarez (:emilio)]

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

Emilio, could your PresShell activeness changes from bug 1717983 could cause these throbber problems?

To answer this, yes, but it points to a pre-existing issue.

Comment 15

[Brian Birtles (:birtles, Feb 26~ parental leave)]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #13)

Does anyone see it on non-macOS?

Yes, I see it on Windows (quite a lot).

Comment 16

[Emilio Cobos Álvarez (:emilio)]

When you see this, does opening the browser console and running:

gBrowser.tabs.filter(t => t.linkedBrowser.docShellIsActive)

Return anything? If so, does it return the tab that you're currently on (the one with the spinner)? If the answer to any of the above is "yes", does doing gBrowser.selectedTab.linkedBrowser.docShellIsActive = true; stop the spinner etc?

Comment 17

[Brian Birtles (:birtles, Feb 26~ parental leave)]

Attachment: Screenshot

Comment 18

[Brian Birtles (:birtles, Feb 26~ parental leave)]

Sorry, you mean the actual browser console...

In that case, if I focus the inactive tab and run that command I get an empty array.

Comment 19

[Emilio Cobos Álvarez (:emilio)]

Yeah, I meant the browser console (Ctrl+Shift+J).

Does setting docShellIsActive manually help get the tab unstuck? In that case... I doubt it's really related to my patch, it's the tab switcher who's responsible of setting docShellIsActive...

Comment 20

[Emilio Cobos Álvarez (:emilio)]

(Brian confirmed over slack that gBrowser.selectedTab.linkedBrowser.docShellIsActive = true did get the tab unstuck)

Comment 23

[Emilio Cobos Álvarez (:emilio)]

Andrei gave me some steps to reproduce this on macOS:

• Switch to a fullscreen app (anyone works, he was using mail, I was using TextEdit).
• Switch to Firefox with Cmd+Tab.
• Ctrl+Tab to switch to the previous foreground tab.
• Spinner.

I'll poke.

Comment 25

[Emilio Cobos Álvarez (:emilio)]

Per comment 18 and following it seems the tab switcher gets into a state where the active tab is not really marked as active (docShellIsActive is managed by the tab switcher).

My patch made the PresShell state (which determines the throttling of the refresh driver and such) consistent with that and made the pres shell throttled in that case, which seems to be what causes this, but it seems like the root of the problem is that the tab is not flagged as active to begin with...

I'm not sure why we aren't activating the requested browser straight away in the AsyncTabSwitcher? It seems like what might be happening is that we end up with a browser that is non-active, but with preserveLayers = true and renderLayers = true, in which case we still throttle the pres shell (which didn't use to be the case before, depending on the order of the calls by the tab switcher).

From what I can tell from poking at the tab switcher code, the tab switcher will only activate the docshell once it gets the LayerTreeReady message, which might happen too late if the refresh driver is throttled... But that's just a guess, I'll try to add some logging to confirm this.

Still activating the docshell on requestTab seems like the right thing to do?

Comment 26

[Dave Townsend [:mossop]]

I think mconley did a bunch of work on the async tab switcher so he may have useful info.

Comment 27

[Catalin Sasca, Desktop QA [:csasca]]

We found this regression range, hope it helps:

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=6245180c2c4a0d7806a158657c55ac4f0e404818&tochange=49c60a0b4565926424dea786b69b772ecc9e3f92

Comment 28

[Emilio Cobos Álvarez (:emilio)]

Yeah, not super surprising at this point, but still very useful to confirm, thanks Catalin!

Comment 29

[Dave Townsend [:mossop]]

I've run this in the browser console and now Nightly is not completely frustrating to use:

setInterval(() => gBrowser.selectedBrowser.docShellIsActive = true, 1000);

Comment 30

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1719328 - Fix an embarrassing typo in BrowserChild::RecvPreserveLayers. r=Mossop

This can cause the tab switcher to get confused. The tab switcher clears this
flag in order to get layer updates, but of course that wasn't happening and
warmed-up tabs after preserveLayers(true) had been called (due to window
minimization on Windows, or occlusion on macOS) ended up in a forever-loading
state.

Quite unfortunate that I didn't notice it when writing or skimming over my
patch this morning, that it passed review, and that compilers don't complain
about this, sigh.

Comment 31

[Brian Birtles (:birtles, Feb 26~ parental leave)]

Thank you Emilio!

Comment 33

[Emilio Cobos Álvarez (:emilio)]

Sorry for the frustration everyone :(

Comment 34

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/cecf08439a34
Fix an embarrassing typo in BrowserChild::RecvPreserveLayers. r=Mossop CLOSED TREE

Comment 35

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/mozilla-central/rev/70be81d77fa6
Fix an embarrassing typo in BrowserChild::RecvPreserveLayers. r=Mossop a=Aryx

Comment 36

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/70be81d77fa6

Comment 38

[Marian-Vasile Laza]

https://hg.mozilla.org/mozilla-central/rev/cecf08439a34

Comment 39

[André Natal]

Sorry for the late response, I was on PTO until today. I know this was already figured, but just answering the original question directed to me: no we haven't landed any translations code recently.