Open Bug 750979 Opened 12 years ago Updated 2 years ago

Offer profile reset option upon re-installation of the same application version

Categories

(Toolkit :: General, defect)

Product:
Toolkit
Component:
General
Type:
defect
Points:
13

Tracking

()

People

(Reporter: MattN, Unassigned)

References

(Blocks 1 open bug,
URL
)

Details

Attachments

(1 file)

infobar3.jpg
72.77 KB, image/jpeg
Details 
Use case from [1]:
"A user determines that "something" is wrong with Firefox, so they attempt to fix it by reinstalling. When the installer detects that the same version of Firefox already exists on the computer it will offer the option to repair Firefox by resetting it to its default state. That intent can be passed on to Firefox and the reset process will be started the next time Firefox starts."

The reset process can be initiated by launching Firefox with the following command-line arguments after re-installation: 
  -reset-profile -migration

[1] https://wiki.mozilla.org/Support/Firefox_Features/Clean_up_user_profile#2._Users_.26_use_cases
Seems like Firefox could have a menu item where Firefox could relaunch itself with those command line arguments. Firefox could also keep track of installation date (perhaps the date / time stamp for a file that isn't updated by app update) to see if it is a re-install. Then it would be available to all platforms.
(In reply to Robert Strong [:rstrong] (do not email) from comment #1)
> Seems like Firefox could have a menu item where Firefox could relaunch
> itself with those command line arguments.

This was implemented in bug 717070 as a button on about:support. See the feature page [1] in comment 0 for the three ways to initiate the profile reset feature.

> Firefox could also keep track of
> installation date (perhaps the date / time stamp for a file that isn't
> updated by app update) to see if it is a re-install. Then it would be
> available to all platforms.

I suppose it's possible to implement it this way and then show an infobar when this is detected or something like that.  Besides the fact that the installer is Windows-only, is something like the screenshot in the URL field feasible with NSIS?
It is feasible to add checkboxes for this option but we are going to implement a single click installer where the vast majority of UI space is already taken up by branding / marketing on the only page where this can be implemented.
We want an option in the Windows installer specifically because this is a very common repair process on Windows. We see countless users on SUMO (and twitter, facebook, etc.) who try to repair Firefox by reinstalling it.
If you want that in the installer someone on the UX Team will need to figure out where it can be placed so cc'ing limi. See bug 651965 for mockups and please update the mockups in the bug once the placement is figured out.
It is important to note that this likely does happen with other OS's and it is at least somewhat masked by the fact that there is around 1 non Windows user for every 9 Windows users.
(In reply to Robert Strong [:rstrong] (do not email) from comment #5)
> If you want that in the installer someone on the UX Team will need to figure
> out where it can be placed so cc'ing limi. See bug 651965 for mockups and
> please update the mockups in the bug once the placement is figured out.

I hope we don't have to block this on a new installer design. We'd help a lot more people if get this in Firefox 15 and then include it in any future installer designs.

(In reply to Robert Strong [:rstrong] (do not email) from comment #6)
> It is important to note that this likely does happen with other OS's and it
> is at least somewhat masked by the fact that there is around 1 non Windows
> user for every 9 Windows users.

Sorry, I just meant that the option is available in the installer. Then that intent is passed on to Firefox like we'd discussed last year. I believe based on this comment: https://wiki.mozilla.org/Talk:Support/Firefox_Features/Clean_up_user_profile#The_installer_is_not_a_good_option
It will have to be incorporated into the new installer so at the very least it should be blocked on having a design that incorporates it. The good news is that the new installer work has been bumped up in priority and this work can be done at the same time instead of resources being allocated to other work that is a high priority.
In case it isn't clear from my comment on the wiki (last bullet item), this would be Windows only since we only have a Windows installer. To get it cross platform it would need to be a utility application other platforms don't have an installer. Also note that (as I also wrote on the wiki in the last bullet item) this would not handle the case where the installer is running as the user that is trying to do the repair (first bullet item).
What is the status of this bug? As I presented this morning during the Monday all hands, Firefox 18 is the most visited browser downloading Firefox 18. The switch from 17 to 18 happened as soon as 18 was throttled up. 

We are probably going to do some communications from a website/snippet perspective about the reset function, but don't want to have coincide with any product changes.
It is a lower priority when compared to all of the other priority 1 bugs (e.g. metro, stub installer, app update work).
(In reply to Robert Strong [:rstrong] (do not email) from comment #11)
> It is a lower priority when compared to all of the other priority 1 bugs
> (e.g. metro, stub installer, app update work).

10-4. We will move forward with some end-user communications to see if it has an impact. Thanks
(In reply to Chris More [:cmore] from comment #12)
> 10-4. We will move forward with some end-user communications to see if it
> has an impact. Thanks

It would be nice if we could find out what percent of the people you found re-downloading the latest Firefox were trying to fix it by reinstalling. Is it possible to add that to future measurements of the download flow ( http://mzl.la/XH8ybV )?
(In reply to Verdi [:verdi] from comment #13)
> (In reply to Chris More [:cmore] from comment #12)
> > 10-4. We will move forward with some end-user communications to see if it
> > has an impact. Thanks
> 
> It would be nice if we could find out what percent of the people you found
> re-downloading the latest Firefox were trying to fix it by reinstalling. Is
> it possible to add that to future measurements of the download flow (
> http://mzl.la/XH8ybV )?

Do you have any ideas on how to tell if a download+install of Firefox is a purposeful pave-over or someone thinking this is how you manually update?

I am hoping that once we get bug 829173 resolved, I will monitor the Firefox latest downloading Firefox latest trend over time to see if it changes. If users have the "YOU'RE UP TO DATE!!" right in their face and still download a fresh copy, it seems more likely that they are trying to reinstall thinking that will help performance.

If we do an about:home snippet about resetting Firefox and this has an impact of the Firefox latest downloading Firefox latest, then maybe it is a purposeful reinstall.

Stay tuned!
(In reply to Chris More [:cmore] from comment #10)
> What is the status of this bug?

It seems like we should proceed with the cross-platform Firefox detection from comment 1.  The next steps would be to identify the file(s) that should have their timestamp checked and to decide on UI to show the user.  A notification bar similar to the slow startup one may work (see bug 836010 attachment 709088 [details])?
URL: http://people.mozilla.org/~mverdi/scr... → https://wiki.mozilla.org/Features/Des...
Component: Installer → General
Product: Firefox → Toolkit
Summary: Add profile reset option to installer on re-install (installation of same version) → Offer profile reset option upon re-installation of the same application version
Version: Trunk → unspecified
Blocks: reset-firefox
No longer depends on: 273874
Keywords: student-project
Whiteboard: [mentor=MattN][lang=js][lang=xul]
Would comparing the saved timestamp of the XREExeF file work? If the file was modified since the last check, we would then check if the buildid had changed.  If the buildid was the same, then assume a re-install happened. In order for this to work we need to be guaranteed that the executable's modification time is changed upon re-installation of the same version. Is there a file better than XREExeF?

This doesn't seem like it will work on OS X since creation and modification time attributes are also copied with the .app bundle.  For OS X, could we check for the existence of updates.xml and if it doesn't exist but we have write permission to the directory then check that the buildid is the same? Will this approach work on all desktop platforms?
Flags: needinfo?(robert.bugzilla)
Keywords: uiwanted
Is a notification bar the right UI for this? 

It's possible a re-install did fix the user's problem (in the case of a frankenbuild) and it could be that they thought they were updating to a new version and aren't actually having problems. I'm not sure how to word this so we don't imply there is a problem when that's not the case. How about:

==
Looking to freshen up Firefox? A reset can easily fix most problems. Learn more.
                                                                  [Reset Firefox…] (x)
==

"Learn more" would link to https://support.mozilla.org/kb/reset-firefox-easily-fix-most-problems
Flags: needinfo?(ux-review)
I actually think this is one of the few cases where a modal dialog box is probably the most effective.

How about this for the dialog text? (Run it by Matej for wording, should probably be more friendly, but here's a suggestion for general direction):

  You just reinstalled Firefox. If you're trying to fix a problem, we recommend 
  resetting to get Firefox to be as good as new.

  [Reset Firefox] [Don't do anything]
Flags: needinfo?(ux-review)
(In reply to Matthew N. [:MattN] from comment #16)
> Would comparing the saved timestamp of the XREExeF file work? If the file
> was modified since the last check, we would then check if the buildid had
> changed.  If the buildid was the same, then assume a re-install happened. In
> order for this to work we need to be guaranteed that the executable's
> modification time is changed upon re-installation of the same version. Is
> there a file better than XREExeF?
I think the only way to be sure is to check these platforms as well as different file systems. For Windows, the install.log file might be a better candidate.

> This doesn't seem like it will work on OS X since creation and modification
> time attributes are also copied with the .app bundle.  For OS X, could we
> check for the existence of updates.xml and if it doesn't exist but we have
> write permission to the directory then check that the buildid is the same?
Likely not since it won't be created until sometime later where later is indeterminate.
I'll ask smichaud if he knows of something that can be keyed off of.

> Will this approach work on all desktop platforms?
Too soon to know.
Flags: needinfo?(robert.bugzilla)
Steven, do you know of a reliable way to detect if an application has been re-installed? This bug needs to be able to check if a new bundle has been installed (not sure about this part) and if it is the same version (this part is simple).
Flags: needinfo?(smichaud)
Hmm, we should probably be wary of things that could trigger false-positives. For example, if you restore Firefox with crappy backup software (that updates the timestamp), or an admin changes your network-mounted apps dir to something with a newer timestamp... Maybe not the greatest examples, but if a user gets a "so you reinstalled, reset?" dialog in such cases, it'll be _really_ confusing.

OS X and Linux seem especially difficult, since there's either no "install" process or it's something we don't have obvious visibility into (packages). Might be worth considering if we should go with a Windows-only solution.
> Steven, do you know of a reliable way to detect if an application
> has been re-installed?

I can't think of any generic way to do this (one that would for all
apps on OS X).  But I'm not sure I understand the question.

When would the check be made?  As the application is being
(potentially) reinstalled?  After it gets (re)installed?

Which program would be checking?  The (presumed) new installer for OS
X (there isn't one now, of course)?  Firefox itself?

Which app are we checking?  Firefox itself?

Once I know the answers to these questions, I may be able to find some
way to query Launch Services for the information.
Flags: needinfo?(smichaud)
(In reply to Justin Dolske [:Dolske] from comment #21)
> Hmm, we should probably be wary of things that could trigger
> false-positives. For example, if you restore Firefox with crappy backup
> software (that updates the timestamp), or an admin changes your
> network-mounted apps dir to something with a newer timestamp... Maybe not
> the greatest examples, but if a user gets a "so you reinstalled, reset?"
> dialog in such cases, it'll be _really_ confusing.
> 
> OS X and Linux seem especially difficult, since there's either no "install"
> process or it's something we don't have obvious visibility into (packages).
> Might be worth considering if we should go with a Windows-only solution.
Perhaps though finding out whether there are reliable ways to determine if a reinstall has occurred.
(In reply to Steven Michaud from comment #22)
> > Steven, do you know of a reliable way to detect if an application
> > has been re-installed?
> 
> I can't think of any generic way to do this (one that would for all
> apps on OS X).  But I'm not sure I understand the question.
> 
> When would the check be made?  As the application is being
> (potentially) reinstalled?  After it gets (re)installed?
After

> Which program would be checking?  The (presumed) new installer for OS
> X (there isn't one now, of course)?  Firefox itself?
By Firefox itself

> Which app are we checking?  Firefox itself?
Firefox itself and specifically the same installation.
Thanks, Robert.

Can the answer to your question wait for a bit (like a few weeks)?

It's likely Firefox can't reliably detect whether or not it's been reinstalled on OS X.  But I can't tell for sure until I've spent at least a day on this problem.
Yes, the other work you are doing is a higher priority.
Blocks: fxdesktopbacklog
Whiteboard: [mentor=MattN][lang=js][lang=xul] → [mentor=MattN][lang=js][lang=xul] p=0
Flags: firefox-backlog+
Keywords: student-project, uiwanted
Whiteboard: [mentor=MattN][lang=js][lang=xul] p=0 → p=13 [Eng. decision on the approach is needed before UX design]
Reminder about comment 25 so we know if we can proceed with the installer approach or checking the existence or timestamp of update files instead.
Flags: needinfo?(smichaud)
Let me see if I can find time for this next week.
Flags: needinfo?(smichaud)
Restore needinfo to remind me.
Flags: needinfo?(smichaud)
So, you should be able to check the timestamp of defaults/pref/channel-prefs.js since it is not updated by app update. I verified that installing on top of an existing install on Mac OS X will update the timestamp.
(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #30)
Robert, are you fine with using that approach on all platforms (assuming it works everywhere)?
I am and I can't think of any reason not to use this approach off the top of my head. There will be likely be around the same amount of false positives with any approach taken whether it is in app or in the installer.
OK, thanks.
Whiteboard: p=13 [Eng. decision on the approach is needed before UX design] → p=13
No longer blocks: fxdesktopbacklog
Michael, what kind of UI have you been thinking of for this?
Flags: needinfo?(mverdi)
Attached image infobar3.jpg — 
(In reply to Philipp Sackl [:phlsa] from comment #34)
> Michael, what kind of UI have you been thinking of for this?

I think an infobar similar to what we show when you start Firefox after not using it for 60 days will work. More context here http://people.mozilla.org/~mverdi/mockups/reset/reset2014v2.pdf
Flags: needinfo?(mverdi)
Looks like we can go ahead with the cross-platform file timestamp plus version checking approach.
Points: --- → 13
QA Whiteboard: [qa+]
Flags: needinfo?(smichaud)
Whiteboard: p=13
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: