Closed Bug 1593137 Opened 2 years ago Closed 2 years ago

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

Categories

(Firefox :: Preferences, defect, P3)

68 Branch
defect

Tracking

()

VERIFIED FIXED
Tracking Status
firefox-esr68 --- verified
firefox70 --- unaffected
firefox71 --- unaffected
firefox72 --- unaffected

People

(Reporter: mkaply, Assigned: tnikkel)

References

Details

Attachments

(2 files)

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.

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?

Flags: needinfo?(mozilla)
Whiteboard: [fxperf]

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

Depends on: 622840
Summary: Preferences taking 60 seconds to open for a particular user → Preferences taking 60 seconds to open for a particular user (due to (many?) slow/mainthread moz-icon loads)

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

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!

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.

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.

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

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

New profile capture attached.

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

Flags: needinfo?(mozilla)

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

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?

Flags: needinfo?(zeeter)
Flags: needinfo?(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.

Flags: needinfo?(tnikkel)

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.

Flags: needinfo?(zeeter)

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

Flags: needinfo?(zeeter)

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

Flags: needinfo?(zeeter)

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

Requested esr68 approval in bug 1530190.

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.

Depends on: 1530190
No longer depends on: 622840
Whiteboard: [fxperf]

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

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

Assignee: nobody → tnikkel
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.