1468889 - Firefox temporarily freezes when opening new tabs

Status: RESOLVED WORKSFORME

(Core :: DOM: Content Processes, defect, P3)

Description

[[e-mail]]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0
Build ID: 20180516032328

Steps to reproduce:

When opening a new tab, Firefox will occasionally freeze and stop working for roughly 0.5 to 2 seconds. While those hiccups aren't a major problem, they are a constant annoyance.

From my observations, this is most likely caused by multiprocess support: When opening a new tab Firefox also starts a new Web process if it's below its limit of processes. Opening this new process seems to be what's causing the browser to temporarily stop working.

Ideally Firefox can solve what's causing the hiccup internally. If this is a system issue, a workaround would be to open the maximum number of Web processes when Firefox starts, rather than opening and closing them dynamically based on tab count: While this might cause a bit of extra memory to be used, it might be better than FF hiccuping as you open new tabs.

It should be noted that I'm noticing this issue on Linux (openSUSE Tumbleweed x64). I'm not aware whether it's also the case on Windows.

Comment 1

[Abe - QA (:Abe_LV)]

Hi,

I tested this on Ubuntu 16.04 with Firefox 60.0.2, but could not manage to reproduce it. It does not take more than a half second to open a new tab. However, I am not on OpenSUSE, so that could be one reason.

Could you please provide a profile using the gecko profiler addon? Steps are here- https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Reporting_a_Performance_Problem


Thanks

test env't:
----------
Version 	60.0.2
Build ID 	20180605171542
Update Channel 	release
User Agent 	Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0

Comment 2

[[e-mail]]

(In reply to Abe - QA (:Abe_LV) from comment #1)

https://perfht.ml/2yrwFsN

I started a new instance of Firefox, opened random sites from my history, and should have captured at least one if not two of the freezes. Indeed they only last for roughly 0.75 seconds, but that's still a noticeable time.

Is there an option to preemptively start every Web.exe process with Firefox and disable the dynamic starting / closing of those processes? I'm curious if that will fix the problem, which I suspect that it would.

Comment 3

[Abe - QA (:Abe_LV)]

@mconley, what is your suggestion on this profile, comment 2? Thanks

Comment 4

[Mike Conley (:mconley) (:⚙️)]

Hm. Some pretty funky behaviour going on here when launching the content process. There's a significant chunk of time missing in the main thread of the new content process when the parent process is being blocked in LaunchSubprocess. Presumably, this is before the profiler has actually started sampling in the process, so it's pretty early on.

So the profile doesn't tell us much, except that there's a block box before sampling that we need better visibility into. The perf profiler on Linux might be a better choice here.

Hey rjesup, do we have the capability of loading perf profiles in perf.html yet? And if so, is there a guide on how the reporter here could gather a profile for us to look at with it for his content process start-up?

Comment 5

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

The symbols in the profile in comment #2 seem very wrong.  Maybe this would work better with one of Mozilla's official builds?

Even so, if I right-click the ContentParent::LaunchSubprocess frame and choose “Focus on subtree”, it definitely seems to be doing *something*, calling and returning from various functions, and not just blocking; if it were blocked I'd expect to see the same stack for many consecutive samples.

I also notice that the first 100-150ms of the mystery time are spent in libfontconfig, which is worrying, and might have something to do with the larger 1-2s mystery time after that.  (The library name should be reliable, even if the symbol names aren't.)  Maybe this is related to bug 1412090?

Comment 6

[[e-mail]]

This is interesting. I was sure what I'm seeing was a common issue (at least on Linux). I would be happy if someone could better explain what's causing the slowdowns so we know: If it's a bug in Firefox this hopefully helps find it... if it's a compilation issue, perhaps we can let the openSUSE team know about it.

Comment 7

[Daniel Holbert [:dholbert]]

(In reply to Jed Davis [:jld] (⏰UTC-6) from comment #5)
> I also notice that the first 100-150ms of the mystery time are spent in
> libfontconfig, which is worrying, and might have something to do with the
> larger 1-2s mystery time after that.  (The library name should be reliable,
> even if the symbol names aren't.)  Maybe this is related to bug 1412090?

(and maybe bug 1439412 would help? In any case, probably qf- since this is Linux-only which puts it out of scope for qf)

Comment 8

[[e-mail]]

This is still a problem in Firefox 65 and latest openSUSE Tumbleweed snapshot. Has an alternative been found yet?

Like I said, a very easy fix for the time being would be an option to spawn the maximum number of processes when Firefox starts. The freezing only occurs because the browser keeps starting and stopping new processes each time you open or close a tab. Having the maximum number of window processes open from the start would move those delays to startup and we'd never experience any hiccups during usage.

Comment 9

[Jonathan Kew [:jfkthame]]

What version of fontconfig is present on the problem system? I think I remember seeing a problem like this where updating to a more recent fontconfig led to a big improvement.

Comment 10

[[e-mail]]

(In reply to Jonathan Kew (:jfkthame) from comment #9)

2.13.1

I use openSUSE Tumbleweed which is a rolling release distribution updated every few days, so it likely has the latest versions of all important packages.

Comment 11

[Jonathan Kew [:jfkthame]]

OK, sounds like this is different, then. The previous issue was resolve in fontconfig 2.13, IIRC.

Comment 12

[crocodile2u]

I'm on Ubuntu 19.10, just installed FF 71.0 (64-bit). This issue affects me as well and is a show-stopper. BTW, for me also closing tabs takes up to a few seconds.

Comment 13

[Arnold]

Ah, I'm glad I found this issue.

So, I stopped tab-hoarding just recently, and now I'm using only a few tabs at the same time. That means I no longer have all content processes running in the background, as they are spawned on demand, one per each new tab, until hitting the dom.ipc.processCount limit.

I can observe, that when a new tab is opened (from a bookmark or a link click), and a new content process is going to be spawned for that tab, there is a 1.5 - 2 s delay until the tab actually starts loading the webpage (the moment when spinner animation and DNS lookup kicks in).

I've captured such a situation, and here is the output from the profiler: https://perfht.ml/2WukxA2.

I'm using Ubuntu 20.04, I tried clean profiles, and Firefox 75, 76, Beta, Nightly. The issue is still present. It's quite infuriating, to be honest.

As a workaround, I set dom.ipc.processCount to 2, so there are no new processes spawned after opening 2 tabs, and new tabs (3, 4..) start loading webpages immediately. But obviously, that isn't a solution, and I'd rather utilize more processes.

Even if it was possible to enforce spawning the maximum number of content processes at once (as the OP suggests), that isn't a solution either, given you guys can't reproduce the issue, so there must be something buggy about the IPC mechanism.

Thanks in advance for investigating the issue.

Comment 14

[Randell Jesup [:jesup] (needinfo me)]

Can you check that the list of modified preferences in about:support? In particular, dom.ipc.processPrelaunch.enabled - we should prelaunch processes when we have 'idle' time, so opening a new tab should just use an existing process.

If you could take a new profile that would let us verify (profiler UI is now built in; you can use Customize off the 'hamburger' menu to add a button for it to the toolbar).

Thanks

Comment 15

[[e-mail]]

Attachment: Important Modified Preferences

Update: I can't say I've seen this issue recently at least not in obvious form, though I do have several tabs open (albeit inactive as I don't select them after startup). When I close more of them I'll take a closer look. At the moment my OS (openSUSE Tumbleweed x64) updated me to Firefox 78.0.2.

As for the question; dom.ipc.processPrelaunch.enabled is at the default value of true. I attached my Important Modified Preferences entries from about:support in this comment.

Comment 16

[Lyubomir [:mystiquewolf]]

I'm also experiencing this with dom.ipc.processPrelaunch.enabled == true on Kubuntu 20.04.2. Doesn't happen always, but frequently enough.

Comment 17

[Lyubomir [:mystiquewolf]]

So here is a profile: https://share.firefox.dev/3nm5HZC

Comment 18

[Lyubomir [:mystiquewolf]]

I'm using Auto tab discard add-on, not sure if this has something to do with it.

Comment 19

[Lyubomir [:mystiquewolf]]

I'm using Auto tab discard add-on, not sure if this has something to do with it.

Nope, it still reproduces when the extension is disabled.

Comment 20

[Gian-Carlo Pascutto [:gcp]]

I've captured such a situation, and here is the output from the profiler: https://perfht.ml/2WukxA2.

Presuming the stacks there were accurate, a ton of time seems to be spent parsing GTK CSS themes. We currently initialize GTK for every process, though that's being removed right now in bug 1635451. We've noticed a clear but small speed benefit here, but I guess in extreme circumstances (very complex themes or themes that trigger worst case behavior in GTK's parser), it might be a huge speedup.

So here is a profile: https://share.firefox.dev/3nm5HZC

There's indeed a 2s period here where...nothing seems to happen? Though the new tab seems to have forced the WebExtensions process to initialize, which happens about 1s in that period.

Comment 21

[Lyubomir [:mystiquewolf]]

I believe i haven't seen this after enabling fission on release.

Comment 22

[Wayne Mery (:wsmwk)]

(In reply to Lyubomir from comment #21)

I believe i haven't seen this after enabling fission on release.

sonichedgehog, do you agree?

Comment 23

[[e-mail]]

(In reply to Wayne Mery (:wsmwk) from comment #22)

(In reply to Lyubomir from comment #21)

I believe i haven't seen this after enabling fission on release.

sonichedgehog, do you agree?

I would say yes. Haven't seen this in well over an year myself, during which I also changed Linux distributions and didn't notice it in either (openSUSE -> Manjaro). I may have enabled a few custom settings that improved it, I presume the relevant ones have become defaults since? If I see this particular issue again I can hopefully reopen it, for now though it feels safe to close.