1734947 - Page Loads will not begin until Temporary Container Add-On is loaded when browser starts

Status: RESOLVED DUPLICATE of bug 1741865

(WebExtensions :: Untriaged, defect, P5)

Description

[Matthew Gaudet (he/him) [:mgaudet]]

I'm not sure if this is a recent regression or not, but I've noticed that over the last few weeks, when I load my browser, I am unable to complete a page load until the icon for the Temporary Containers add on changes from inactive to active.

This is a bit frustrating, as it feels like my internet is out until I notice this.

Comment 1

[BugBot [:suhaib / :marco]]

The Bugbug bot thinks this bug should belong to the 'Core::CSS Parsing and Computation' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Clara Guerrero ( Need Info Brindusa Tot Please)]

Attachment: temp.JPG

Hi Matthew,

Can you provide additional steps to reproduce so I can try replicating this on my end, and try to provide a regression range?

Thanks!
Clara

Comment 3

[Matthew Gaudet (he/him) [:mgaudet]]

Attachment: Screen Recording 2021-10-14 at 7.38.22 AM-1.mov

So, I don't have a super clear STR. What I do have is a screen recording of the behaviour. What you see me doing is manually updating firefox. Then, I rapidly open three tabs... none of which begins loading until you see the Temporary Container Tabs icon change colour. This violates my expectations, as I would expect that the extension wouldn't block loads.

Comment 4

[Clara Guerrero ( Need Info Brindusa Tot Please)]

The video is super clear, thanks for providing that. However I cannot seem to reproduce on my end, as you can see on my screenshot , the icon is not in active status and pages still loaded (I downloaded https://addons.mozilla.org/en-US/firefox/addon/temporary-containers/ as you described)
This only happens after updating browser, but not each time you launch the browser, correct?

Comment 5

[Matthew Gaudet (he/him) [:mgaudet]]

I believe it's every time I launch the browser, but it seems to be much much worse after an update, so that's where I notice it most (and updates happen silently now if you have Firefox open, but no Windows open, which is surprising).

It's quite possible (probable?) that this is a different problem, and that extension simply makes the issue visible. I will try to make time to do some investigation on this, so I will keep the ni? on this.

Comment 6

[Clara Guerrero ( Need Info Brindusa Tot Please)]

Sounds good! If you can find accurate steps on how to reproduce i'll be happy to help find the regression range.
Have a great day!

Comment 7

[Chris Peterson [:cpeterson]]

Here is a similar issue about "Very slow start up with pinned tabs" in Temporary Container's GitHub issue tracker:

https://github.com/stoically/temporary-containers/issues/532

@ Matthew, do you have any pinned tabs? Can you try record recording a performance profile of Firefox startup? Here are instructions for recording a profile of startup: https://profiler.firefox.com/docs/#/./guide-startup-shutdown

The Temporary Container extension blocks all network requests until it is fully initialized. Nika skimmed the extension's code and sees that the extension's initialization code is blocking all network requests while it is waiting to query open tabs (browser.tabs.query({})) and all other installed extensions (browser.management.getAll()).

Perhaps there is some initialization dependency between pinned tabs, blocked network requests, and session restore? And the deadlock is eventually broken when some long timeout expires?

https://addons.mozilla.org/en-US/firefox/addon/temporary-containers

Comment 8

[Chris Peterson [:cpeterson]]

Firefox 92–94 are also affected according to the extension's similar GitHub issue: https://github.com/stoically/temporary-containers/issues/532

Comment 9

[hazel ward]

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

Here is a similar issue about "Very slow start up with pinned tabs" in Temporary Container's GitHub issue tracker:

https://github.com/stoically/temporary-containers/issues/532

@ Matthew, do you have any pinned tabs? Can you try record recording a performance profile of Firefox startup? Here are instructions for recording a profile of startup: https://profiler.firefox.com/docs/#/./guide-startup-shutdown

The Temporary Container extension blocks all network requests until it is fully initialized. Nika skimmed the extension's code and sees that the extension's initialization code is blocking all network requests while it is waiting to query open tabs (browser.tabs.query({})) and all other installed extensions (browser.management.getAll()).

Perhaps there is some initialization dependency between pinned tabs, blocked network requests, and session restore? And the deadlock is eventually broken when some long timeout expires?

https://addons.mozilla.org/en-US/firefox/addon/temporary-containers

I'm the author of the linked GitHub issue, here's a profile on Fx release https://share.firefox.dev/3BjwXgy

Comment 10

[Luca Greco [:rpl] [:luca] [:lgreco]]

I've tried the following STR but I was unable to trigger it yet:

• create new profile
• install the temporary-containers addon from addons.mozilla.org
• open 3 tabs on some website (developer.mozilla.org, wikipedia.org, google.com) in contained tabs created by the temporary containers
• pinned 1 of the 3 tabs
• configured Firefox to restore all the open tabs on restart from about:preferences
• restart Firefox

But I was unable to reproduce the issue (I tried on Nightly 95 and Release 93, using the official Mozilla builds on Ubuntu 20.04).

Hi Hazel
could you get the full stack trace for that target.join is not a function exception raised from background.js:578?
(I took a look to the script and I'm not yet sure if that exception is just a side effect, but the stack trace may allow us to get a better picture of what is leading to that error and be able to reproduce the issue locally)

is there any temporary-containers setting that you are using on the temporary-containers installations that are able to trigger this issue?

The details from about:support could also be useful to double-check what we may be missing to recreate the issue consistently in a new profile.

Comment 11

[hazel ward]

Attachment: about:support

Here's a new profile from Firefox 93: https://share.firefox.dev/3CmsUkP

The local firefox profile being used is pretty much just all default settings for both firefox and the extension

The console says the following for the target.join() error
listener moz-extension://e1a9fa28-0e00-41be-85e3-a87aaf8385e5/background.js:578
AsyncFunctionThrow self-hosted:696

Comment 12

[Luca Greco [:rpl] [:luca] [:lgreco]]

(In reply to Hazel Ward from comment #11)

The console says the following for the target.join() error
listener
moz-extension://e1a9fa28-0e00-41be-85e3-a87aaf8385e5/background.js:578
AsyncFunctionThrow self-hosted:696

eh, unfortunately the stack trace does let us see what was the original call stack of the wrap method call.
Anyway if I'm reading the temporary-containers (transpiled) background.js script correctly, target is actually meant to be a String and so the target.join exception is expected, and just a pre-existing issue in that catch block, likely triggered just as a side-effect of the temporary-containers initialization timing out.

The profiles linked does confirm (through the "Extension Suspend" and "ExtensionParent" markers) that the web request has been suspended on the webRequest.onBeforeSendHeaders event listener registered by the temporary containers addon (because those markers include the temporary-containers extension id '{c607c8df-14a7-4f28-894f-29e8722976af}', also confirmed by the about:support details attached in comment 11), and that Firefox isn't busy but just waiting the extension to reply.

I'll look the about:support details more closely to see if I can spot any other detail that can be useful to reproduce this issue consistently.

Comment 13

[Matthew Gaudet (he/him) [:mgaudet]]

Attachment: Matt's about:support

Comment 14

[Matthew Gaudet (he/him) [:mgaudet]]

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

Here is a similar issue about "Very slow start up with pinned tabs" in Temporary Container's GitHub issue tracker:

https://github.com/stoically/temporary-containers/issues/532

@ Matthew, do you have any pinned tabs? Can you try record recording a performance profile of Firefox startup? Here are instructions for recording a profile of startup: https://profiler.firefox.com/docs/#/./guide-startup-shutdown

Sorry for the delay in replying: I do not have any pinned tabs, so at the very least my original issue here doesn't map 1-1 onto that specific github issue as described.

If it's helpful, I've also uploaded my about:support.

Comment 15

[BugBot [:suhaib / :marco]]

The severity field is not set for this bug.
:mixedpuppy, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 16

[Shane Caraveo (:mixedpuppy)]

This is an architecture problem with the addon triggering this. We'll consider some UI to point out the problem to users, but we cannot address the problem in the addon.

Comment 17

[Matthew Gaudet (he/him) [:mgaudet]]

Hrm.

So I did disable that addon. The problem remains, but now I can't find any indicator in the UI that shows what's up.

Next steps are on me I think, either a startup profile, trying a clean profile, or bisecting my addons to find out if any of them is responsible.

Comment 18

[stoically]

(In reply to Shane Caraveo (:mixedpuppy) from comment #16)

This is an architecture problem with the addon triggering this. We'll consider some UI to point out the problem to users, but we cannot address the problem in the addon.

Add-on author here. While the add-on is indeed triggering the symptom, as the architecture requires to block requests until some webext API calls (specifically already open tabs & installed add-ons) finished on initialization, the root cause here is that the Firefox API calls take a long time. I'm not sure what causes it, but I saw it happen for other users in the past. Unfortunately the add-on can't do much about it besides trying to balance the timeout, though, it'll always be unsatisfying experience, as there's still a timeout and no instant response on startup.

Comment 20

[Tomislav Jovanovic :zombie]

(not sure why my prev comment is marked as private, nor how to unprivate it)

Hi Matthew, can you please provide more details (like a pref profile or something) so that we can look into if and what we would need to do to address this.

(probably in bug 1743485).

Comment 21

[Matthew Gaudet (he/him) [:mgaudet]]

Luca: That see-also link may have been the perfect spot. I took a look at my Profile's storage, and found that I had 2.2GB of storage dedicated to slack.com (which was 2/3 of the profile size)

After removing that data, I did a browser update, and it was noticeably better performing compared to the video at the top of the page. I think that suggests that this is actually a dupe of Bug 1741865.

Comment 22

[hazel ward]

Hello! I discovered some information that may be helpful

I can reliably reproduce the startup timeout/delay with temporary containers installed when I set my monitor's refresh rate to 300hz
The delay does not occur at 240hz or 60hz