There are probably a lot of users out there who, for various reasons, have since moved from Firefox to another browser. When those users return to Firefox to try out a new release, the Firefox profile is no longer up to date with their contemporary browsing data. Returning the user to that old profile data doesn't make good sense. Also, if the user abandoned Firefox because of some profile instability issue from add-ons or other profile hackery, then returning them to that old profile doesn't make good sense. I believe that Firefox should check at launch and if the profile it's about to use hasn't been touched in more than one month (two?), we should prompt the user with some kind of a "Would you like to reset Firefox to "factory defaults" and/or re-migrate your IE/Chrome/Safari data?" option. If the profile is really really old, I think we should just do this automatically. If doing things automatically is rejected, then I think we should add a button in the advanced prefs that resets Firefox and re-migrates user data from other browsers. Abandoned Firefox profiles are either out dated or broken or both. We should so something to give the user a better returning to Firefox experience.

Can someone help get this onto the priority list (if it's agreed this should be a Firefox feature) I think it's pretty important as we try to re-gain some lost users.

Prompting to migrate again if the profile hasn't been used in a long time is a good idea. Determining the last-use may be slightly involved, but it's doable. Perhaps some kind of "welcome back" dialog could offer to re-import data and also disable addons? I think "automatic reset" is a bit too harsh - I don't think it's true that old profiles are often broken, or that old profile data often cause actual issues. Deleting (or prompting users to delete) old data seems dangerous (or at least annoying). User-triggered "Reset Firefox" functionality sounds like a good idea, but that should probably get its own bug.

I think this is an interesting idea, but allow me to point out a counter example. I have a notebook computer that I use probably twice a year. If this feature were to make it into Firefox, every time I use that notebook, it would ask me if I want to re-migrate, which would be extremely annoying. In my case, it wouldn't do any good to re-migrate the profile, since the other browsers on that computer have gone unused just as long or longer. As another example, I usually have two or three Firefox profiles on development machines, to keep my daily browsing separate from development, including history, bookmarks, and most importantly, addons. Often, I can go several months without using my development profile, but still using my main profile every day. I would not enjoy Firefox asking me if I want to re-migrate my development profile just because I haven't done any web coding in a while. Finally, I would wonder how this would work with Firefox sync. In my first example, if the age of my sync data were taken into account, I wouldn't be asked to re-migrate because I use the same sync profile on that low-use notebook as on my everyday workstation. If it asked me to re-migrate before syncing, what would happen to my sync data? Would it get wiped on that machine, forcing me to set sync back up? If not, would it be automatically merged?

Implementation notes: To know when the user last used the profile, we can check nsIXULRuntime::replacedLockTime. If it is non-zero and greater than the threshold we determine, provide UI to reset or migrate. I think automatically performing these actions can be handled in a follow-up bug if the need arises. UI needs to be designed but can possibly build upon bug 750979 which will only offer a reset. How about a notification bar like so: Welcome back! We can help you with some spring cleaning [Reset Firefox…] [Import from another browser…](x) Perhaps we should also open some sort of firstrun tab (startup.homepage_welcome_url) to let the user know about recent improvements in Firefox?

(In reply to :Gavin Sharp (use gavin@gavinsharp.com for email) from comment #2) > I don't think it's true that old profiles are often broken, or that old > profile data often cause actual issues. You would be surprised. Speaking with my old colleagues who had moved from Firefox to Chrome it came across strongly that they have tried to go back to Firefox a bunch of times but it was "too slow and unstable." It turns out that they are all techies but had no idea that they had a profile and certainly no idea how to reset it (a bad addon or settings must have caused the slowdown). On resetting their profiles they were very surprised about the improvements in speed and stability. This really is quite a barrier to people switching back to Firefox at a small inconvenience to a few. I do think that users should have a say in whether their profile is reset though.

Just an idea: How about giving people the choice afterwards? We automatically reset the profile and show a bar on top with the first start after a while. Saying something like: "We reset your profile for your convenience. If you'd rather go back, click here" People are going with defaults, and for the vast majority this will be a much better option than using their old profile. Firefox reset is migrating bookmarks, passwords, history, cookies etc.

Firefox Health Report maintains a history of recent sessions. If you need something more robust than the single last session time, it could serve your needs.

(In reply to Matthew N. [:MattN] from comment #5) > UI needs to be designed but can possibly build upon bug 750979 which will > only offer a reset. How about a notification bar like so: > > Welcome back! We can help you with some spring cleaning > [Reset Firefox…] [Import from another > browser…](x) As suggested in bug 750979 comment 18, I think it's most effective to use a modal dialog here, since we actually want to stop the user and get in their way. :) Something like this (again, run it by Matej): You haven't started Firefox in a while. Do you want us to clean up the settings to ensure you have a fresh out-of-the-box experience? Oh, and welcome back! :) [Reset Firefox] [Don't do anything]

Thanks Alex!

I also ( comment #3) do not like the idea of a totally automatic reset. In addition to machines not ordinarily used for day to day browsing, any account not often used for browsing suffers the same problem. So a user that does not often use that machine, or maybe the admin account would have Firefox reset.

I hacked this quick prototype together on the plane.

Matej, could you review the string in comment 9?

How about this? It looks like you haven't started Firefox in a while. Do you want to clean up your settings for a fresh, like-new experience? And by the way, welcome back! [Reset Firefox] [Don't do anything]

Just worked on a slight tweak with Matt on irc. Here's the latest: It looks like you haven't started Firefox in a while. Do you want to clean it up for a fresh, like-new experience? And by the way, welcome back!

I know this is getting bikesheddy, but what's the reasoning for the complication of the "and by the way" here? It'd be more simple and natural to just do "Welcome back!" at the beginning.

We can move re-migration in a separate bug as it's complicated to migrate from both Firefox and another browser and non-trivial to get a good UX.

Comment on attachment 769260 [details] [diff] [review] v.1 Reset option only Review of attachment 769260 [details] [diff] [review]: ----------------------------------------------------------------- Looks good! Might be nice for some automated tests for the notification bar, but I wouldn't block on it.

Thanks! Try push: https://tbpl.mozilla.org/?tree=Try&rev=aa80ce3adf47 https://hg.mozilla.org/integration/mozilla-inbound/rev/37015ff213ae

(In reply to Dave Garrett from comment #17) > I know this is getting bikesheddy, but what's the reasoning for the > complication of the "and by the way" here? It'd be more simple and natural > to just do "Welcome back!" at the beginning. I like that it's a bit more casual, but I'm fine either way. It's a bit shorter with "welcome back" at the start, which is good: Welcome back! It looks like you haven't started Firefox in a while. Do you want to clean it up for a fresh, like-new experience?

(In reply to Matej Novak [:matej] from comment #22) > (In reply to Dave Garrett from comment #17) > > I know this is getting bikesheddy, but what's the reasoning for the > > complication of the "and by the way" here? It'd be more simple and natural > > to just do "Welcome back!" at the beginning. > > I like that it's a bit more casual, but I'm fine either way. It's a bit > shorter with "welcome back" at the start, which is good: Jared wondered if some people would stop reading after "Welcome back!" (perhaps thinking that the welcome message was the sole purpose?) so I used the string from comment 16. If you feel strongly that the string should change, please file a follow-up bug.

(In reply to Matthew N. [:MattN] from comment #23) > (In reply to Matej Novak [:matej] from comment #22) > > (In reply to Dave Garrett from comment #17) > > > I know this is getting bikesheddy, but what's the reasoning for the > > > complication of the "and by the way" here? It'd be more simple and natural > > > to just do "Welcome back!" at the beginning. > > > > I like that it's a bit more casual, but I'm fine either way. It's a bit > > shorter with "welcome back" at the start, which is good: > > Jared wondered if some people would stop reading after "Welcome back!" > (perhaps thinking that the welcome message was the sole purpose?) so I used > the string from comment 16. If you feel strongly that the string should > change, please file a follow-up bug. Yes, we were talking about this offline. Basically, the whole point of this message is to push users who might have stopped using Firefox to reset their profile. It's nice to say welcome back while we're talking to them, but we should be careful not to lose readers who may stop early because they think this is just a lengthy welcome back message.

I am so glad we're doing this. It's going to be a big win for our users :) My only question is whether users will understand what "Reset Firefox" means. We say that we're "cleaning up" Firefox, but users might get worried that this is the same as uninstalling Firefox and then re-installing a brand new copy. Correct me if I'm wrong, but we're keeping the user's bookmarks, right? We're just removing add-ons and settings?

(In reply to Larissa Co [:lco] from comment #25) > I am so glad we're doing this. It's going to be a big win for our users :) > > My only question is whether users will understand what "Reset Firefox" > means. We say that we're "cleaning up" Firefox, but users might get worried > that this is the same as uninstalling Firefox and then re-installing a brand > new copy. Correct me if I'm wrong, but we're keeping the user's bookmarks, > right? We're just removing add-ons and settings? http://screencast.com/t/gMXCqUpP2

(In reply to Larissa Co [:lco] from comment #25) > My only question is whether users will understand what "Reset Firefox" > means. Zhenshou and I discussed this with the User Advocacy team. We thought that once the reset was less destructive (like it saved your session https://bugzilla.mozilla.org/show_bug.cgi?id=833943) it would be good to rename this feature to something more appropriate. Madhava and I brainstormed a few name in irc one day. I don't know if there is a bug for making that change yet.

There is bug 872241 and bug 872240 for the help menu. The other strings could be changed at the same time.

Asa brought this up in the feature review meeting to add it to relase note

Jared, can you please describe the feature as implemented in a comment and update the Summary to reflect what we're actually doing here. Also, a screencast of how this looks to a returning user would be really helpful.

Since I wrote the patch, I'll do it.

Is there any way I can simulate the profile not being used for months so that I could verify the fix?

(In reply to Simona B [QA] from comment #32) > Is there any way I can simulate the profile not being used for months so > that I could verify the fix? The patch looks to be using Services.appinfo.replacedLockTime as its time to check, but that doesn't seem to be documented anywhere. Your most reliable option would be to load up a test box or VM, set its clock to 61 days in the past, install Firefox and use the profile a bit, then exit, fix the clock, and reload Firefox to test.

Testing Win, Mac, & Linux would also not be a bad idea, just to make sure replacedLockTime is fetched correctly everywhere. (and someone writing documentation for it on MDN would be nice too) If there's some way to write an automatic test for this that would be great as well, as this is the sort of thing that could break without people noticing.

Adding the feature keyword so that this bug is properly picked up by the Release Tracking wiki page.

Mozilla/5.0 (X11; Linux i686; rv:25.0) Gecko/20100101 Firefox/25.0 Build ID: 20130904004004 Verified as fixed on Firefox 25.0a2 (using the indications provided in Comment 33) on Windows 7, Ubuntu 13.04 and Mac OS X 10.8.4- the reset notification is displayed after opening an abandoned profile (older than 61 days). I did found one situation in which the reset notification is not displayed, and I filed Bug 912576. Also (at least on the Aurora branch) the Reset notification is covered in less than a minute by another notification (Aurora automatically sends some data to Mozilla so that we can improve your experience) making it invisible to the users. Is this something intended by design?

By the way, I said 61 days to make testing simpler. The mark is 60 days to the millisecond but nobody at all cares about that level of precision, though the code will. If you tried to do exactly 60 days but the recorded time and/or time you jump to isn't perfect, then it's plausible you could accidentally be on either side of the mark. (I have no clue how DST could mess things up here but I just assume that it can) Seeing as there is no point to getting this exact, just test a day to either side of the mark. Do 61 days to check that it shows and 59 days to check that it doesn't.

(In reply to Dave Garrett from comment #37) > By the way, I said 61 days to make testing simpler. The mark is 60 days to > the millisecond but nobody at all cares about that level of precision, > though the code will. If you tried to do exactly 60 days but the recorded > time and/or time you jump to isn't perfect, then it's plausible you could > accidentally be on either side of the mark. (I have no clue how DST could > mess things up here but I just assume that it can) Seeing as there is no > point to getting this exact, just test a day to either side of the mark. Do > 61 days to check that it shows and 59 days to check that it doesn't. Mozilla/5.0 (X11; Linux i686; rv:26.0) Gecko/20100101 Firefox/26.0 Build ID:20130904030204 Mozilla/5.0 (X11; Linux i686; rv:25.0) Gecko/20100101 Firefox/25.0 Build ID:20130904004004 Verified also on the latest Nightly and on the latest Aurora on Windows 7, Ubuntu 13.04 and Mac OS X 10.8.4 that: - the Reset Notification is not displayed when the computer clock is set to 59 days in the past. - the Reset Notification is displayed when setting the computer clock to 60 and 61 days in the past. (In reply to Simona B [QA] from comment #36) > Also (at least on the Aurora branch) the Reset notification is covered in > less than a minute by another notification (Aurora automatically sends some > data to Mozilla so that we can improve your experience) making it invisible > to the users. Is this something intended by design? Dave, do you have any thoughts on this? Please let me know if there is anything else you would want me to verify on this.

(In reply to Simona B [QA] from comment #38) > (In reply to Simona B [QA] from comment #36) > > Also (at least on the Aurora branch) the Reset notification is covered in > > less than a minute by another notification (Aurora automatically sends some > > data to Mozilla so that we can improve your experience) making it invisible > > to the users. Is this something intended by design? > > Dave, do you have any thoughts on this? I did not design this, but I think it is safe to assume that this is not wanted. If there's not a separate bug for this issue, I would highly recommend filing one. Both notifications should make it to the user, probably with this one having higher priority. You've probably checked enough to make sure this is verified and could mark this VERIFIED, but I'm not QA for this so I'll leave that to you or the bug owner to decide. Question: This is desktop only and mobile is not affected or intended to be affected, correct? Also, to repeat myself as I'm needinfoing the patch author about the above, this is easily the sort of thing that could break and nobody would notice because it does not affect developers or regular users. If there's some way to write an automated test for this, that would sound good to me.

needinfo for comment 39 (Bugzilla ate it for some reason)

sorry for the bugspam there; it actually won't let me needinfo the assignee. not sure if that's a Bugzilla bug or what

(In reply to Dave Garrett from comment #41) > sorry for the bugspam there; it actually won't let me needinfo the assignee. > not sure if that's a Bugzilla bug or what You can't needinfo the assignee because he already has a needinfo request that was opened in comment #31 and is still open.

(In reply to Asa Dotzler [:asa] from comment #30) > Jared, can you please describe the feature as implemented in a comment and > update the Summary to reflect what we're actually doing here. Also, a > screencast of how this looks to a returning user would be really helpful. See attached. Sorry for the delay, I ended up going on vacation before getting to this. (In reply to Simona B [Away] from comment #36) > Also (at least on the Aurora branch) the Reset notification is covered in > less than a minute by another notification (Aurora automatically sends some > data to Mozilla so that we can improve your experience) making it invisible > to the users. Is this something intended by design? AFAIK that notification is only shown a few startups on Aurora and Nightly (if the user doesn't take action) so I don't think this is a problem worth working around since it's unlikely for real users. The fact that notification bars stack is by design.

FYI, Here is a workaround to disable this feature, this should really be documented somewhere: To disable the message from popping up, update the file modification time on the .parentlock file in the user profile directory. for example, on linux: touch $HOME/.mozilla/firefox/*/.parentlock I really wish this would have been implemented as a variable in prefs.js like all of the other startup checks, and there should really be a way to disable it. I really think it is going to cause more problems than it solves. Simply adding a "reset everything to defaults" option in the menu somewhere would be better in my opinion.

(In reply to bugzilla.mozilla.org from comment #44) > I really think it is going to cause more problems than it solves. Why do you think so? Nothing is done automatically, it's simply a notification bar that's displayed if the profile hasn't been used in over 60 days which seems very non-intrusive. > Simply adding a "reset everything to defaults" option in the menu > somewhere would be better in my opinion. That's bug 872241.

>> I really think it is going to cause more problems than it solves. >Why do you think so? As I understand it this feature is intended to help people who are not "computer experts". They are going to see the "Do you want to clean it up?" message and think "that sounds great!" but then the behavior of the browser is going to potentially change. If they haven't used the browser in a while they are even less likely to remember what key settings they changed to get firefox set up the way they wanted a few months ago. Often times a friend/relative/administrator will get things set up properly, and then a user will see a message like this and BOOM - all the settings are hosed because the user clicked on something that popped up and sounded like a good idea. This is going to be popping up not just for people who haven't used firefox in 2 months. People will get the message due to system clock problems, remote filesystem timestamp issues (http://forums.mozillazine.org/viewtopic.php?f=38&t=2766881&p=13166771) , or in corporate environments where the default firefox profile is automatically deployed, etc. If there is an easy, documented way to prevent the message then its not that big of a deal though for professional environments. In my opinion, "clean it up" and the subsequent explanations do not adequately explain what is going to happen, and I really question how often a "reset" is needed when a user is not experiencing any problems. I could see some less severe kind of clean up being helpful in certain cases, but even then there should be a way to turn off all of these "helpful" startup popup messages that aren't wanted in certain environments and can lead to confusion.

Several Additional Comments: This should be listed in the release notes as new, not as changed. Would it be possible to do this if Firefox actually starts slow or crashes often? Using an old profile probably does have correlation with such problems, but using this will both suggest to erase perfectly good profiles, and it will leave bad profiles in place. Is it possible to find out from telemetry data how good the correlation is? Erasing the whole profile doesn't sound like the ideal way to solve this. Is it possible to pinpoint the causes of the most frequent problems and fix them? Mozilla already remotely disables plugins that are known to cause problems, and Firefox learns to survive crash of plugins. Doesn't this already catch most of these issues? Would it be possible to tell the users which extension causes how much delay and how many crashes? This would allow the users to decide, and it would put pressure on the developers of those extensions. The end result would be better than the one from wiping old profiles. When Firefox learned to check which plugin were actively installed by users, it showed a list of automatically installed plugins, and let the users decide which ones they want to keep. In contrast this new feature doesn't say what it erases. It doesn't even explicitely say that it does erase things. I think it should. Please somebody describe - how does Firefox do the detection - what data will be lost by the reset (extensions?) - how can this function be switched off Regarding the way the detection is done, these things were mentioned: - nsIXULRuntime::replacedLockTime - Services.appinfo.replacedLockTime (is this a pref?) - datestamp of file parent.lock in profile directory Are they all the same?

(In reply to bugzilla.mozilla.org from comment #44) > I really wish this would have been implemented as a variable in prefs.js > like all of the other startup checks, and there should really be a way to > disable it. Is there still no option to disable this? In our enterprise environment we have a preconfigured Firefox profile in the default Windows profile. When new users login, they get this message, and potentially all our configuration gets blown away. We already use mozilla.cfg and would like to update it with something to stop this.

So, why are you commenting in a closed bug? You should file a bug explaining your issues, mark it as a regression and make it block this one.

PS: if you remove the parent.lock file from the default profile there should be no prompt, so maybe you could consider doing that as a workaround

(In reply to Marco Bonardo [:mak] from comment #50) > PS: if you remove the parent.lock file from the default profile there should > be no prompt, so maybe you could consider doing that as a workaround I was just commenting to say the same thing and mid-aired: (In reply to Jason Jackson from comment #48) Delete the profile lock file(s) in your preconfigured profile to avoid this issue. As Marco said, please file a new bug if that isn't enough.

To make it more clear, deleting the profile lock file (the name varies by platform) is the right way to address this and not just a workaround. Having that file present in system images not only leads to this feature taking effect, it also will lead to false-positives for startup crash detection and possibly other features now or in the future. If you are making images or standard profiles for Firefox, the profile lock file(s) should not be part of the image as they are used to know if Firefox is currently running or when it was last running.

I think it should be possible to disable the question/offer. First time I was asked I though why not, pressed the "Reset Firefox" button and lost all my bookmarks and stored passwords. What a pain! Fortunately I had a backup. Now I get asked frequently and always just close it but I'd prefer not to be asked in the first place.

fwiw, bookmarks should not be lost in the process... You should have filed a bug about that.

I suppose I thought that the word "Reset" was simply doing what it said on the tin and I should have known better. Note that my Firefox is in daily use. This is NOT after it being idle for anything like a month. V31.6.0.

(In reply to Barrie Walker from comment #55) > I suppose I thought that the word "Reset" was simply doing what it said on > the tin and I should have known better. > > Note that my Firefox is in daily use. This is NOT after it being idle for > anything like a month. V31.6.0. If your Firefox is in daily use and you see this warning (which should only be shown if having been idle for ages), then please file a separate bug. Continuing to comment here won't help us solve the issue, unfortunately.

In the expectation that Barrie won't file a separate bug: I've seen the Reset Firefox prompt on a family member's Firefox that was in daily use and hadn't been relaunched for a couple of months. (She was a couple of release numbers behind, on the beta channel.) I'll file a bug if that's unexpected.

Oh hey, someone already did. I'll go confirm those.

(In reply to Richard Newman [:rnewman] from comment #57) > In the expectation that Barrie won't file a separate bug: I've seen the > Reset Firefox prompt on a family member's Firefox that was in daily use and > hadn't been relaunched for a couple of months. (She was a couple of release > numbers behind, on the beta channel.) > > I'll file a bug if that's unexpected. (In reply to Richard Newman [:rnewman] from comment #58) > Oh hey, someone already did. I'll go confirm those. I can certainly file a bug report. But are you saying someone already has? I'll see if I can find it. (New to this forum.)

(In reply to Barrie Walker from comment #59) > I can certainly file a bug report. But are you saying someone already has? > I'll see if I can find it. (New to this forum.) Bug 1091619.