1800088 - Firefox profiles are opened with a delay of about 40 seconds when using the "--first-startup" syntax

Status: RESOLVED WORKSFORME

(Firefox :: Normandy Client, defect)

Description

[Simona Rosu [:srosu], Ecosystem QA]

Attachment: FirefoxFirstStartUPprofiles_delay.gif

[Affected versions]:

• Firefox Nightly 108.0a1 (Build ID: 20221110092309)
• Firefox Release Candidate 107.0 (Build ID: 20221107173030)
• Firefox Release 106.0.5 (Build ID: 20221104133228)

[Affected Platforms]:

• Windows 10 x64
• Windows 11 x64
• macOS 12.5.1
• Linux Mint 20.2 x64

[Prerequisites]:

• Have the latest versions of the Firefox browser installed.
• Have the “-p –first-startup” syntax added to its target.

[Steps to reproduce]:

1. Double-click the Firefox shortcut.
2. Create a new profile and open it.
3. Observe what happens.

[Expected result]:

• The Firefox profile opens instantly.

[Actual result]:

• Nothing happens for about 30-40 seconds, and after that, the browser opens.

[Notes]:

• Attached is a screen recording of the issue.

Comment 1

[Dave Townsend [:mossop]]

Looks suspicious... https://searchfox.org/mozilla-central/rev/d1fe4b6dd7027a54c17ce3030948a1be354598ab/toolkit/modules/FirstStartup.sys.mjs#44

Comment 2

[Dave Townsend [:mossop]]

With some quick debugging this is happening because the normandy task started as part of the first startup code blocks until the main window opens, causing us to block startup for 30 seconds until proceeding anyway.

A couple of things I noticed while diagnosing this:

1. Normandy init is called twice when -first-startup is passed. Once from FirstStartup.sys.mjs and once from BrowserGlue.jsm. The latter actually happens first. I don't know if this is a problem or not.
2. Both of the calls end up blocking waiting for remote settings to return a response so I don't know if that is actually where the problem lies.

Comment 3

[Dan Mosedale (:dmosedale, :dmose)]

Given https://bugzilla.mozilla.org/show_bug.cgi?id=1797423#c22, it would be interesting to try turning off HTTP/3 and seeing if this problem goes away...

Comment 4

[Beth Rennie [:beth] (she/her)]

Bug 1749345 might be related/have the same root cause?

Comment 5

[Simona Rosu [:srosu], Ecosystem QA]

I haven't reproduced this issue in the last 2 days. Maybe, it has been fixed by disabling HTTP3 from the production CDN. (see comment 11). Tested using the latest Firefox Nightly 108.0a1 (Build ID: 20221112215806), Firefox Release Candidate 107.0 (Build ID: 20221110173214), and Firefox Release 106.0.5 (Build ID: 20221104133228) on Windows 10 and 11 x64.

• Now, the Firefox profiles open instantly using the "--first-startup" syntax.

Comment 6

[:Gijs (he/him)]

(In reply to Simona Rosu [:srosu], Ecosystem QA, PTO - NI to: [e-mail] from comment #5)

I haven't reproduced this issue in the last 2 days. Maybe, it has been fixed by disabling HTTP3 from the production CDN. (see comment 11). Tested using the latest Firefox Nightly 108.0a1 (Build ID: 20221112215806), Firefox Release Candidate 107.0 (Build ID: 20221110173214), and Firefox Release 106.0.5 (Build ID: 20221104133228) on Windows 10 and 11 x64.

• Now, the Firefox profiles open instantly using the "--first-startup" syntax.

Should we resolve this bug wfm given this and the fact that bug 1749345 is open for the generic issue around timeouts used here?

Comment 7

[Dan Mosedale (:dmosedale, :dmose)]

Sounds reasonable to me. We can always re-open if it resurfaces.

Comment 8

[Dave Townsend [:mossop]]

I guess the risk is that this comes back if we re-enable HTTP/3 on the CDN side. From bug 1797423 comment 42 that sounds like it may be a while out so given the future plans for Normandy I think it's reasonable to just ignore this at this point.