All passwords deleted upon startup if privacy.clearOnShutdown.passwords = True but privacy.sanitize.sanitizeOnShutdown = false

VERIFIED FIXED in Firefox 44

Status

()

Firefox
General
--
critical
VERIFIED FIXED
2 years ago
2 years ago

People

(Reporter: Paul Goldberg, Assigned: MattN)

Tracking

({dataloss, regression})

42 Branch
Firefox 47
dataloss, regression
Points:
---
Dependency tree / graph
Bug Flags:
qe-verify +

Firefox Tracking Flags

(firefox44+ verified, firefox45 unaffected, firefox46 verified, firefox47 verified, firefox-esr38 unaffected, firefox-esr45 affected, relnote-firefox 44+)

Details

Attachments

(4 attachments)

(Reporter)

Description

2 years ago
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:44.0) Gecko/20100101 Firefox/44.0
Build ID: 20160120154102

Steps to reproduce:

Upgrade from Firefox 43 (64 bit) to Firefox 44 RC2 64 bit.


Actual results:

All my saved passwords appears to be deleted along with my password sign in.  Going back to Firefox 43 and my passwords are still gone.  The only way I can get my passwords back is to put my saved Mozilla directory back in Appdata - Roaming in Windows 10 64 bit. This works only in Firefox 43 not Firefox 44. 


Expected results:

Password manager should continue to work with saved passwords.
(Reporter)

Updated

2 years ago
Severity: normal → critical
OS: Unspecified → Windows 10
Hardware: Unspecified → x86_64

Updated

2 years ago
Component: Untriaged → Password Manager
Keywords: dataloss
Product: Firefox → Toolkit
(Reporter)

Comment 1

2 years ago
The only work around to get my passwords into Firefox 44 was after the upgrade to Firefox 44 restore the logins.json file to the Mozilla Preferences directory in Appdata roaming.
(Reporter)

Comment 2

2 years ago
This is from the Norton forum website where I also posted this problem.  This is feedback from another that has the same problem:

Firefox 44 user 
Topopurim47's picture
Topopurim47
Regular Contributor5
Reg: 21-Feb-2009
Posts: 300
Solutions: 1
Kudos: 34
Add Kudos
0
Re: Firefox 44 Release Candidate - Password Problem
Posted: 27-Jan-2016 | 1:47PM • Permalink new

win764bit, ns22.5, ff44.0      been using firefox password mgr for several sites(no banking, etc)  everything was working good. updated to ff44.0   now the popup window for entering the master password does not appear making ff pw mgr unusable..i entered feedback of problem to ff. thanks

https://community.norton.com/en/comment/6875961#comment-6875961
[Tracking Requested - why for this release]:
i am going to confirm this bug based on seeing a couple of similar user reports:
https://input.mozilla.org/?q=password&product=Firefox&date_end=2016-01-27&date_start=2016-01-20&version=44.0
https://support.mozilla.org/en-US/questions/1106621
https://support.mozilla.org/en-US/questions/1106675
https://support.mozilla.org/en-US/questions/1106737
http://www.camp-firefox.de/forum/viewtopic.php?f=1&t=116714
Status: UNCONFIRMED → NEW
tracking-firefox44: --- → ?
Ever confirmed: true

Comment 4

2 years ago
Matt, I thought I'd start with you. As Philipp mentioned above, we are seeing several user reports of this issue. Would you be able to help investigate? Thanks!
Flags: needinfo?(MattN+bmo)

Comment 5

2 years ago
Florin, could your team please verify that password manager works as expected on 44.0-build3 (released build)? Thanks!
Flags: needinfo?(florin.mezei)
https://input.mozilla.org/dashboard/response/5792793 and https://support.mozilla.org/questions/1106737#answer-836425 would indicate that affected users' logins.json is emptied
I'm not seeing anything obvious in pwmgr changes that targetted Fx44…
I don't see any huge drops in saved passwords via telemetry when comparing aggregates of beta 43 to beta 44. I saw some reports saying that the checkbox to remember passwords was also unchecked which leads me to be suspicious of this code which first shipped in Fx42: http://hg.mozilla.org/mozilla-central/diff/fb4f42bbeb01/browser/base/content/sanitize.js#l1.43
Can anyone who experienced this issue confirm that the remember passwords checkbox was also unchecked in preferences?
(Reporter)

Comment 10

2 years ago
The remember passwords box was unchecked after the update to Firefox 44.
Thanks.

* When the passwords were gone, did you happen to look for logins.json? If it existed, did you see what was in the file?
* Do you use Firefox Sync?

Can you attach the data from about:support via "Copy text to clipboard"? You can attach here: https://bugzilla.mozilla.org/attachment.cgi?bugid=1242176&action=enter

I'm wondering if an extension caused this.
Flags: needinfo?(pgoldberg)
(Reporter)

Comment 12

2 years ago
I did not look at the contents of logins.json but when I replaced the file with a backup version of logins.json all my passwords were back and it worked normally so either the file was erased or became corrupted. I also tried doing the update with all extensions disabled and again no more passwords.  I do not use Firefox Sync.
Flags: needinfo?(pgoldberg)
(Reporter)

Comment 13

2 years ago
Created attachment 8712986 [details]
about:support
(In reply to Paul Goldberg from comment #12)
>  I also tried doing the update with all extensions disabled and again no more
> passwords. 

Oh, I didn't know you could reproduce this, that's very helpful. Could you please set the pref signon.debug to True in about:config then do the update again without extensions and hopefully it will happen again. Then open the Browser Console with Ctrl-Shift-J and copy the content into an attachment on this bug. If I know what the error message is then it'll be much easier to narrow down the cause of this.

Thanks in advance.
Flags: needinfo?(MattN+bmo) → needinfo?(pgoldberg)
(Reporter)

Comment 15

2 years ago
Sorry I can not any longer reproduce the bug.  I went back for Firefox 43 and then to Firefox 44 (release version).  The I went back to Firefox 43 and then to Firefox 44 (RC2).  Then I went back to Firefox 43 and then uninstalled it.  Then I rebooted and installed Firefox 44 (release version) but in all cases the passwords were retained.
Flags: needinfo?(pgoldberg)
Perhaps the problem doesn't happen in safe mode (and your check earlier wasn't actually safe mode?) and can only happen with one of your extensions?
(Reporter)

Comment 17

2 years ago
When I did all of the trying to reproduce the bug I did not put it into safe mode, all the extensions were functioning.  The only difference is some extensions were updated (Firefox auto updated). Again, previously when the bug was reproducible I did try the upgrade with all the extensions disabled.
i think the common factor in all of the about:support logs i have seen is the presence of the "Norton Identity Safe" {C1A2A613-35F1-4FCF-B27F-2840527B6556} extension.
sorry, have to backtrack on comment #18 - just stumbled across a user who lost pwds without identity safe...
(Reporter)

Comment 20

2 years ago
I was able to reproduce the bug by putting my old profile back into Firefox 44 - logind.json was empty except for the exclusions I had entered:

{"nextId":142,"logins":[],"disabledHosts":["https://securebanking.xxxx.com","https://www.paypal.com"],"version":1}


I will now try to do what you suggested above.
(Reporter)

Comment 21

2 years ago
I disabled all the extensions and again went from FF43 to FF44 (64 bit) and all my logins were again deleted - this only works putting in my old profile.  So something within my profile causes the deletion of the passwords.
(Reporter)

Comment 22

2 years ago
Created attachment 8713169 [details]
Browser Console.txt
(Reporter)

Updated

2 years ago
Summary: Password Manager In Firefox 44 (RC2) not working → Password Manager In Firefox 44 not working
(Reporter)

Comment 23

2 years ago
Another report of this bug:


noghere's picture
noghere
Super Keylogger Crusher10
Reg: 20-Apr-2011
Posts: 365
Solutions: 10
Kudos: 29
Kudos0
Re: Firefox 44 Release Candidate - Password Problem
Posted: 28-Jan-2016 | 12:35AM • Permalink

Same problem here. It is the first time this issue happened updating FF. I solved restoring the old logins.json file (I saved the old profile) in the Users>your name>AppData>Roaming>Mozilla>Firefox>Profiles>xxxxxx.default directory. It is a Mozilla bug and not a Norton problem.

http://community.norton.com/en/comment/6877131#comment-6877131

Comment 24

2 years ago
Unable to reproduce this issue under Windows 7 64-bit nor Windows 10 64-bit - after applying updates from 43.0 and 43.0.1 to the latest 44.0RC:
* all the logins are saved 
* 'Use a master password' checkbox is still marked
* the popup window for entering the master password is displayed 
Even tried with a bunch of extensions (Password Exporter, BetterPrivacy, Adblock Plus) via the about:support file from comment 13, but without success.
Please let me know if I can help more!
Flags: needinfo?(florin.mezei)
Summary: Password Manager In Firefox 44 not working → Password Manager In Firefox 44 (RC2) not working
Comment on attachment 8713169 [details]
Browser Console.txt

Thanks for the log, this helps narrow it down. It's definitely code at startup that is removing all logins and then flipping the rememberSignons prefs to false which leads me even more to http://hg.mozilla.org/mozilla-central/diff/fb4f42bbeb01/browser/base/content/sanitize.js#l1.43 from bug 1102184 since it does these exact operations in the same order. I don't see other code in mozilla-release doing that. I'm going to try and repro.

> nsLoginManager:Removing all logins nsLoginManager.js:349
> Login storage:Removing all logins storage-json.js:388
> nsLoginManager:got change to rememberSignons preference nsLoginManager.js:149

The log plus contents of logins.json eliminate the possibility of a corrupt logins.json.
(In reply to Paul Goldberg from comment #21)
> So something within my profile causes the deletion of the
> passwords.

You've been very helpful at narrowing this down but I have another favor to ask… could you provide the prefs.js file and/or about:support output from before the upgrade when it's going to delete all logins? I think you're hitting a "one-time" migration that should have happened in Fx42 if you had certain pref values: http://hg.mozilla.org/mozilla-central/diff/fb4f42bbeb01/browser/base/content/sanitize.js#l1.40
Flags: needinfo?(pgoldberg)
(Reporter)

Comment 27

2 years ago
Created attachment 8713258 [details]
prefs.js
Flags: needinfo?(pgoldberg)
Comment on attachment 8713258 [details]
prefs.js

Awesome.

> user_pref("privacy.clearOnShutdown.passwords", true);

So your profile had the pref to removal all passwords at shutdown/startup and we're just respecting that. Since we removed that option in bug 1102184, we are doing a one time migration and removing all passwords then disabling remembering new ones. Given that you are surprised about the deletion, I'm guessing that you didn't intend for that preferences to be set to true or be in effect so perhaps the migration code should have been checking an additional preference…
(In reply to Matthew N. [:MattN] from comment #28)
> Given that you are surprised about the deletion, I'm
> guessing that you didn't intend for that preferences to be set to true or be
> in effect so perhaps the migration code should have been checking an
> additional preference…

Yeah… privacy.sanitize.sanitizeOnShutdown should have been checked too… :(
Assignee: nobody → MattN+bmo
Blocks: 1102184
Status: NEW → ASSIGNED
status-firefox44: --- → affected
status-firefox45: --- → affected
status-firefox46: --- → affected
status-firefox47: --- → affected
status-firefox-esr38: --- → unaffected
status-firefox-esr45: --- → affected
Keywords: regression
OS: Windows 10 → All
Hardware: x86_64 → All
Summary: Password Manager In Firefox 44 (RC2) not working → All passwords deleted upon startup if privacy.clearOnShutdown.passwords = True but privacy.sanitize.sanitizeOnShutdown = false
Component: Password Manager → General
Product: Toolkit → Firefox
Version: 44 Branch → 42 Branch
I'm not sure why this is still happening on Fx44, it should only happen the first time a user upgrades to Fx42+. Some extensions set privacy.clearOnShutdown.passwords to True and that's probably what's happening here. Perhaps "Norton Identity Safe" did that at one time and I would be surprised if other enterprise deployments and third-party password managers set that pref in the past even if it shouldn't have had an effect anymore with privacy.sanitize.sanitizeOnShutdown = false.

I mention enterprise since it's one of the prefs that CCK2 suggests to override.

Comment 31

2 years ago
It's still unclear to me how this relates to Norton Identity Safe specifically, but I can confirm that 100% of the users I found who gave Input feedback on this with config data had Norton Identity Safe installed:
https://input.mozilla.org/en-US/dashboard/response/5791738
https://input.mozilla.org/en-US/dashboard/response/5792017
https://input.mozilla.org/en-US/dashboard/response/5792087
https://input.mozilla.org/en-US/dashboard/response/5792770
https://input.mozilla.org/en-US/dashboard/response/5793085
https://input.mozilla.org/en-US/dashboard/response/5793184
https://input.mozilla.org/en-US/dashboard/response/5793511
https://input.mozilla.org/en-US/dashboard/response/5793570
(Reporter)

Comment 32

2 years ago
I never intended or set (knowingly) that flag.  Since others have had their passwords deleted (and I am sure) they also did not choose it. Something must have happened to set it that was not under the control of the user.
Created attachment 8713278 [details] [diff] [review]
v.1 Check privacy.sanitize.sanitizeOnShutdown = true
Attachment #8713278 - Flags: review?(dolske)
Comment on attachment 8713278 [details] [diff] [review]
v.1 Check privacy.sanitize.sanitizeOnShutdown = true

Review of attachment 8713278 [details] [diff] [review]:
-----------------------------------------------------------------

Ugh. Yeah, this is a latent bug we shipped in 42. Probably didn't affect too many people, since it's a slightly unusual state to be in.

How I love that (apparently) the Norton crapware shipped a pref change that has no actual functionality other than to trigger this bug. :(
Attachment #8713278 - Flags: review?(dolske) → review+
Depends on: 1243841
STR:
WARNING: This will delete all logins.
1) Set the prefs privacy.clearOnShutdown.passwords = True (add it as new in versions after 42) and privacy.sanitize.sanitizeOnShutdown = false
2) Add some saved passwords (they will be deleted)
3) Start/restart Firefox

Expected result:
All logins are still present in Preferences > Security > Saved Logins… and the "Remember Logins" checkbox is still checked.

Actual result:
All logins are deleted. The "Remember Logins" checkbox is unchecked.
(In reply to Matthew N. [:MattN] from comment #35)
You also need to set privacy.sanitize.migrateClearSavedPwdsOnExit = False if you are testing in a profile which already ran Fx42+ code.

Comment 37

2 years ago
The issue occurred to my two computers running XP SP3 and Win7 SP1, both running Norton Internet Security.

--The remember passwords box was unchecked after the update to Firefox 44?
Yes

-- When the passwords were gone, did you happen to look for logins.json? If it existed, did you see what was in the file?
Yes, the file existed and was empty (4kb).

--Do you use Firefox Sync?
No.

I restored the old saved logins.json file and all worked fine again.
(In reply to noghere from comment #37)
Thanks for the info. That aligns with the other reports so you are likely hitting this same problem. We're fixing this for 45+ in this bug and for users of older versions we will hotfix in bug 1243841 to prevent the data loss.
Verification steps that bug 1102184 is still working (now more properly):

1) Set the prefs: 
* privacy.clearOnShutdown.passwords = True
* privacy.sanitize.sanitizeOnShutdown = True
* privacy.sanitize.migrateClearSavedPwdsOnExit = False
2) Add some saved passwords (they will be deleted)
3) Start/restart Firefox

Expected result:
All logins are deleted. The "Remember Logins" checkbox is unchecked.

We expect all logins to be deleted in this case since privacy.sanitize.sanitizeOnShutdown is now True (in comment 35 it's false).
Comment on attachment 8713278 [details] [diff] [review]
v.1 Check privacy.sanitize.sanitizeOnShutdown = true

I completed my own verification using comment 35 and comment 39 and things worked as expected so I will land this now.

I'm not sure if we need approval‑mozilla‑release or not since we are considering hotfix in bug 1243841.

Approval Request Comment
[Feature/regressing bug #]: Bug 1102184
[User impact if declined]: Users with privacy.clearOnShutdown.passwords = True (either set by the user in Prefs before Fx42 or set by an extension [possibly Norton Identity Safe]) will have their logins deleted unexpectedly even if the effect of privacy.clearOnShutdown.passwords should have been disabled due to privacy.sanitize.sanitizeOnShutdown = False.
[Describe test coverage new/current, TreeHerder]: Manual verification
[Risks and why]: Low risk trivial oversight in the one-time migration patch
[String/UUID change made/needed]: None
Attachment #8713278 - Flags: approval-mozilla-release?
Attachment #8713278 - Flags: approval-mozilla-beta?
Attachment #8713278 - Flags: approval-mozilla-aurora?

Comment 41

2 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/92cc1d89929b
Tracked. We are planning to hotfix this issue soon (today if possible).
tracking-firefox44: ? → +
Can someone provide me with a copy of the "Norton Identity Safe" extension code? The version from https://identitysafe.norton.com/ is from 2014. I'm guessing that a newer version is bundled with Norton 360?

The extensions should be in a directory like C:\ProgramData\Norton\{0C55C096-0F1D-4F28-AAA2-85EF591126E7}\N360_22.5.2.15\coFFAddon\

The "coFFAddon" is the important part. Could somebody zip that coFFAddon directory up and attach it here?
Flags: needinfo?(pgoldberg)
Never mind, I got the 2016.5.6.90 version of the extension by installing the trial and updating many times.
Flags: needinfo?(pgoldberg)
(Reporter)

Comment 45

2 years ago
The current version of Norton does not include identity safe.  Since October 2015 Norton has been working on a signed version for Firefox.  The only working extension is Norton Safe Web.
Matt, (once the hotfix is pushed out) is it possible to add an automated test for this scenario? Just so we can catch regressions like this in the future.
Flags: needinfo?(MattN+bmo)

Updated

2 years ago
Duplicate of this bug: 1243842
OK, it all makes sense now. After a lot of investigation and fiddling with various versions of Norton I think I understand the whole story now.

To start, bug 1089695 isn't the problem as it was correct at the time of landing and worked properly (respecting both prefs) for Fx42 and Fx43. See https://hg.mozilla.org/mozilla-central/rev/fb4f42bbeb01#l2.44 and it's check for Sanitizer.prefShutdown ("sanitizeOnShutdown"). Note though that the migration pref (privacy.sanitize.migrateClearSavedPwdsOnExit) didn't get set to true unconditionally, only if Sanitizer.prefShutdown && Sanitizer.prefDidShutdown doesn't have a user value. This made it different than most one-time migrations in that it could happen after the first time running the Fx42 code. It was waiting to run at startup when the conditions were right. I think that may have contributed a bit to the problem, at least for users who had already run Fx42 and/or Fx43 before.

The main problem is that the refactoring in bug 1089695, specifically https://hg.mozilla.org/releases/mozilla-release/diff/9a6d45264eb2/browser/base/content/sanitize.js#l1.898 , which removed the check for privacy.sanitize.sanitizeOnShutdown before doing the migration code. That landed in Fx44 which explains why the reports are just coming in now. Note that the indentation in sanitize.js is incorrect since that landing.

I confirmed that a 2015 version of the Norton extension (with binary components) set the privacy.clearOnShutdown.passwords pref to true via one of its DLLs while not necessarily setting privacy.sanitize.sanitizeOnShutdown to true. That explains why Norton users are affected by the regression introduced in bug 1089695.

I'll proceed with a hotfix now. I think the fix that landed here on inbound is sufficient for in-tree fixes.
Blocks: 1089695
(In reply to Matthew N. [:MattN] from comment #48)
> OK, it all makes sense now. After a lot of investigation and fiddling with
> various versions of Norton I think I understand the whole story now.

I've seen norton mentioned few times at this bug, but I don't have any norton products installed and yet I also bumped into this at bug 1243842 (dup of this), specifically, I had privacy.clearOnShutdown.passwords = True.

I don't recall changing this pref manually any time recently via about:config, so what could have changed it? Is there any legitimate combination of options (via UI) which end up with this pref set? Maybe in earlier versions of firefox and it was kept at this value since then?
(In reply to Avi Halachmi (:avih) from comment #49)
> I've seen norton mentioned few times at this bug, but I don't have any
> norton products installed

Did you ever? It doesn't need to be installed anymore.

> I don't recall changing this pref manually any time recently via
> about:config, so what could have changed it? Is there any legitimate
> combination of options (via UI) which end up with this pref set? Maybe in
> earlier versions of firefox and it was kept at this value since then?

The UI option to toggle this was removed in bug 1102184 for Fx42. You possibly checked the checkbox any time before then.
(In reply to Matthew N. [:MattN] from comment #50)
> Did you ever? It doesn't need to be installed anymore.

Not that I recall, it happened to me on two different systems* which I installed from scratch without OEM crapware, and definitely I never installed Norton AV or other "pc cleanup" stuff. At the very least not in the past 3 years (where the same profile was used since on both systems).

* On the first system where it happened I didn't have a profile backup, so I cannot confirm this pref was set to true there too.

> The UI option to toggle this was removed in bug 1102184 for Fx42. You
> possibly checked the checkbox any time before then.

I don't think I have, but I might - depending on how it was presented at the UI. If, as its name suggests, it would delete saved logins+passwords on exit, then I definitely didn't set it or have it set, since logins were clearly saved and kept - as I want them to - between sessions.

What does/did this pref do in terms of behavior?
(In reply to Avi Halachmi (:avih) from comment #51)
> (In reply to Matthew N. [:MattN] from comment #50)
> > Did you ever? It doesn't need to be installed anymore.
> 
> Not that I recall, it happened to me on two different systems* which I
> installed from scratch without OEM crapware, and definitely I never
> installed Norton AV or other "pc cleanup" stuff. At the very least not in
> the past 3 years (where the same profile was used since on both systems).
> 
> * On the first system where it happened I didn't have a profile backup, so I
> cannot confirm this pref was set to true there too.

That pref synced.

> > The UI option to toggle this was removed in bug 1102184 for Fx42. You
> > possibly checked the checkbox any time before then.
> 
> I don't think I have, but I might - depending on how it was presented at the
> UI. If, as its name suggests, it would delete saved logins+passwords on
> exit, then I definitely didn't set it or have it set, since logins were
> clearly saved and kept - as I want them to - between sessions.
> 
> What does/did this pref do in terms of behavior?

https://support.mozilla.org/en-US/kb/delete-browsing-search-download-history-firefox#w_how-do-i-make-firefox-clear-my-history-automatically
Flags: needinfo?(MattN+bmo)
Matt and I chatted over IRC and we are wondering if there are other entities (other than passwords) like cookies/cache/form & search history which might get removed in these data migration scenarios too. We will request Florin's team to help test those migration scenarios to know for sure.
I'll check when I have time (I'm heading out for a conference), but there are chances I may have caused that bug. If this is what I suspect, yes, cookies/cache/form & search history might get removed, too.
As well as offline apps, list of downloads, http sessions and site-specific settings.
Verification of your fix in bug 1089695 is happening over there. We'll focus verification in this bug on this fix that landed here to fix the regression.
Flags: qe-verify+
Thanks for figuring out this problem, shame on me for not noticing it, but honestly it was really hard to notice.
I actually think the wrong indentation fooled me (eslint would have noticed it!), that code should have been moved to onShutdown, where we do actually check the shutdown pref! And I think we should still do that rather than adding another pref check.

Comment 58

2 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/92cc1d89929b
Status: ASSIGNED → RESOLVED
Last Resolved: 2 years ago
status-firefox47: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 47
I filed bug 1244064 to move the code to the proper place (regardless it needs indentation fixes).

Updated

2 years ago
See Also: → bug 1244230
(In reply to Matthew N. [:MattN] from comment #48)
> OK, it all makes sense now. After a lot of investigation and fiddling with
> various versions of Norton I think I understand the whole story now.
> [...]

Thanks for the great investigation! I feel a lot more confident with the fix, being able to explain the confusing details we saw while starting to look into it.

U+1F4AF HUNDRED POINTS SYMBOL (sorry, that's the best Bugzilla can do for emoji)
Comment on attachment 8713278 [details] [diff] [review]
v.1 Check privacy.sanitize.sanitizeOnShutdown = true

Taking it as it is a major problem.
Should be in 45 beta 2
Attachment #8713278 - Flags: approval-mozilla-beta?
Attachment #8713278 - Flags: approval-mozilla-beta+
Attachment #8713278 - Flags: approval-mozilla-aurora?
Attachment #8713278 - Flags: approval-mozilla-aurora+

Comment 62

2 years ago
bugherderuplift
https://hg.mozilla.org/releases/mozilla-aurora/rev/7ca71faafccb
status-firefox46: affected → fixed

Comment 63

2 years ago
bugherderuplift
https://hg.mozilla.org/releases/mozilla-beta/rev/b02e8e8f06da
status-firefox45: affected → fixed
Depends on: 1244908
See Also: bug 1244230
Duplicate of this bug: 1244230
Comment on attachment 8713278 [details] [diff] [review]
v.1 Check privacy.sanitize.sanitizeOnShutdown = true

This issue is the main-drivers for 44.0.1. Let's uplift the patch to moz-release.
Attachment #8713278 - Flags: approval-mozilla-release? → approval-mozilla-release+

Comment 66

2 years ago
bugherderuplift
https://hg.mozilla.org/releases/mozilla-release/rev/9e0819a359d5
status-firefox44: affected → fixed
I've tested this on FF 44.0.1 on Win 7.
I can't reproduce the problem in comment 35.
I can reproduce the expected results in comment 39, though I'm not sure I understand why the logins should be gone if the option was removed in bug 1102184.
Let me know is these are the correct results.

Also, based on comment 48, do I need to test other scenarios?
Flags: needinfo?(MattN+bmo)
Paul, could you please verify the problem is gone on FF 44.0.1 on your end too?
Thanks.
https://archive.mozilla.org/pub/firefox/candidates/44.0.1-candidates/build1/
Flags: needinfo?(pgoldberg)
(Reporter)

Comment 69

2 years ago
I also tested 44.0.1 and it works!  I wnt back to 43.0.4 and the put the old Firefox directory in Appdata/Roaming, the n verified the passwords were there. I then upgraded to 44.0.1 and verified that the passwords were intact. Everything else seems to function normally.
Flags: needinfo?(pgoldberg)
(In reply to Paul Silaghi, QA [:pauly] from comment #67)
> I've tested this on FF 44.0.1 on Win 7.
> I can't reproduce the problem in comment 35.

I assume you're saying you can reproduce this problem in the fixed build but could in 44.0.

> I can reproduce the expected results in comment 39, though I'm not sure I
> understand why the logins should be gone if the option was removed in bug
> 1102184.

They should be deleted since we do one last deletion of the logins for people who were previously deleting them on every shutdown.

> Let me know is these are the correct results.

No, you should be able to reproduce the expected results in comment 39 or something is wrong. Ensure all three prefs have the correct value in a pre-Fx44 build before running 44.0.1

> Also, based on comment 48, do I need to test other scenarios?

Verification of other scenarios are in bug 1089695. We could do those verifications on 44.0.1.

P.S. The abbreviation for Firefox is Fx, not FF.
Flags: needinfo?(MattN+bmo)
So, I reproduced the problem on Fx 44.0 (actual results in comment 35).
I got the expected results in comments 35, 39 on Fx 44.0.1.
I also tried the scenarios in bug 1089695 - everything ok.
Based on my testing and reporter's testing in comment 69, I'm marking this bug as verified on Fx 44.0.1.
status-firefox44: fixed → verified
So who exactly is affected by the fix?

As far as I understand it only affects update to 44.0, so whoever updated and got hit cannot restore their passwords, and whoever updated and didn't get hit will also not get hit in the future.

So the fix for 44.0.1 will only affect those who still didn't update to 44? (I'm not saying it shouldn't get fixed, just trying to understand whom would it help).

Comment 73

2 years ago
(In reply to Avi Halachmi (:avih) from comment #72)
> So the fix for 44.0.1 will only affect those who still didn't update to 44?

AFAIK, yes, and that's also why we stopped updates to 44.0 some time ago and will only turn them on again when we push 44.0.1 - about 2/3-3/4 of our users seem to have not updated yet.
Added to the release notes with "Fix a rare bug which triggered the removal of stored passwords (1242176)" as wording
relnote-firefox: --- → 44+
Verified fixed Fx 45b6, 46.0a2 (2016-02-18) Win 7.
Don't know why, but I'm not getting the expected results in comment 39 on 47.0a1 (2016-02-17) -> the logins are not deleted, and the checkbox remains checked.
status-firefox45: fixed → verified
status-firefox46: fixed → verified
Flags: needinfo?(MattN+bmo)
(In reply to Paul Silaghi, QA [:pauly] from comment #75)
> Don't know why, but I'm not getting the expected results in comment 39 on
> 47.0a1 (2016-02-17) -> the logins are not deleted, and the checkbox remains
> checked.

The migration code was removed in bug 1244908 (2016-02-04 on m-c) so you would need to test on a version before that.
Flags: needinfo?(MattN+bmo)
Ty.
Verified fixed Fx 47.0a1 (2016-02-02).
Status: RESOLVED → VERIFIED
status-firefox47: fixed → verified
I backed out this from Firefox 45 cause the underlying bug 1089695 that caused this has been backed out 
https://hg.mozilla.org/releases/mozilla-beta/rev/ce5224000cec

Please verify everything is as expected.
Flags: needinfo?(MattN+bmo)

Updated

2 years ago
status-firefox45: verified → unaffected
I confirmed at https://hg.mozilla.org/releases/mozilla-beta/annotate/30d48874cea4/browser/base/content/sanitize.js#l761 that the migrateClearSavedPwdsOnExit check is back inside the sanitizeOnShutdown pref check.
Flags: needinfo?(MattN+bmo)
You need to log in before you can comment on or make changes to this bug.