Closed Bug 1553399 Opened 3 years ago Closed 9 months ago

Firefox start slowly when started through ProfileManager (ProfileManager doesn't unlock the mutex dir before launching the child)

Categories

(Toolkit :: Startup and Profile System, defect, P3)

67 Branch
defect

Tracking

()

RESOLVED FIXED
90 Branch
Tracking Status
firefox-esr60 --- unaffected
firefox-esr78 --- wontfix
firefox67 --- wontfix
firefox67.0.1 --- wontfix
firefox68 --- wontfix
firefox69 --- wontfix
firefox70 --- wontfix
firefox88 --- wontfix
firefox89 --- wontfix
firefox90 --- fixed

People

(Reporter: zitrobugs, Assigned: dthayer)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: regression, Whiteboard: [fxperf:p3][qf:p3:responsiveness])

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:67.0) Gecko/20100101 Firefox/67.0

Steps to reproduce:

Start Firefox 67 release (64bit) with ProfileManager.
In profiles.ini is the entry:
[General]
StartWithLastProfile=0
Version=2

select a profile and press button "Start Firefox"

Actual results:

Since Firefox 67 release (64bit) firefox starts very slowly with ProfileManager after I have selected the profile and pressed the button "Start Firefox"
(With Firefox 66.0.5 it started quickly)

Expected results:

Firefox should start as fast as without ProfileManager with the entry
[General]
StartWithLastProfile=1
Version=2

I can confirm the problem like this.

OS: Windwos 10 Pro 64Bit
Browser: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:67.0) Gecko/20100101 Firefox/67.0 - Build-Id: 20190516215225

and

OS: Windwos 10 Pro 64Bit
Browser: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:69.0) Gecko/20100101 Firefox/69.0 - Build-ID: 20190525213840

Possibly a result of bug 1474285.

Component: Untriaged → Startup and Profile System
Flags: needinfo?(dtownsend)
Product: Firefox → Toolkit
Duplicate of this bug: 1554288
Regressed by: 1474285
Flags: needinfo?(dtownsend)
Priority: -- → P3

status-firefox67:wontfix??? Like there is problem, but nobody will repair it?

(In reply to Lukas from comment #4)

status-firefox67:wontfix???

Firefox 67 is the current release. The only fixes for current releases are for security vulnerabilities and severe issues like frequent crashes. Bugs of this one's severity are fixed in the next major version at the earliest.

Firefox 67 starts multiple times slower than Firefox 66.
I use the profile manager (firefox -p) too.

According to my investigation, the first problematic build is:
2019-03-07-09-49-51-mozilla-central (67.0a1, 20190307094951)

The previous one is fine:
2019-03-06-16-13-00-mozilla-central (67.0a1, 20190306161300)

The latest Nightly (69.0a1, 20190609214350) and Developer Edition (68.0b8, 20190606101422) are still affected.

Fwiw, the issue reproduces in both Windows 10 Pro (version 1809) and Windows 7 Home Premium (SP1).

Flags: needinfo?(dtownsend)

It's not clear what the needinfo request was for here?

Flags: needinfo?(dtownsend) → needinfo?(mtanalin)

(In reply to Dave Townsend [:mossop] (he/him) from comment #10)

Just your awareness of this bug (now you are obviously aware) and probably a substantive comment from you as the author of the change presumably caused this bug, regarding when approximately the bug is going to be fixed or the change temporarily backed-out. Thanks.

Flags: needinfo?(mtanalin)

It's unclear what change caused this but it is unlikely it would be backed put at this point. I marked this as P3 a few weeks indicating that there are other more important issues to be fixed, there is currently no estimate for when this might be resolved.

(In reply to Dave Townsend [:mossop] (he/him) from comment #12)

It's unclear what change caused this

Please see comments #6 and #9. Exact build (20190307094951), regression range, and the potential causing bug are known.

(In reply to Marat Tanalin from comment #13)

(In reply to Dave Townsend [:mossop] (he/him) from comment #12)

It's unclear what change caused this

Please see comments #6 and #9. Exact build (20190307094951), regression range, and the potential causing bug are known.

Yes I saw, it is currently narrowed down to a dozen patches containing quite a lot of changes.

(In reply to Dave Townsend [:mossop] (he/him) from comment #14)
OK. As for priority, this issue literally ruins the efforts of making Firefox start as fast as possible. It is now painful to start Firefox.

Bad Case: firefox.exe -p
https://perfht.ml/2XZRS5v

Good Case: firefox.exe -p -no-remote
https://perfht.ml/2XYCjuI

Good Case: firefox.exe -p profilename
https://perfht.ml/2XYCp5y

Whiteboard: [qf][fxperf]

NI myself so I can try to reproduce this on my side.

Flags: needinfo?(dpalmeiro)
Whiteboard: [qf][fxperf] → [fxperf][qf:p3:responsiveness]

(I'm guessing mRemoteService->UnlockStartup() should be performed immediately while lanching child maybe. See also bug 1553781(I'm not understanding though))
(this may be wrong of course)

Given that we don't expose the profile manager or consider it primary UI, this gets fxperf:p3 if that.

Summary: Firefox start slowly with ProfileManager → Firefox start slowly when started through ProfileManager
Whiteboard: [fxperf][qf:p3:responsiveness] → [fxperf:p3][qf:p3:responsiveness]
Flags: needinfo?(dpalmeiro)

Happy to take a patch for 70 or beyond.
Since we are getting close to the end of the 69 beta cycle and this is set to P3, I'm marking it fix-optional for 69 and 70 to remove it from weekly triage.

Duplicate of this bug: 1584010

With mozregression I get below.

Bug 1518639: Implement windows remoting server and client. r=jimm

Implements the windows remove client and server based on the current remoting
code in nsNativeAppSupportWin.cpp. Makes the hidden window classname encode both
program name and profile name. nsNativeAppSupportWin is now just used for
setting up the console.

Differential Revision: https://phabricator.services.mozilla.com/D19076

Maybe that helps narrow it down.

Flags: needinfo?(dtownsend)
Duplicate of this bug: 1590614

I would like to add that when I clicked the start button on profiles through the about:profiles manager Firefox loads fast normal 1.2 seconds. But when I launch Firefox from the executable on windows it takes the long 6 seconds. It it very odd that I am getting the complete opposite effects to the bug 1590614 I recently opened which affected me starting from the Firefox v68 release. You will find my current system environment details on that bug.

Flags: needinfo?(dtownsend)
Regressed by: 1518639
No longer regressed by: 1474285
Summary: Firefox start slowly when started through ProfileManager → Firefox start slowly when started through ProfileManager (ProfileManager doesn't unlock the mutex dir before launching the child)
Duplicate of this bug: 1651596
Duplicate of this bug: 1678864

Doug this keeps coming up and I haven't had any time to look into it, any chance you could take a look?

Flags: needinfo?(dothayer)

Sure thing!

Assignee: nobody → dothayer
Status: NEW → ASSIGNED
Flags: needinfo?(dothayer)

This fixes the issue for me. I can't think of any problems with doing this
here? However I am not an expert in the remote service. As part of this I also
cover the case where the user encounters the profile lock dialogue and selects
to kill the existing instance of Firefox. This can result in a slow startup in
a similar way as far as I've been able to observe.

Pushed by dothayer@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/53c5b8e49f49
Unlock nsRemoteService before launching child r=mossop

Please push this fix to the stable channel. This annoys me since 83, I reported it back then but you didn't see it as an issue back then.

(In reply to vas from comment #33)

Please push this fix to the stable channel. This annoys me since 83, I reported it back then but you didn't see it as an issue back then.

This fix would not be accepted on the release channel, we might be able to take it for the next beta though.

Status: ASSIGNED → RESOLVED
Closed: 9 months ago
Resolution: --- → FIXED
Target Milestone: --- → 90 Branch

The patch landed in nightly and beta is affected.
:dthayer, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.

Flags: needinfo?(dothayer)

While I sympathize with any affected users who have had to suffer through this for a while, I think the reality is this is pretty mild, and the vast majority of users don't launch Firefox through the profile manager, so I don't think this warrants the added risk of uplifting it.

Flags: needinfo?(dothayer)
Has Regression Range: --- → yes
You need to log in before you can comment on or make changes to this bug.