1633505 - Show refresh button within the uninstaller

Status: RESOLVED FIXED

(Firefox :: Installer, enhancement, P1)

Description

[Rachel Tublitz [:rachel]]

This work is being prioritized in order to help users who are trying to fix a problem with Firefox resolve issues. We see that a lot of users uninstall and then re-install Firefox (which does not actually do a refresh). Making it easier to fix corrupt profiles is something we'd like to include within the uninstaller.

This will cover adding a refresh button to the first screen of the uninstaller, as well as some minor text changes throughout.

Comment 1

[Adam Gashlin (he/him) [:agashlin] (ex-moco)]

Attachment: Bug 1633505 - Show refresh button within the uninstaller. r?mhowell

Detect a profile for the installation, if found offer refresh on welcome page:

• Replace text
• Add help link and button
• Use Uninstall button text on the Next button

Add a different prompt to close the browser for refresh.

When leaving the welcome page:

• via help link, launch a URL
• via Refresh button, launch Firefox with the necessary args

Add utility functions to launch the link and Firefox.

Remove the UN_CONFIRM_CLICK label and cleared UN_CONFIRM_PAGE_TITLE,
this was an auxiliary to the design.

Move the check for the install-specific profile to common.nsh from stub.nsi,
it should be identical, just wrapped in stack ops to save regs.

Move InitHashAppModelId to just after un.UninstallUnOnInitCommon (which sets
$INSTDIR correctly), so AUMID would be available in un.PreWelcome. I don't
think there's anything else that would change $INSTDIR in the uninstaller
so this should be ok.

Unrelated but adjacent cleanup: Remove inappropriate use of _MOZFUNC_UN
in CopyPostSigningData.

Comment 2

[Adam Gashlin (he/him) [:agashlin] (ex-moco)]

Attachment: uninstall refresh.png

From left to right: Screenshots of the new welcome page, a slightly modified confirm page (removed subtitle and click Uninstall to proceed msg), and the welcome page with 3x longer English text as an estimate for localized versions.

I'm still waiting to hear whether we are going to replace the watermark with a white background version.

The 3X rule of thumb may be a little excessive here, but I'd rather not move the button and link up just a few lines, as I think they look better close to the bottom than hanging out in the middle of the page.

Comment 3

[Adam Gashlin (he/him) [:agashlin] (ex-moco)]

Attachment: uninstall refresh 2.png

Top row is as before, from left: Welcome page, confirm page, welcome page with 3x simulating localization expansion.

Bottom row is simulated RTL, the layout is accurate but the punctuation seems scrambled as en-US isn't truly RTL.

Comment 4

[Meridel [:meridel]]

Thanks, Adam! This is looking good.

Ideally, the 'Learn more' link would follow closely after the body copy, rather than stack on top of the Refresh button. I assume we had to do it this way because of build or l10n needs?

Comment 5

[Adam Gashlin (he/him) [:agashlin] (ex-moco)]

(In reply to Meridel from comment #4)

Ideally, the 'Learn more' link would follow closely after the body copy, rather than stack on top of the Refresh button. I assume we had to do it this way because of build or l10n needs?

It's both l10n and general uncertainty around text rendering. The link and the body have to be different controls (unless using SysLink, see below, or something even more powerful), so we're responsible for placing and sizing them so they don't overlap or get clipped. It's impractical to determine the size needed for the text precisely enough to use for layout, so generally we give much more space than needed.

It's possible to use DrawText's DT_CALCRECT to get the height of text given a font and width, but that's only if using DrawText. There is a complex relationship between this and the size of text in a dialog label. I think this mostly revolves around padding, but I never was able to get to the bottom of it, it can vary in different Windows versions, themes, and resolutions. We used this for sizing with the earlier stub installer, but we really could only use it with a large margin of error, more to ensure that we didn't cut off any locales than to lay things out nicely. The web stub (bug 1596812) was implemented in part to get out of this situation. It would have been very difficult to take over the rendering ourselves to directly use DrawText, especially given the toolkit we're using in the uninstaller ("Modern UI", which uses InstallOptions).

There is a SysLink control that enables using anchor tags to intersperse links with text, but there isn't support for it in InstallOptions. Managing it ourselves, in particular properly dealing with the events, would have been a large task in itself.

Comment 6

[Jacqueline Savory [:jsavory] UX]

This looks great Adam, thanks for getting that title centered!
I don't see anything else we need to change for this round, looking forward to doing a bigger refresh in the future :)

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/c7f88fdf7837
Show refresh button within the uninstaller. r=mhowell

Comment 8

[Bogdan Tara[:bogdan_tara | bogdant]]

https://hg.mozilla.org/mozilla-central/rev/c7f88fdf7837

Comment 10

[Julien Cristau [:jcristau]]

Do we want to mention this in the 78 release notes?

(see this doc for the nomination process)

Comment 11

[Rachel Tublitz [:rachel]]

(In reply to Julien Cristau [:jcristau] from comment #10)

Do we want to mention this in the 78 release notes?

(see this doc for the nomination process)

Yes. This is a change that it would be useful for other users to know about as well in case they are trying to resolve issues and have never heard about refreshing Firefox in order to do so.

Comment 12

[Rachel Tublitz [:rachel]]

Release Note Request (optional, but appreciated)
[Why is this notable]:
See comment 11
[Affects Firefox for Android]:
No
[Suggested wording]:
I'd suggest that we also link to https://support.mozilla.org/kb/refresh-firefox-reset-add-ons-and-settings in case users come across this in the release notes and want to learn more about how this works, or how to do it.
[Links (documentation, blog post, etc)]:
PRD is linked at the top of this bug

Comment 13

[Julien Cristau [:jcristau]]

Thanks, added "On Windows, the Firefox uninstaller has a new option to refresh your profile" to the draft relnotes.

Comment 14

[Adam Gashlin (he/him) [:agashlin] (ex-moco)]

For testing with longer text before all localizations are complete, here are modified full installers (based on mozilla-beta):

• en-US (try task)
• ar (try task) (for checking RTL, the new text is still in English)

Hebrew translations are complete, you can see proper RTL in the Hebrew Beta installer.

Comment 15

[Michael Droettboom [:mdroettboom]]

Apologies for the drive by question from the data org here -- I might be retreading ground already discussed elsewhere. I got here from researching detecting reinstalls wrt retention analysis.

There are obviously some implications with respect to how this will affect our retention metrics. Currently, we can track users across reinstalls since their client id remains the same. Removing the profile would reset their client id and look like churn instead. At a minimum, it would be good to collect telemetry on profile resets (if we don't already) so that we don't erroneously count it as churn. (The alternative of connecting client ids across profile resets is probably less desirable since we can't assume the user is resetting only to fix an issue -- they may be trying to reset their profile data).

Comment 16

[Adam Gashlin (he/him) [:agashlin] (ex-moco)]

I believe the client ID and some other telemetry info is preserved through the refresh migration, this is the same mechanism as with an in-browser "Refresh Firefox" (though it doesn't offer to restore tabs). The data is migrated starting here. It looks like you might get a new "first-shutdown" ping after this. The client ID shows up as null in about:telemetry on the run when it was refreshed, but it gets submitted correctly.

There is a scalar migration.uninstaller_profile_refresh (bug 1634115) specifically for the uninstaller route, and all refreshes are tracked by histogram FX_MIGRATION_ENTRY_POINT = 2.