Closed Bug 1560697 Opened 5 years ago Closed 5 years ago

Content load stuck "waiting for socket thread" for several seconds right after startup

Categories

(Core :: Storage: localStorage & sessionStorage, defect)

Product:
Core
Component:
Storage: localStorage & sessionStorage
Version:
69 Branch
Platform:
Desktop
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INCOMPLETE
Tracking Flags:
Tracking Status
firefox69 --- affected

People

(Reporter: filip.stamcar, Unassigned)

References

Details

Attachments

(1 file)

A snapshot of my configuration
62.75 KB, application/json
Details

I'm using Firefox Nightly 69 on Windows 10.

Few days ago, my Firefox profile stopped working.
When I try to open website, it is just loading forever with blank page.
Addons also don't work. When I click on addon icon, it just displays empty little popup.

I then restarted Firefox in safe mode. Some websites then load, but very slow.
I also created new Firefox profile. I works there normally. But I don't want to create new profile, because I used many customisations and addons that would need to be transferred manually.

I also asked on Reddit:
https://www.reddit.com/r/firefox/comments/c39cc2/daily_nightly_discussion_for_20190621_post_about/erqcdqf/

They suggested me to test profile in mozregression to find possible bug that caused issues. I tried multiple times with mozregression but without any successful results.

First, I tested this with my current (broken) profile and clone option. No matter which dates I specified, it always worked on all builds. Websites loaded normally and addons also worked. It was same with clone-first option.

But when I used reuse option, it always failed. Even if I specified 2019-06-01 - 2019-06-21 for dates, it failed on all builds. I also tried few more dates and it was the same.

I have a lot of settings and configurations in addons which I don't want to lose. Is it possible to fix my old profile without deleting addons and customisations?

Are you using any customizations other than addons or preferences? (e.g. are you using things like userChrome.css, etc?)

In any case, can you provide a snapshot of your configuration by doing the following:

  1. Go to about:support
  2. Click one of the "copy data" buttons
  3. Paste the resulting data into a file on your local disk
  4. Come back to this page, click "Attach File" and select the file you created in the previous step

We can scan that for anything obvious but note that this does not include everything. The only really reliable way to get to the bottom of this is to disable things (i.e., addons, non-default preferences, etc.) piece-by-piece to isolate what is responsible.

Flags: needinfo?(filip.stamcar)

I partially fixed that bug.

In summary, I copied old profile to a new profile, opened a new profile in Firefox and it worked. More details are on Reddit:
https://www.reddit.com/r/firefox/comments/c39cc2/daily_nightly_discussion_for_20190621_post_about/ervlh4i/

However, I now have a slightly different problem.
When I open Firefox, I have to wait for about 10 seconds before I can open websites or extensions. If I open them right after Firefox startup, they won't load for about 10 seconds, like they didn't in my original problem. After about 10 seconds, they will load and any additional website will also load normally fast.
Is is possible to also fix this?

I don't use userChrome.css, but I have a lot of addons and some changed preferences in about:config. I don't want to lose them, so I can't refresh profile.

Flags: needinfo?(filip.stamcar)
Summary: Websites load forever → Websites don't load in first 10 seconds

Okay, can you collect a profile while this is happening? Since you're using Nightly, you don't need an extension, you can enable the profiler by going to the Tools menu, then "Web Developer", then "Enable Profiler Toolbar Icon". Since we're interested in what's happening during startup, you'll need to set an environment variable when launching Firefox as described here:
https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Profiling_with_the_Built-in_Profiler#Profiling_Firefox_Startup

Then you can follow the instructions here to capture and upload the profile:
https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Reporting_a_Performance_Problem#Capturing_and_sharing_a_profile

Flags: needinfo?(filip.stamcar)

That article says that I should wait until the "Waiting for symbol tables for library libxul.pdb..." notification disappears. However, it sometimes (for first two profiles) didn't disappear for me even after few minutes. So I shared some results (first two) without waiting notification to disappear.

I created a few different profiles in different times after startup (each in separate run):

  1. Right after startup without opening any website
    https://perfht.ml/2J4oncu

  2. After I opened website and before it loaded
    https://perfht.ml/2J6O63Z

  3. Right before website loaded
    https://perfht.ml/2J82hWi

  4. After website loaded
    https://perfht.ml/2J4uwFF

Flags: needinfo?(filip.stamcar)

From the third profile in comment 4, it appears that the Ever Sync extension is running some very slow synchronous javascript code during initialization. This prevent uBlock Origin from running and inspecting your outgoing requests, which makes them appear to stall for several seconds.
You could confirm this by disabling Ever Sync and seeing if the problem is resolved.

I've moved this bug to a component where somebody from Mozilla may reach out to the developer, but anybody affected by this can also reach out directly to the developer)

Component: General → Developer Outreach
Product: Firefox → WebExtensions
Summary: Websites don't load in first 10 seconds → Ever Sync extension runs some very slow initialization code
Version: 69 Branch → Firefox 69

I disabled Ever Sync but it is still almost the same.

Here are my new profiles with disabled Ever Sync (in the same order as before):

  1. https://perfht.ml/2X9P9Kr
  2. https://perfht.ml/2X2cXQa
  3. https://perfht.ml/2X75RKb
  4. https://perfht.ml/2X76cNg

Even if I disable all extensions (but without safe mode), I will still have the same problem. However, I will have to wait only 4 seconds instead of 10.

Here are my new profiles with disabled extensions (in the same order as before):

  1. https://perfht.ml/2X47gkI
  2. https://perfht.ml/2X8iOn0
  3. https://perfht.ml/2XcbUgU
  4. https://perfht.ml/2X7FaFf

I was also gradually enabling extensions to see which extension uses other 6 seconds.

When I have uBlock Origin enabled, it takes 6-7 seconds to load.
When I also BitTube AirTime (which also contains ad blocker) enabled, it takes 7 seconds. It's same if I disable uBlock Origin.
MetaMask and Module Linker add about 1 second, so it is 8 seconds in total.
Grammarly and Ever Sync adds about 1-2 seconds each, so it finally takes 10 seconds to load.
Other addons do not affect that time.

Note that most of that extensions don't affact time if they are installed and used in fresh Firefox profile. If fresh profile, website load almost instantly.

Thanks for gathering those profiles. From the very last batch with your extensions disabled, I notice that the first content load is still waiting for the socket thread for over 3 seconds. Unfortunately, the socket thread isn't profiled by default. So a couple of suggestions for where to go next:

  1. Your support data indicates you have a firewall enabled, if you disable the firewall does that make a difference?
  2. To gather new profiles that include the socket thread, add MOZ_PROFILER_STARTUP_FILTERS="GeckoMain,Socket Thread" to the environment variables you're setting when starting Firefox.

Thanks for all your efforts so far, I think we're narrowing this down and getting close to the underlying problem.

Flags: needinfo?(filip.stamcar)

I'm using default Windows Defender Firewall. I now disabled it while testing but it is still the same.

I created profiles with disabled extensions and included socket thread:

  1. https://perfht.ml/2X9my7N
  2. https://perfht.ml/2XarxVZ
  3. https://perfht.ml/2XbOdoH
  4. https://perfht.ml/2X9TtJr
Flags: needinfo?(filip.stamcar)

Moving this back to Firefox:General for now since the extension inefficiency isn't the primary issue here.

Component: Developer Outreach → General
Product: WebExtensions → Firefox
Summary: Ever Sync extension runs some very slow initialization code → Content load stuck "waiting for socket thread" for several seconds right after startup
Version: Firefox 69 → 69 Branch

Randell, do you have any thoughts about what's happening here?

Flags: needinfo?(rjesup)

Also, after staring more at the third profile from comment 8, there are a bunch of system-initiated loads (captive portal, proxy detection, activity stream, and so on), all of which finish right around the same time (~5.5 seconds into the profile). The content load of slo-tech.com happens to be the 11th load started by the browser and it starts as soon as one of those first 10 load finishes. This is total speculation, but this would all be consistent with some 10 element queue somewhere in Necko that is filling up. I don't know enough about Necko to know where to look for such a queue.
Also fwiw, there are a few non-default network prefs:

    "network.dns.disablePrefetch": true,
    "network.http.speculative-parallel-limit": 0,
    "network.predictor.cleaned-up": true,
    "network.predictor.enabled": false,
    "network.prefetch-next": false,
    "network.security.esni.enabled": true,

Even if I reset that prefs to default values, it is still the same.

Update: I actually find out that I can't reset those prefs. Even if I reset them to default values, they will still contain old values (listed in Andrew Swan's comment) after Firefox restart.

Are you running any privacy-related extensions, or add-blockers, etc? can you try in safe mode?

Flags: needinfo?(rjesup) → needinfo?(filip.stamcar)

I see DuckDuckGo, some blah.si addons in a language I don't know, one other in the same language. You could just disable all extensions and try it

:jesup:
There is some context in previous comments but per comment 6, these recent profiles were gathered with all user-installed extensions disabled. What you're seeing are the built-in search engines which still show up in the list of extensions (some of them have names
And per comment 2, I don't know if safe mode has been tried but the user is not experiencing this problem in a new profile.

Filip:

Update: I actually find out that I can't reset those prefs. Even if I reset them to default values, they will still contain old values

How are you changing the prefs? Via about:config? Are they overridden from some other file in your profile?

Huh; why is the profiler showing disabled extensions then? Even in the "All extensions disabled" case I see things like Odpiralni Časi (etc)

It's also interesting that the "delay" is shorter with extensions disabled....

(In reply to Randell Jesup [:jesup] (needinfo me) from comment #17)

Huh; why is the profiler showing disabled extensions then? Even in the "All extensions disabled" case I see things like Odpiralni Časi (etc)

That appears to be the localized name of a search engine in the user's region:
https://searchfox.org/mozilla-central/rev/06bd14ced96f25ff1dbd5352cb985fc0fa12a64e/browser/components/search/extensions/odpiralni/manifest.json#2

(In reply to Randell Jesup [:jesup] (needinfo me) from comment #17)

Huh; why is the profiler showing disabled extensions then? Even in the "All extensions disabled" case I see things like Odpiralni Časi (etc)

Extensions that are shown in comment 8 are search engines and other extensions that are built into Firefox. I can't disable them in about:addons, because they aren't listed. This wasn't tested in safe mode, but with just all extensions disabled manually.

(In reply to Andrew Swan [:aswan] from comment #16)

How are you changing the prefs? Via about:config? Are they overridden from some other file in your profile?

I changed them in about:config. But they were overwritten. I'm using uBlock Origin, so this could be the case here. I read somewhere that it disables prefetching for privacy reasons.

(In reply to Randell Jesup [:jesup] (needinfo me) from comment #14)

Are you running any privacy-related extensions, or add-blockers, etc? can you try in safe mode?

Yes, I use uBlock Origin, Webmail Ad Blocker and BitTube (which appears to also contain ad blocker). In safe mode, it works normally without any delay.

Flags: needinfo?(filip.stamcar)

Here is also a comparison between enabled extensions, disabled extensions, and real safe mode. All profiles were created (almost) immediately when website loaded.

Enabled extensions: https://perfht.ml/2Xcsc9b
Disabled extensions: https://perfht.ml/2Xdty3u
Safe mode: https://perfht.ml/2XeCJkj

Are the about:config entries overwritten if you restart in safe mode? If so, are they overwritten if you set them in safe mode (or extensions-disabled mode), and then restart in safe mode? I'm wondering if the extensions were blocking your ability to reset them (regardless of what the UI shows). You can also directly check prefs.js in the profile directory after shutting down to see the values. (non-default value should show up there).

Honza: 10 seems unlikely as a request limit in Necko, but seems possible in one of those extensions.

Flags: needinfo?(honzab.moz)
Flags: needinfo?(filip.stamcar)

The "disabled extensions" profile shows very little extension activity, and effectively none during the pause; that would tend to imply the prefs may be getting reset to non-default values before you disable them and restart.

In your profiles, the network requests from the content process are blocked until the http://wpad/wpad.dat request finishes. Do you know what this url is? Could it be a proxy autoconfiguration file?

The preferences mentioned before are most likely set by an enterprise policy. I see WindowsGPOPoliciesProvider from EnterprisePolicies.js in most of the profiles you shared.

(In reply to Florian Quèze [:florian] from comment #24)

In your profiles, the network requests from the content process are blocked until the http://wpad/wpad.dat request finishes. Do you know what this url is? Could it be a proxy autoconfiguration file?

It definitely is. What is your proxy configuration - both in Firefox and the OS?

Flags: needinfo?(honzab.moz)

(In reply to Randell Jesup [:jesup] (needinfo me) from comment #22)

Are the about:config entries overwritten if you restart in safe mode? If so, are they overwritten if you set them in safe mode (or extensions-disabled mode), and then restart in safe mode? I'm wondering if the extensions were blocking your ability to reset them (regardless of what the UI shows). You can also directly check prefs.js in the profile directory after shutting down to see the values. (non-default value should show up there).

Honza: 10 seems unlikely as a request limit in Necko, but seems possible in one of those extensions.

If I reset pref, it will be correctly removed from pref.js. If I ten open safe mode, it will be correctly reset. When I then open normal mode, it will be set to a non-default value. So it's likely some extension which forces that prefs.

(In reply to Florian Quèze [:florian] from comment #24)

In your profiles, the network requests from the content process are blocked until the http://wpad/wpad.dat request finishes. Do you know what this url is? Could it be a proxy autoconfiguration file?

The preferences mentioned before are most likely set by an enterprise policy. I see WindowsGPOPoliciesProvider from EnterprisePolicies.js in most of the profiles you shared.

I was using a proxy option to detect proxy for the current network. Request for wpdad probably came from that.
I then reset this option to default to use the system's configuration. The system configuration is to detect proxy (default for Windows 10).

Request for wpdad gone.
When I tried to load the website with disabled extensions (no safe mode), it worked normally fast. With extensions, it was slow.

Enabled extensions: https://perfht.ml/2XdiPq6
Disabled extensions: https://perfht.ml/2XbiZOI

I also tested a few different extension combinations to see how they affect that delay.

Only uBlock Origin: https://perfht.ml/2XdsXis
Only BitTube: https://perfht.ml/2XbPIDB
BitTube and uBlock Origin: https://perfht.ml/2X9AEGm
All other extensions: https://perfht.ml/2XeQDTG
Buster and Livemarks: https://perfht.ml/2XbjXuk
Buster, EverSync and Livemarks: https://perfht.ml/2XjB1OV
All except BitTube, uBlock and EverSync: https://perfht.ml/2XdkRqe
All except BitTube, uBlock, EverSync and LastPass: https://perfht.ml/2XdpsIH
All except BitTube, uBlock, EverSync, Livemarks, MetaMask and LastPass: https://perfht.ml/2Xaiows

Flags: needinfo?(filip.stamcar)

The profiles in comment 26 look like we are blocked by what's happening in the WebExtensions process. It seems to be blocked for several seconds while loading a script, but it's not the same script that blocks on every profile. And the actual thing we are blocked on is mozilla::dom::LSObject::EnsureDatabase in all profiles.

So it seems WebExtension startup blocks network loads until a database (that can take seconds to get) is initialized synchronously. Any idea of why this would take so long, and anything we could to about it?

Flags: needinfo?(aswan)

The comment at https://searchfox.org/mozilla-central/rev/f91bd38732d4a330eba4e780812274b98eb81274/dom/localstorage/LSObject.cpp#822 indicates this is actually blocked on waiting for something happening on the "DOM File" thread. Filip, any chance you could capture a profile including that additional thread? Thanks a lot for all the profiles you already shared, very appreciated!

Flags: needinfo?(filip.stamcar)

A friend of mine sent me a profile with the same issue as what I saw in the profiles from comment 26, but on Linux: https://perfht.ml/2RPWNUt Marking this as affecting all platforms.

OS: Windows 10 → All

(In reply to Florian Quèze [:florian] from comment #27)

The profiles in comment 26 look like we are blocked by what's happening in the WebExtensions process. It seems to be blocked for several seconds while loading a script, but it's not the same script that blocks on every profile. And the actual thing we are blocked on is mozilla::dom::LSObject::EnsureDatabase in all profiles.

So it seems WebExtension startup blocks network loads until a database (that can take seconds to get) is initialized synchronously. Any idea of why this would take so long, and anything we could to about it?

This is an individual extension that installs a blocking webRequest listener. At least uBlock origin does this, I don't know offhand about all the other extensions in use. We looked at this much earlier in this bug (comment 5) and it was a synchronous localStorage read in the Ever Sync extension that blocked the entire extension process, preventing uBO from replying from its blocking listener. But we turned away from that (comment 9) when there was still a multi-second pause with uBO disabled. That, however also appears to be the issue with the profile in comment 29 (although in this case it is uBO itself reading from localStorage that is taking a very long time)

At this point, my best summary is that the original reporter was actually experiencing two different problems at the same time:

  1. Very slow localStorage reads during startup of uBO or other extensions causing uBO to effectively stall outgoing web requests for seconds.
  2. The problem with proxy autoconfig (see comment 24 and comment 26)
Flags: needinfo?(aswan)

Here is my new profile, including GeckoMain, Socket Thread and DOM File, with extensions and on page load:
https://perfht.ml/2JgBpDB

Flags: needinfo?(filip.stamcar)

There's not much to see in the profile on the file thread, I think we may have reached the limits of what the profiler can show us and could use something like procmon or strace to see what's actually happening between Firefox and the OS.
Unless asuth has any ideas? (quick recap is the profile from comment 31 shows the web extension process blocked for 7 seconds (!!) in LSObject::DoRequestSynchronously, any ideas what might cause that and/or to to diagnose or fix it?)

Flags: needinfo?(bugmail)

Under LocalStorage NextGen (enabled on 68 onwards, currently), LocalStorage uses QuotaManager for persistence. QuotaManager initializes asynchronously and initialization time is a function of disk speed, number of origins known to QuotaManager, and amount of data stored under QuotaManager. It is likely QM is taking ~7 seconds to initialize.

While there are currently efforts under way to optimize the initialization process (and cache and reuse cached state when a clean shutdown occurs), cleaning up the QuotaManager storage used is currently the best way to improve this time. Using the "Refresh Firefox" mechanism from about:support accomplishes this in a dramatic fashion by copying the profile over and none of the QuotaManager data. For a more targeted clearing, the "manage data" UI has a "last used" column that can be sorted by and thereby used to select origins that haven't been used in a while and purge them. See https://support.mozilla.org/en-US/kb/storage for the general operation of the dialog.

Flags: needinfo?(bugmail)

:asuth, thanks for the explanation.

Filip, would you be willing to try one of the things Andrew suggests in comment 33 and reporting on startup time with proxy checking still disabled but your extensions enabled?

Flags: needinfo?(filip.stamcar)
See Also: → 1562942

I removed data from some old sites and reduced data to about 350 MB. I don't want to refresh profile because I will lose my addons and configuration.

Now, it's maybe slightly better, but it still takes almost 5 seconds to load.

Flags: needinfo?(filip.stamcar)

Filip, could you try changing the preference dom.storage.next_gen to false (you can do this from about:config) and seeing if address the startup slowness?
The storage implementation is supposed to be fully downgradeable so this should not entail any data loss.

Flags: needinfo?(filip.stamcar)

It's about one second faster, but it still takes almost 4 seconds to load.

Flags: needinfo?(filip.stamcar)

Thanks for all your help and patience so far. Can you collect a profile with the storage pref set to false?

Flags: needinfo?(filip.stamcar)

I can't collect a new profile.

I started Firefox with MOZ_PROFILER_STARTUP=1 and MOZ_PROFILER_STARTUP_FILTERS="GeckoMain,Socket Thread,DOM File" and opened a website. But when I try to "Capture Profile", profiler website will open, but it will remain on "Grabbing the profile from the Gecko Profiler Addon...". The actual website with data doesn't show even after a few minutes. I also tried this few more times.

But when I start profiler and capture profile manually (without MOZ_PROFILER_STARTUP=1), it works. I opened Firefox, enabled profiler as quickly as possible, open website and then capture profile. This is what I got:
https://perfht.ml/2XmRHF3

Flags: needinfo?(filip.stamcar)

(In reply to Filip Š from comment #39)

I can't collect a new profile.

I started Firefox with MOZ_PROFILER_STARTUP=1 and MOZ_PROFILER_STARTUP_FILTERS="GeckoMain,Socket Thread,DOM File" and opened a website. But when I try to "Capture Profile", profiler website will open, but it will remain on "Grabbing the profile from the Gecko Profiler Addon...". The actual website with data doesn't show even after a few minutes. I also tried this few more times.

But when I start profiler and capture profile manually (without MOZ_PROFILER_STARTUP=1), it works. I opened Firefox, enabled profiler as quickly as possible, open website and then capture profile.

Gerald, does this sound familiar? Can it be related to any recent landing?

Flags: needinfo?(gsquelart)

(In reply to Florian Quèze [:florian] from comment #40)

(In reply to Filip Š from comment #39)

I can't collect a new profile.
...
Gerald, does this sound familiar? Can it be related to any recent landing?

Nothing obvious. But I can see that locally, so I'll try and bisect... I'll open a separate bug too (assuming it's a different issue from the OP).

Flags: needinfo?(gsquelart)

Though I can reproduce the MOZ_PROFILER_STARTUP=1 issue 100% in a local build, I don't see it in moz-regression so I can't easily find the source of the issue. And I don't know much about how the add-on/popup get the data and send it to the front-end, so I'm not sure how to debug further (yet).
Greg, you've got recent experience working on the popup, could you please have a look? (If you can reproduce the issue from comment 39.) Or contact me to discuss...

Flags: needinfo?(gtatum)

I don't believe these steps are hitting the new popup code. The installation instructions are still pointing folks to use the extension, so it's using the old tried and true method. I can successfully capture a profile on Beta (68) and Nightly (69) using the above flags. It could be that the request is just taking a really really long time. I'm not sure if the console spit out any errors, but the UI should report errors that happen in profile capturing pipeline.

Flags: needinfo?(gtatum)

Filip, can you reproduce the slow load with LSNG disabled (as described in comment 36) and only uBlock origin enabled?

When all extensions are enabled and LSNG is disabled it rakes about 4 seconds. When only uBlock Origin is enabled and LSNG is disabled it takes about 2 seconds.

Ok, there was a regression on the profiler that was fixed late last week where we hung on the loading screen waiting for symbolication.

We deployed a change, the service worker may need to be updated to see the change. There is UI that shows up or you can hit shift+refresh to double check.

https://github.com/firefox-devtools/profiler/pull/2136

I just deployed the aforementioned fix to production. Please go to https://profiler.firefox.com once to make sure the service worker is updated (some notification should popup once it's done) before trying to capture. Sorry about this :/

I captured new profiles with LSNG disabled:

All extensions: https://perfht.ml/2XBolmi
Only uBlock Origin: https://perfht.ml/2XAIxF1

At this point, I'm not seeing anything obvious in the profile from comment 48. The load of slo-tech.com is initiated at about 1.6s and blocked by uBO until about 3.8s. But neither the extension process or the parent process are especially busy during that time. Profiles don't contain a detailed trace of extension activity during this time so I'm unable to tell what's happening.
I notice that :gorhill is already on the cc list here, do you have any insight?

Flags: needinfo?(rhill)

I cc'ed myself after reading comment 33. uBO does use localStorage.getItem at launch time to configure some aspects of itself, where an asynchronous call wouldn't work.

One way to find out if the new localStorage implementation is causing the issue would be to change an advanced setting in uBO which tells it to no longer hold back network requests at launch until it is ready. So if Filip can try this in uBO:

  • Go to the "Settings" pane in uBO's dashboard
  • Enabled "I am an advanced user"
    • I little gear icon will appear aside that side
  • Click the little gear icon at the end of the "I am an advanced user" setting
    • A new page open with a list of raw settings
  • Change the suspendTabsUntilReady entry to no
  • Click "Apply changes"

Now uBO has saved data into its localStorage which it will use to decide whether it should hold all network requests back at launch until all the filter lists are loaded and ready. When suspendTabsUntilReady is set to no, it won't hold back. However uBO still need to get the configuration from localStorage, so my thinking is that if despite that setting the undue delay at launch is still there, than it's reasonable to conclude the source of the delay is accessing localStorage at launch.

To figure out the involvement of QuotaManager, these are the parent process threads of interest:

  • "IPDL Background": This is the "PBackground" thread where all PBackground IPC messages are serviced. Notably, there is where IndexedDB (IDB) and LocalStorage NG (LSNG) requests go. This thread only ever exists in the parent process.
  • "QuotaManager IO": This is where QuotaManager IO happens for initialization and for initial acquisition of "directory locks" which are handed out to the QuotaManager Clients like IndexedDB and LSNG. Once a lock has been acquired, further IO for that client (ex: IDB) will happen on an IO thread owned by that client.
  • "LS Thread": This is the LSNG IO thread. All LSNG IO happens on this thread once a directory lock has been acquired for the given origin.
  • "Indexed": The thread names are of the form "IndexedDB #1" and "IndexedDB #2" but eventually the number gets large and some code somewhere has to squish the string into a fixed length so it ends up like "Indexed~ #18506". These are per-database connection threads for IndexedDB. Because IndexedDB auto-closes database connections under the hood when they've been idle for a while, there will be some potential churn here for long-lived IDB consumers that only sporadically open transactions.

Note that since bug 1474562 landed, I believe that WebExtensions' use of storage.local is backed by IndexedDB. (Note: I don't know how storage.sync is stored.) This means that any data dependency on storage.local or IndexedDB will still need to wait for QuotaManager initialization and the relevant database to be opened. The key thing is that as long as LSNG is disabled, these accesses can't synchronously block the process.

See Also: → 1570644
Component: General → DOM: Web Storage
Product: Firefox → Core

Hi Filip,

Would you mind helping me to check if this issue is still on the lastest Nightly? We recently improved the initialization time on storage which might help to fix this issue. Thanks in advance!

Depends on: 1563023
Flags: needinfo?(rhill) → needinfo?(filip.stamcar)

It is now probably fixed. Websites still load about a second slower on startup, but this is probably expected and not actually so noticeable.

Flags: needinfo?(filip.stamcar)

Marked as Resolved/Incomplete, as we did no explicit fix. Please reopen it or file a new bug, if the problem appears again. Thank you!

Status: UNCONFIRMED → RESOLVED
Closed: 5 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: