1593137 - Preferences taking 60 seconds to open for a particular user (due to (many?) slow/mainthread moz-icon loads)

Status: VERIFIED FIXED

(Firefox :: Settings UI, defect, P3)

Description

[Mike Kaply [:mkaply]]

Attachment: Firefox.2019-10-31.17.49.profile.json.gz

I have a user reporting that opening preferences takes 60 seconds on 68 ESR.

Hopefully the attached profile is useful. I don't know how to read it.

Conversation is here:

https://github.com/mozilla/policy-templates/issues/480

We thought it was policies originally, but he removed that from the equation.

Comment 1

[:Gijs (he/him)]

If they close Firefox, move their handlers.json file out of their profile (or rename it), and reopen Firefox and the prefs, does the problem go away?

Is the profile or the main windows disk on a network drive?

Comment 2

[Florian Quèze [:florian]]

(In reply to Mike Kaply [:mkaply] from comment #0)

Hopefully the attached profile is useful. I don't know how to read it.

The useful part of the profile shows bug 622840.

Comment 3

[Stephen]

(In reply to :Gijs (he/him) from comment #1)

If they close Firefox, move their handlers.json file out of their profile (or rename it), and reopen Firefox and the prefs, does the problem go away?

Is the profile or the main windows disk on a network drive?

I renamed handlers.json to .OLD, relaunched Firefox, and I still experience the delay opening the about:preferences tab. Any other suggestions?

Thanks!

Comment 4

[Florian Quèze [:florian]]

This was reported on Firefox ESR so I assume you are experiencing this in an enterprise environment. Do you have network drives that might take longer to access than local drives?

Is there any chance you could capture a profile again after increasing the buffer size in the profiler settings and enabling the "Main Thread IO" feature of the profiler? Thanks!

Comment 5

[Stephen]

This seems to only be an issue on Windows 7 SP1 Enterprise. So far I have been unable to reproduce the issue on Windows 10.

Comment 6

[Stephen]

Sorry I missed the other question. The profile is local to the device. We do have network drives, but only for shared files/folders. All apps/profiles are on local drive.

Comment 7

[Stephen]

I'm attempting to capture a new profile, but it appears profiler.firefox.com is unreachable at this time.

Comment 8

[Timothy Nikkel (:tnikkel)]

Bug 1530190 should have made these calls off main thread and async, it landed in 69, so it's not in esr 68.

Comment 9

[Stephen]

Attachment: Firefox 2019-11-04 17.00 profile.json.gz

New profile capture attached.

Comment 10

[Mike Kaply [:mkaply]]

I understand this is worked around in 69, but any ideas why this user is running into the problem at all?

Comment 11

[Timothy Nikkel (:tnikkel)]

(In reply to Mike Kaply [:mkaply] from comment #10)

I understand this is worked around in 69, but any ideas why this user is running into the problem at all?

I'm not sure, the stacks in the profile go deep, deep into some Windows code, including things with the name "ModalLoop". This is exactly the kind of thing we wanted to avoid by moving this off the main thread.

Comment 12

[:Gijs (he/him)]

There are also a bunch of dll-loaded-main-thread notifications, which is a bit odd. I don't see why opening prefs would load additional dlls. It's possible some extra piece of software on the machine is interfering in a way that's making itself felt here...

Anyway - let's make sure bug 1530190 helped here - Reporter, if you try with a more recent version of Firefox (like current release, 70.0) on the same machine (install/unzip on a different path and you should get a different profile - or use the profile manager https://support.mozilla.org/kb/profile-manager-create-and-remove-firefox-profiles ), is the problem gone?

:tnikkel, I assume backporting the changes to moz-icon to 68 is... tricky?

Comment 13

[Timothy Nikkel (:tnikkel)]

(In reply to :Gijs (he/him) from comment #12)

There are also a bunch of dll-loaded-main-thread notifications, which is a bit odd. I don't see why opening prefs would load additional dlls. It's possible some extra piece of software on the machine is interfering in a way that's making itself felt here...

I don't remember the specifics, but that api call can basically spin the event loop and do anything.

(In reply to :Gijs (he/him) from comment #12)

:tnikkel, I assume backporting the changes to moz-icon to 68 is... tricky?

The backport (including all of the followups) should be easy, I don't think the code has been touched except for this fix and followups. I'm more comfortable uplifting it now that it has been shipping to users on release for months.

Comment 14

[Stephen]

So what is my next step(s)? I'm in the process of testing 68.x ESR for an enterprise rollout using GPO (instead of CCK2). Are you saying this could be fixed in a future 68.x patch? I would hate to wait for the next major ESR release just to resolve this.

Comment 15

[:Gijs (he/him)]

(In reply to Stephen from comment #14)

So what is my next step(s)? I'm in the process of testing 68.x ESR for an enterprise rollout using GPO (instead of CCK2). Are you saying this could be fixed in a future 68.x patch? I would hate to wait for the next major ESR release just to resolve this.

Maybe. It'd be helpful if you tested current release (see comment #12) to verify that the patch we think fixes this actually fixes this. It's no good to any of us if we include it in a 68 dot-release and it doesn't fix your problem...

Comment 16

[Stephen]

I just tested current release on the same Win7 device. I'm happy to report the issue is now gone.

Comment 17

[Florian Quèze [:florian]]

(In reply to Timothy Nikkel (:tnikkel) from comment #8)

Bug 1530190 should have made these calls off main thread and async, it landed in 69, so it's not in esr 68.

Ah, this nicely explains why I couldn't find related hangs in the BHR data for current nightlies! :-)

Comment 18

[Timothy Nikkel (:tnikkel)]

Requested esr68 approval in bug 1530190.

Comment 19

[:Gijs (he/him)]

This is waiting on bug 1530190. Really it ought to be P1 but then it needs an assignee and nobody is actually working on this. I don't want to dupe it over because it'll be helpful to verify this if/when this lands on esr68. So marking P3, even though that's not really the right answer, to get this out of the triage backlog.

Comment 20

[Stephen]

I can confirm that 68.3.0 ESR has resolved this issue. Thanks again!

Comment 21

[:Gijs (he/him)]

(In reply to Stephen from comment #20)

I can confirm that 68.3.0 ESR has resolved this issue. Thanks again!

Sweet, thanks for confirming!