Closed Bug 1719328 Opened 3 years ago Closed 3 years ago

Seeing the tab throbber a lot

Categories

(Firefox :: Tabbed Browser, defect, P1)

defect

Tracking

()

RESOLVED FIXED
91 Branch
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.

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

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

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
Severity: -- → S2
Flags: needinfo?(kmaglione+bmo)
Priority: -- → P1
Summary: Seeing the tab throbber a lot → Seeing the tab throbber a lot and slow script warnings from "Firefox Translation" extension

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.

Component: DOM: Content Processes → Translation
Flags: needinfo?(kmaglione+bmo) → needinfo?(florian)
Product: Core → Firefox

(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.

(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.

Flags: needinfo?(anatal)

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.

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)

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.

Flags: needinfo?(emilio)

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).

See Also: → 1719411
See Also: → 1719403
QA Whiteboard: [qa-regression-triage]

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

Does anyone see it on non-macOS?

(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.

(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).

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?

Flags: needinfo?(emilio)
Attached image Screenshot

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.

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...

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

Depends on: 1719440

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.

Flags: needinfo?(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?

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

Component: Translation → Tabbed Browser

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

Regressed by: 1717983

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

setInterval(() => gBrowser.selectedBrowser.docShellIsActive = true, 1000);
Flags: needinfo?(florian)

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.

Assignee: nobody → emilio
Status: NEW → ASSIGNED

Thank you Emilio!

Sorry for the frustration everyone :(

Flags: needinfo?(emilio)
Pushed by ncsoregi@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/cecf08439a34 Fix an embarrassing typo in BrowserChild::RecvPreserveLayers. r=Mossop CLOSED TREE
Pushed by ncsoregi@mozilla.com: https://hg.mozilla.org/mozilla-central/rev/70be81d77fa6 Fix an embarrassing typo in BrowserChild::RecvPreserveLayers. r=Mossop a=Aryx
Summary: Seeing the tab throbber a lot and slow script warnings from "Firefox Translation" extension → Seeing the tab throbber a lot
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 91 Branch
See Also: → 1719488
Blocks: 1719509
See Also: → -Wunused-parameter

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.

Flags: needinfo?(anatal)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: