Update progress bar does not appear - macOS, Nightly
Categories
(Toolkit :: Application Update, defect, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox77 | --- | affected |
People
(Reporter: rachel, Unassigned)
References
(Regression)
Details
(Keywords: regression, Whiteboard: [iu_tracking])
Attachments
(1 file)
|
2.15 KB,
text/plain
|
Details |
It looks like we should be showing an 'update in progress' indicator...which does not seem to appear on macOS.
Assuming it's more widespread than just a quirk of my machine, this would be worthwhile to fix; it makes the app appear to be incredibly slow on startup. As a user, I would be more understanding of this if I know we're updating...but since I have no visual feedback here, it just makes things feel slow.
I'll ni? myself here to provide detailed update logs here in case it's helpful.
| Reporter | ||
Updated•6 years ago
|
| Reporter | ||
Updated•6 years ago
|
Comment 1•6 years ago
|
||
It is only shown after an interval has passed per UX team.
https://searchfox.org/mozilla-central/source/toolkit/mozapps/update/updater/progressui_osx.mm#99
| Reporter | ||
Comment 2•6 years ago
|
||
| Reporter | ||
Comment 3•6 years ago
•
|
||
Aha! Thank you Rob. I will connect with UX team on this then. I will try to more accurately time what I'm seeing as I've noted delays of ~seconds which looks like it's out of bounds with what that logic is targeting.
Comment 4•6 years ago
|
||
The priority flag is not set for this bug.
:agashlin, could you have a look please?
For more information, please visit auto_nag documentation.
Comment 5•6 years ago
|
||
I thought I had typed this up somewhere but I guess not here:
I think this is because we decide not the show the UI on a staged update or replace request if elevation isn't required, which seems to be the case from this log ("gCanStageUpdatesSession - able to stage updates" and "getElevationRequired - able to write to application bundle, elevation not required").
It makes sense to not show the UI on the staging phase, since the user isn't really waiting for anything, but I'm less sure it should apply on the replace phase. I guess the assumption was that the replacement would be fast enough it wouldn't be required, which seems reasonable. I'm wondering why you're seeing these long pauses, since the replacement should just be renaming a folder and deleting the old files. Maybe there is something else slowing down Firefox startup?
As an aside, the UI does get shown if elevation is required, and I'm not sure what would keep it from showing during staging here?
Updated•6 years ago
|
Description
•