Open Bug 1445965 Opened 3 years ago Updated 2 years ago
Firefox hangs when typing immediately in the address bar on start due to Speculative Connections nss initialization
User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0 Build ID: 20180310025718 Steps to reproduce: Start Firefox from version 58 onwards and immediately start typing into the address bar. Actual results: Firefox freezes for 1-2 seconds. After this short period, Firefox is again workable. If you continued typing in the period that Firefox is freezed, the browser has buffered what you typed *after* the crash and displays the text (URL or text for search). Expected results: Firefox should not have freezed and the URL bar should be responsible immediately after you launch the browser.
If you think that some add-on creates the problem, please
Severity: normal → major
Component: Untriaged → Address Bar
OS: Unspecified → Windows 7
Priority: -- → P4
Hardware: Unspecified → x86_64
Summary: Firefox hangs when typing in address bar on start → Firefox hangs when typing immediately in address bar on start
Forgot to mention that if you close and re-open the browser, issue re-appears. This does not apply to new windows or tabs, if an instance of FF is running. I have tested in different PC with Windows 7 as also as on Windows 10 (version 1803 and above) and the issue persists. If you think that some add-on creates the problem (although unlikely), please feel free to ask me my full list of them.
we need a performance profile taken when the problem happens to be able to debug it. See https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Reporting_a_Performance_Problem and https://perf-html.io/
Priority: P4 → --
LP, are you able to take a profile as Marco requested? (In reply to Marco Bonardo [::mak] from comment #3) > we need a performance profile taken when the problem happens to be able to > debug it. > See > https://developer.mozilla.org/en-US/docs/Mozilla/Performance/ > Reporting_a_Performance_Problem > and https://perf-html.io/
Apologies for my late reply. Attached is the profiler .gz file. I opened Firefox, started the profiler and just navigated to Google.gr from the address bar. Regards, Lefteris
(In reply to LP from comment #5) > Created attachment 8976496 [details] > Firefox 2018-05-17 14.40 profile.sps.json.gz > > Apologies for my late reply. Attached is the profiler .gz file. I opened > Firefox, started the profiler and just navigated to Google.gr from the > address bar. > > Regards, > Lefteris Please note that the problem continues all the way up to Firefox 60.0 release.
I do see a 5s hang there, unfortunately the profile doesn't seem to have symbols and as such I can't tell what's up. Is this an official build from mozilla.org? Please check again in perf-html.io to get a profile with stacks and then a direct link to it will be fine. You can also check if safe mode helps: https://support.mozilla.org/kb/troubleshoot-firefox-issues-using-safe-mode Finally, we know that some Antivirus may create problems on startup, is your AV up-to-date and what is it?
Hello, This is a production build. I started noticing the problem with FF 58.0 and it continued all the way up to FF 60.0.2 (the update was applied today). All versions are in 64bit. The OS is Windows 7.** Here's the link of the profiler: https://perfht.ml/2Hts1tm. I had stacks checked but just to be sure, I checked all the options of the profiler. Starting Firefox in Safe Mode, did not solve the problem. It still hangs for 5s. The anti-virus installed is McAfee; this a company laptop, so it is being updated to the latest version of the AV but I do not have any control in disabling or configuring it. Regards, Lefteris ** I had the problem also with my personal laptop with Windows 10 (v. 1803) but the latest versions seem to have lowered the hang in just below 2s. The profiler link is from my corporate Windows 7 laptop.
OK, this one is better and has stacks. Indeed this is a hang caused by the Address Bar, BUT it's actually due to something in network. Basically the Address Bar uses a feature named Speculative Connection, that allows to initialize a connection a little bit earlier, for performance reasons. When you first use the Address Bar, we call mozilla::net::nsHttpsHandler::SpeculativeConnect2, that initializes nss, that queries a Sqlite database, that in your case seems to take 4 seconds, at least. You may try to set browser.urlbar.speculativeConnect.enabled to false in about:config and that may be enough to workaround your problem.
Status: UNCONFIRMED → NEW
Component: Address Bar → Networking
Ever confirmed: true
Product: Firefox → Core
Summary: Firefox hangs when typing immediately in address bar on start → Firefox hangs when typing immediately in the address bar on start due to Speculative Connections nss initialization
If the networking team can't solve this slowdown, we could evaluate doing something in the UI, like waiting for the first idle to initialize speculative connections, and then using the feature from that point on. But this is likely something that can affect other consumers, so a centralized solution (even doing that same thing) would probably be nicer.
Thanks for your answer. Changing the browser.urlbar.speculativeConnect.enabled property to false indeed solved the problem in the URL bar but I just inspected that the problem continues when clicking a URL from my bookmarks. Here is a link from a healthy profiler that I am typing "www.google.gr" in my address bar: https://perfht.ml/2HvPwSL Here is a link from a problematic profiler that I am clicking on a bookmark link: https://perfht.ml/2HtaLEQ Both tests were performed on the same browser, immediately after opening Firefox, with a close and re-open in-between them and with speculative connect disabled. In the first scenario, after loading Google.gr, I was able to open the same bookmark without any delays. Regards, Lefteris
If I'm reading the profile correctly, the main thread is spending a ton of time in NtQueryFullAttributesFile. Is your profile directory on a networked drive? (see about:profiles) If so, you could try setting the environment variable NSS_SDB_USE_CACHE to yes (it should be auto-detected and set by default in 61 - see bug 1435376).
Hello, No, none of the three profiles of Firefox are on a network drive; all three are stored locally, in C:\Users.
I'll try to land bug 1435141, which will probably improve the situation here.
Assignee: nobody → valentin.gosu
Depends on: 1435141
Priority: -- → P2
Whiteboard: [fxsearch][fxperf] → [fxsearch][fxperf][necko-triaged]
This seems important enough to me to be an fxperf:p2. Let's see how much bug 1435141 helps, and failing that, perhaps we can disable speculative connection until we know that NSS is warmed up.
Whiteboard: [fxsearch][fxperf][necko-triaged] → [fxsearch][fxperf:p2][necko-triaged]
(In reply to Mike Conley (:mconley) (:⚙️) (Catching up on needinfos / reviews) from comment #15) > This seems important enough to me to be an fxperf:p2. Let's see how much bug > 1435141 helps, and failing that, perhaps we can disable speculative > connection until we know that NSS is warmed up. As mentioned in comment 11, disabling speculative connect helps _a bit_™. But it seems NSS init is still the big pain point, so I'm not sure how much we can improve things there.
Assignee: valentin.gosu → nobody
Priority: P2 → P3
You need to log in before you can comment on or make changes to this bug.