Seeing the tab throbber a lot
Categories
(Firefox :: Tabbed Browser, defect, P1)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr78 | --- | unaffected |
firefox89 | --- | unaffected |
firefox90 | --- | unaffected |
firefox91 | + | fixed |
People
(Reporter: mossop, Assigned: emilio)
References
(Blocks 1 open bug, Regression)
Details
(Keywords: regression)
Attachments
(2 files)
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.
Comment 1•3 years ago
|
||
I'm experiencing the same thing and have a very similar profile to what Mossop captured.
Comment 2•3 years ago
|
||
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
Updated•3 years ago
|
Comment 3•3 years ago
|
||
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•3 years ago
|
||
(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•3 years ago
|
||
(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.
Updated•3 years ago
|
Comment 6•3 years ago
•
|
||
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•3 years ago
|
||
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•3 years ago
•
|
||
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•3 years ago
|
||
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•3 years ago
|
||
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).
Updated•3 years ago
|
Reporter | ||
Comment 12•3 years ago
|
||
I do not have Firefox Translation enabled so that might be a red herring.
Assignee | ||
Comment 13•3 years ago
|
||
Does anyone see it on non-macOS?
Assignee | ||
Comment 14•3 years ago
|
||
(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•3 years ago
|
||
(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).
Assignee | ||
Comment 16•3 years ago
|
||
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•3 years ago
|
||
Comment 18•3 years ago
|
||
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.
Assignee | ||
Comment 19•3 years ago
|
||
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
...
Assignee | ||
Comment 20•3 years ago
|
||
(Brian confirmed over slack that gBrowser.selectedTab.linkedBrowser.docShellIsActive = true
did get the tab unstuck)
Assignee | ||
Comment 23•3 years ago
|
||
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.
Assignee | ||
Comment 25•3 years ago
|
||
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?
Reporter | ||
Comment 26•3 years ago
|
||
I think mconley did a bunch of work on the async tab switcher so he may have useful info.
Comment 27•3 years ago
|
||
We found this regression range, hope it helps:
Assignee | ||
Comment 28•3 years ago
|
||
Yeah, not super surprising at this point, but still very useful to confirm, thanks Catalin!
Reporter | ||
Comment 29•3 years ago
|
||
I've run this in the browser console and now Nightly is not completely frustrating to use:
setInterval(() => gBrowser.selectedBrowser.docShellIsActive = true, 1000);
Updated•3 years ago
|
Assignee | ||
Comment 30•3 years ago
|
||
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.
Updated•3 years ago
|
Comment 31•3 years ago
|
||
Thank you Emilio!
Comment 34•3 years ago
|
||
Comment 35•3 years ago
|
||
Updated•3 years ago
|
Comment 36•3 years ago
|
||
bugherder |
Updated•3 years ago
|
Assignee | ||
Updated•3 years ago
|
Comment 38•3 years ago
|
||
bugherder |
Comment 39•3 years ago
|
||
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.
Description
•