User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:26.0) Gecko/20100101 Firefox/26.0 (Beta/Release) Build ID: 20131206145143 Steps to reproduce: I have started Firefox after 60 days of system time. Actual results: Firefox asked me if I want to reset my profile. Expected results: There should also be an option to control how many days pf inactivity should pass until the question appears. Also the value 0 in this preference could be for disabling this message.

Why should there be an option? Ignoring the question is relatively easy; it doesn't make sense to offer customizability about when we'll ask it.

As always: Users could be annoyed if they see this message over and over but don't want to reset the profile.

(In reply to :Gavin Sharp (email gavin@gavinsharp.com) from comment #2) > Why should there be an option? [...] Please see the comments to bug #498181 and #945232; numerous reasons have already been discussed. Still, the best option is to fully remove the perfectly useless "feature" introduced with #498181.

(In reply to sworddragon2 from comment #3) > As always: Users could be annoyed if they see this message over and over but > don't want to reset the profile. They won't see it more often than once every 60 days.

(In reply to :Gavin Sharp (email gavin@gavinsharp.com) from comment #5) > They won't see it more often than once every 60 days. So, as already stated: 1. Experienced users are annoyed every 60 days, 2. Unexperienced users are both misled and annoyed every 60 days, just because they didn't use Firefox for a rather short time of two months. As there's no convincing reason for this unnecessary (and potentially misleading) annoyance, why not get rid of it? Or - if somebody should insist on keeping it - at least make it configurable?

> They won't see it more often than once every 60 days. This is already too much for some users :) And what if a user needs to change the system time often, for example for developing reasons?

"once every 60 days" is an upper bound on the frequency - it's even lower than that unless you always wait exactly 60 days between invocations of Firefox. The number of affected users and the magnitude/frequency of the annoyance are so small that this isn't worth discussing further.

Except that the other site was forgotten: What if somebody maintains hundreds of computers and 60 days are too long for him? Triggering this message more often could be useful too for example if the clients are complaining often about problems that were caused from defect profiles.

Gavin, you are missing the scenario where Firefox is used in a corporate/educational environment where a profile is pre-configured and distributed with a mandatory roaming (Windows) user profile. I provide approximately 1000 kiosk computers for students at a major university with Firefox ESR as one of the browser options. The Firefox profile is pre-configured at the start of session (and during periodic version updates) to minimize the time-to-useful-activity for the students. After 60 days, every use of Firefox would get this prompt. In our case, this would be a significant annoyance and resulting administrative overhead. A configuration option to disable this function would be acceptable (better than dropping Firefox and remaining with Chrome and IE).

Hi Mark, Can you file a new bug about that case, and CC me? Sounds like a problem worth investigating.

Another possible issue could become that some IT-admins are using scripts, or the directory of the default user, to put files into the profile directory of Firefox. For example the file that stores the certificates, or the whitelist for plugins. If Firefox resets the profile, these contents will be lost, and Firefox will not work properly any more (for example not accept data from intranet servers). Populating the directory of the default user is not the Mozilla way to set defaults in user profiles, but it is the standard way for many other software, so I'm pretty sure that this method is being used for Firefox as well. Firefox should only wipe things that are actually causing problems.

Has another bug been filed for this? I haven't been able to find it, if so. Our organization needs this fixed ASAP. We have thousands of computers that have DeepFreeze (by Faronics) loaded on them, so after 60 days, our Firefox installations start showing this message. Even if the user presses the "Reset Firefox" button, after reboot, the message returns because DeepFreeze does not allow permanent changes to the data on the hard drive. In the future, the Firefox team should disallow new features to be implemented without a way to disable them; that should be standard operating policy. Not doing so is bad practice. After all, this is almost always *someone* out there who would benefit from a way to disable features. In this case, this oversight negatively affects just about every school, university, and community college across the globe.

Jason: see bug 498181 comment 51. You should just delete the profile.lock file from the Firefox profile in your pre-configured images.

I deploy a large number of computers with a preconfigured firefox for an organization. Many of these computers go unused for weeks at a time. Displaying the 'reset user profile?' is very confusing to our users in this environment. All of the profiles are fine and don't need to be reset. As an administrator in an enterprise environment I would prefer that there be an option in prefs.js to disable this behavior.

As others have expressed here, this is a very undesirable feature in enterprise, education, and other large organizations. We set up the profiles in a very specific, uniform way--we don't want them reset for any reason ever. Deleting the parent.lock file from the default windows user covers many situations, but not all. Think of the results in education after staff (with existing profiles) return from summer break. We're not asking to change the default behavior. All we're asking for is the option. What's the harm in having this in about:config?

Has any progress been made on this bug? I think we're on the verge of simply pushing out a script to uninstall Firefox across most of our campus labs because we are simply getting too many calls about this. I really want to keep Firefox, but I also need our HelpDesk to be able to function.

I don't think any progress will be made until either a) a new bug is filed for this issue (as proposed in comment 11), or b) this bug is reopened. I guess nothing further will happen as long as it is set to RESOLVED WONTFIX. However, I definitly still think there is good reason to either solve this bug or completely remove the annoying "feature" by undoing bug #498181. There are enough scenarios where the current situation causes more problems than it solves.

I can certainly file a new bug, but it is essentially going to be identical to this one (and probably be marked a duplicate thereof). I am not sure why Gavin wanted a new bug filed (as per comment 11). The comment he was referring to, Comment 10, was simply an example of why this bug should exist. That's nothing new. That's why the majority of us are asking for the feature. My guess is that Gavin is unaware that the majority of computer labs and kiosks across college campuses around the world use mandatory profiles and/or Faronics DeepFreeze to disable permanent profile changes. Not everyone is a home user. This is not some "special case." My small community college alone has 2200 computers directly affected by this, so multiply that times the amount of colleges across the globe, and add kiosks that are trying to use Firefox. Any feature added to Firefox that has some time element *needs* to have an official way to disable it for environments where the computers have frozen partitions or profiles. Hacks are unacceptable in corporate and academic environments. How am I supposed to explain a hack to my CIO if it ever becomes an issue? "Yeah, I deleted that file to fix the issue; I didn't realize it would later break something else. Some guy on Bugzilla told me to do it." That should go over well with my CIO. I am also intrigued why there seems to be such a reluctance to simply add an option to disable it. If there was a will to create the feature in the first place, why is there such a lack of will to add a setting in about:config to disable it? Many of us didn't even ask for the feature in the first place, yet we are paying the price of having it.

This adds a simple boolean pref to disable the automatic 60-day prompting.

(In reply to Jason from comment #19) > I am also intrigued why there seems to be such a reluctance to simply add an > option to disable it. If there was a will to create the feature in the > first place, why is there such a lack of will to add a setting in > about:config to disable it? Many of us didn't even ask for the feature in > the first place, yet we are paying the price of having it. In general, because maintaining lots of options and configuration settings like that blows up the testing matrix and makes future development move slower. From your perspective it's "just add a single simple pref", but if we do that every time someone asks, we'd end up with thousands of prefs to maintain indefinitely, which is unmanageable. Obviously there's a tradeoff involved that requires us using our judgement. In this specific case, I've been convinced we should just add the pref, hence the patch. I appreciate those of you who have commented constructively. I'll request an uplift of this patch to Firefox 29, which is scheduled for release on April 29th.

(In reply to Jason from comment #19) > Hacks are unacceptable in corporate and academic > environments. How am I supposed to explain a hack to my CIO if it ever > becomes an issue? "Yeah, I deleted that file to fix the issue; I didn't > realize it would later break something else. Some guy on Bugzilla told me > to do it." That should go over well with my CIO. For what it's worth, that workaround (bug 498181 comment 51) is not any more "hacky" than setting the pref I'm adding would be, so in the interim you shouldn't let that stop you from using it to address the issue, if you can.

Repeating the comment I just left on bug 498181 here: 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 will send an email to the enterprise mailing list to spread the information.

Comment on attachment 8395434 [details] [diff] [review] add browser.disableResetPrompt pref Review of attachment 8395434 [details] [diff] [review]: ----------------------------------------------------------------- I guess this is fine for enterprise cases where they don't want users doing a reset to lose their enterprise customizations but I would think an extension to overlay the dialog would be a better way since there are multiple entry points.

Testing this revealed that the "Reset Warning" is broken on Mac due to bug 924456 :(

Comment on attachment 8395434 [details] [diff] [review] add browser.disableResetPrompt pref [Approval Request Comment] Bug caused by (feature/regressing bug #): bug 498181 User impact if declined: annoying prompting in certain large-installations Testing completed (on m-c, etc.): manual testing Risk to taking this patch (and alternatives if risky): minimal String or IDL/UUID changes made by this patch: no

https://hg.mozilla.org/releases/mozilla-aurora/rev/1bafe2bbc7ca https://hg.mozilla.org/releases/mozilla-beta/rev/b7271a31ac3b

Matt, I didn't see the option to reset profile using Firefox 31 beta 6 after changing the computer's date and then switching it back. I believe this is now expected, but using the browser.disableResetPrompt pref, the result is the same. Is this intended? Thank you!

The date checks only happen at startup so you need to restart Firefox after changing the computer's clock. Did you do that? The prompt should still be appearing after 60 days when this new browser.disableResetPrompt pref is false.

Firefox was closed each time when I changed the system date: 1. Change the system date with 1st March (more than 60 days ago) 2. Open Firefox 31 beta 6 with a new profile 2'. Add the pref browser.disableResetPrompt and set it to false 3. Close Firefox 4. Change the system date to the current date 5. Re-open Firefox Results: In both above cases, no prompt is shown at startup.

Hello Petruta, can you please file a new bug about the reset notification not appearing after 60 days (and CC me)? Please include the output from running Services.appinfo.replacedLockTime in the Browser Console when you expect the notification bar to appear. Please also provide OS information.

Looks like QA work on this is done, and this does not work as expected.

(In reply to Florin Mezei, QA (:FlorinMezei) from comment #35) > Looks like QA work on this is done, and this does not work as expected. I think bug 1035205 was filed to address the follow-up work so this can probably be marked verified fixed. If this is not working as expected though this should have been reopened. I'll leave that up to Matt to decide how he wants this to work.

(In reply to Florin Mezei, QA (:FlorinMezei) from comment #35) > Looks like QA work on this is done, and this does not work as expected. Arguably it works too well. The problem was that Petruta couldn't test the correct state before the patch. The after state was correct but Petruta couldn't verify it was because of this patch. I think we should leave this unverified until bug 1035205 is verified.

Sorry to post on a closed bug, but we just hit this issue today and this is the most appropriate place to post for those researching. I am an IT Director and despite that some people might not like having lots of options in about:config, when strange things are added like this “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!” there should be an option to turn it off. Deleting the .parentlock is a workaround but not appropriate in all cases. Things like this are more than just a potential annoyance to end-users, it can and DOES interfere with certain types of corporate and specialty use of the browser... especially when it comes to locking profiles and not wanting users to ever reset them. There are many ways to use Firefox, and not all of them are typical (and our use seems to often fall in the atypical category). Anyway, I do wish to thank those involved in the process to get this disable "feature" working. Hopefully pref browser.disableResetPrompt will make it into 32. See bug 1035205

(In reply to crxssi from comment #38) > Hopefully pref browser.disableResetPrompt will make it into 32. It's already in 29.

These are different things: In version 13 the function "reset profile" was added. This can be called from about:support, and from the safe mode dialog (which is automatically triggered after consecutive startup crashes). In version 25 the feature "welcome back" was introduced, which is another way to trigger the "reset profile" function. In version 29 an option was added to turn "welcome back" off. lockPref("browser.disableResetPrompt", true); Then came bug 1035205 which says that the "welcome back" feature does not work any more. If you do not like this feature, then this bug is good news for you ;-)

I am using Fedora-supplied Firefox 30 and when I go into about:config, there is no option called "browser.disableResetPrompt" or anything even close....

(In reply to crxssi from comment #41) > there is no option called "browser.disableResetPrompt" I believe it's intended to be a hidden preference. In about about:config, right-click > New > Boolean. The tricky part is, because of bug 1035205, you can't verify if you actually did it correctly. :(

Marking as Verified as per bug 1035205 resolution. The notification bar is disabled if the pref "browser.disableResetPrompt" is added and set to true.

(In reply to Jason Jackson from comment #42) > (In reply to crxssi from comment #41) > > there is no option called "browser.disableResetPrompt" > > I believe it's intended to be a hidden preference. In about about:config, > right-click > New > Boolean. The tricky part is, because of bug 1035205, > you can't verify if you actually did it correctly. :( Thanks, I have just verified this is working on Firefox 35.0. I am not sure why they would want to make this hidden, though. Shouldn't be a secret. Hiding it just makes it that much more difficult for people to quickly find it and enable it and verify it works correctly. Grrrrrr.

(In reply to Matthew N. [:MattN] from comment #23) > Repeating the comment I just left on bug 498181 here: > 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. ¡Hola! Just dropping a breadcrumb for others as I did this research for a user on #firefox, the "profile lock file" is detailed at http://kb.mozillazine.org/Profile_in_use#Remove_the_profile_lock_file ¡Gracias! Alex