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

Status: RESOLVED FIXED

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

Description

[Zitronella]

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

Comment 1

[dharkness21]

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

Comment 2

[Gingerbread Man]

Possibly a result of bug 1474285.

Comment 4

[Lukas]

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

Comment 5

[Gingerbread Man]

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

Comment 6

[Marat Tanalin]

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.

Comment 7

[Marat Tanalin]

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

Comment 8

[Masatoshi Kimura [:emk]]

Regression range per comment #6:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=4ab143dde4dc3424cfedc74b3648fbf2e47fb7bf&tochange=c89f024c023fa816d700b151e8e0cbb9a1907cb8

Comment 9

[Masatoshi Kimura [:emk]]

Bug 1518639?

Comment 10

[Dave Townsend [:mossop]]

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

Comment 11

[Marat Tanalin]

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

Comment 12

[Dave Townsend [:mossop]]

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.

Comment 13

[Marat Tanalin]

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

Comment 14

[Dave Townsend [:mossop]]

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

Comment 15

[Marat Tanalin]

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

Comment 16

[atlanto]

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

Comment 17

[Denis Palmeiro [:denispal]]

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

Comment 18

[atlanto]

https://hg.mozilla.org/mozilla-central/annotate/767ee8714acf825c878a4079eeb40aaf27abb738/toolkit/xre/nsAppRunner.cpp#l3861

mRemoteService->LockStartup();

At least, this takes 5 seconds on my PC in the process which is launched by LaunchChild in ShowProfileManager.
https://hg.mozilla.org/mozilla-central/annotate/767ee8714acf825c878a4079eeb40aaf27abb738/toolkit/xre/nsAppRunner.cpp#l1935

Comment 19

[Masatoshi Kimura [:emk]]

So it is failing to lock the mutex dir for some reason.
https://searchfox.org/mozilla-central/rev/040aa667f419932adf425d92c7438f03230ad96b/toolkit/components/remote/nsRemoteService.cpp#67-72

Comment 20

[atlanto]

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

Comment 21

[:Gijs (he/him)]

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

Comment 22

[Liz Henry (:lizzard) (relman/hg->git project)]

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.

Comment 24

[Mikael Håkansson]

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.

Comment 26

[[e-mail]]

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.

Comment 29

[Dave Townsend [:mossop]]

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

Comment 30

[Alex Thayer [:alexical] (she/her)]

Sure thing!

Comment 31

[Alex Thayer [:alexical] (she/her)]

Attachment: Bug 1553399 - Unlock nsRemoteService before launching child r?mossop

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.

Comment 32

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/53c5b8e49f49
Unlock nsRemoteService before launching child r=mossop

Comment 33

[vas]

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.

Comment 34

[Dave Townsend [:mossop]]

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

Comment 35

[Iulian Moraru]

https://hg.mozilla.org/mozilla-central/rev/53c5b8e49f49

Comment 36

[BugBot [:suhaib / :marco/ :calixte]]

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.

Comment 37

[Alex Thayer [:alexical] (she/her)]

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.