Last Comment Bug 750979 - Offer profile reset option upon re-installation of the same application version
: Offer profile reset option upon re-installation of the same application version
Status: NEW
:
Product: Toolkit
Classification: Components
Component: General (show other bugs)
: unspecified
: All All
: -- normal with 4 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
:
Mentors:
https://wiki.mozilla.org/Features/Des...
Depends on:
Blocks: reset-firefox
  Show dependency treegraph
 
Reported: 2012-05-01 18:09 PDT by Matthew N. [:MattN] (In Taipei until Sep. 23)
Modified: 2015-11-06 06:26 PST (History)
23 users (show)
MattN+bmo: firefox‑backlog+
See Also:
Crash Signature:
(edit)
QA Whiteboard: [qa+]
Iteration: ---
Points: 13
Has Regression Range: ---
Has STR: ---


Attachments
infobar3.jpg (72.77 KB, image/jpeg)
2014-06-17 14:10 PDT, Verdi [:verdi]
no flags Details

Description Matthew N. [:MattN] (In Taipei until Sep. 23) 2012-05-01 18:09:25 PDT
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
Comment 1 Robert Strong [:rstrong] (use needinfo to contact me) 2012-05-01 18:20:15 PDT
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.
Comment 2 Matthew N. [:MattN] (In Taipei until Sep. 23) 2012-05-01 18:26:28 PDT
(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?
Comment 3 Robert Strong [:rstrong] (use needinfo to contact me) 2012-05-01 18:32:59 PDT
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.
Comment 4 Verdi [:verdi] 2012-05-01 20:10:32 PDT
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.
Comment 5 Robert Strong [:rstrong] (use needinfo to contact me) 2012-05-01 20:14:32 PDT
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.
Comment 6 Robert Strong [:rstrong] (use needinfo to contact me) 2012-05-01 20:16:52 PDT
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.
Comment 7 Verdi [:verdi] 2012-05-01 20:29:21 PDT
(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
Comment 8 Robert Strong [:rstrong] (use needinfo to contact me) 2012-05-01 20:37:44 PDT
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.
Comment 9 Robert Strong [:rstrong] (use needinfo to contact me) 2012-05-01 20:44:54 PDT
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).
Comment 10 Chris More [:cmore] 2013-02-04 15:41:07 PST
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.
Comment 11 Robert Strong [:rstrong] (use needinfo to contact me) 2013-02-04 15:45:20 PST
It is a lower priority when compared to all of the other priority 1 bugs (e.g. metro, stub installer, app update work).
Comment 12 Chris More [:cmore] 2013-02-04 15:50:39 PST
(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
Comment 13 Verdi [:verdi] 2013-02-04 17:27:57 PST
(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 )?
Comment 14 Chris More [:cmore] 2013-02-04 22:09:05 PST
(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!
Comment 15 Matthew N. [:MattN] (In Taipei until Sep. 23) 2013-03-13 15:58:24 PDT
(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])?
Comment 16 Matthew N. [:MattN] (In Taipei until Sep. 23) 2013-03-14 20:13:50 PDT
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?
Comment 17 Matthew N. [:MattN] (In Taipei until Sep. 23) 2013-03-14 20:30:29 PDT
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
Comment 18 Alex Limi (:limi) — Firefox UX Team 2013-03-15 17:31:04 PDT
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]
Comment 19 Robert Strong [:rstrong] (use needinfo to contact me) 2013-04-10 23:04:42 PDT
(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.
Comment 20 Robert Strong [:rstrong] (use needinfo to contact me) 2013-04-10 23:07:04 PDT
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).
Comment 21 Justin Dolske [:Dolske] 2013-04-11 01:31:17 PDT
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.
Comment 22 Steven Michaud [:smichaud] (Retired) 2013-04-11 08:29:42 PDT
> 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.
Comment 23 Robert Strong [:rstrong] (use needinfo to contact me) 2013-04-11 08:34:48 PDT
(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.
Comment 24 Robert Strong [:rstrong] (use needinfo to contact me) 2013-04-11 11:02:10 PDT
(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.
Comment 25 Steven Michaud [:smichaud] (Retired) 2013-04-11 11:38:34 PDT
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.
Comment 26 Robert Strong [:rstrong] (use needinfo to contact me) 2013-04-11 11:39:53 PDT
Yes, the other work you are doing is a higher priority.
Comment 27 Matthew N. [:MattN] (In Taipei until Sep. 23) 2014-05-29 15:27:29 PDT
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.
Comment 28 Steven Michaud [:smichaud] (Retired) 2014-05-29 15:40:23 PDT
Let me see if I can find time for this next week.
Comment 29 Steven Michaud [:smichaud] (Retired) 2014-05-29 15:41:12 PDT
Restore needinfo to remind me.
Comment 30 Robert Strong [:rstrong] (use needinfo to contact me) 2014-05-29 15:55:15 PDT
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.
Comment 31 Matthew N. [:MattN] (In Taipei until Sep. 23) 2014-05-29 17:04:25 PDT
(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)?
Comment 32 Robert Strong [:rstrong] (use needinfo to contact me) 2014-05-29 18:08:17 PDT
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.
Comment 33 Matthew N. [:MattN] (In Taipei until Sep. 23) 2014-05-29 18:36:00 PDT
OK, thanks.
Comment 34 Philipp Sackl [:phlsa] (Firefox UX) please use needinfo 2014-06-03 02:21:25 PDT
Michael, what kind of UI have you been thinking of for this?
Comment 35 Verdi [:verdi] 2014-06-17 14:10:32 PDT
Created attachment 8441662 [details]
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
Comment 36 Matthew N. [:MattN] (In Taipei until Sep. 23) 2014-08-12 13:54:23 PDT
Looks like we can go ahead with the cross-platform file timestamp plus version checking approach.

Note You need to log in before you can comment on or make changes to this bug.