Firefox temporarily freezes when opening new tabs

UNCONFIRMED
Unassigned

Status

()

defect
P3
normal
UNCONFIRMED
Last year
3 months ago

People

(Reporter: sonichedgehog_hyperblast00, Unassigned, NeedInfo)

Tracking

(Depends on 1 bug)

60 Branch
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [qf-])

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.
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
Flags: needinfo?(sonichedgehog_hyperblast00)
(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.
Flags: needinfo?(sonichedgehog_hyperblast00)
@mconley, what is your suggestion on this profile, comment 2? Thanks
Flags: needinfo?(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?
Component: Untriaged → DOM: Content Processes
Flags: needinfo?(mconley) → needinfo?(rjesup)
Product: Firefox → Core
Whiteboard: [qf]
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?
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.
(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)
Depends on: 1439412
Whiteboard: [qf] → [qf-]
Priority: -- → P3

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.

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.

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

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

You need to log in before you can comment on or make changes to this bug.