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

Status: VERIFIED FIXED

(Firefox :: General, defect)

Description

[Paul Goldberg]

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.

Comment 1

[Paul Goldberg]

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.

Comment 2

[Paul Goldberg]

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

Comment 3

[[:philipp]]

[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

Comment 4

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

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!

Comment 5

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Florin, could your team please verify that password manager works as expected on 44.0-build3 (released build)? Thanks!

Comment 6

[[:philipp]]

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

Comment 7

[Matthew N. [:MattN]]

I'm not seeing anything obvious in pwmgr changes that targetted Fx44…

Comment 8

[Matthew N. [:MattN]]

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

Comment 9

[Matthew N. [:MattN]]

Can anyone who experienced this issue confirm that the remember passwords checkbox was also unchecked in preferences?

Comment 10

[Paul Goldberg]

The remember passwords box was unchecked after the update to Firefox 44.

Comment 11

[Matthew N. [:MattN]]

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.

Comment 12

[Paul Goldberg]

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.

Comment 13

[Paul Goldberg]

Attachment: about:support

Comment 14

[Matthew N. [:MattN]]

(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.

Comment 15

[Paul Goldberg]

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.

Comment 16

[Matthew N. [:MattN]]

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?

Comment 17

[Paul Goldberg]

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.

Comment 18

[[:philipp]]

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.

Comment 19

[[:philipp]]

sorry, have to backtrack on comment #18 - just stumbled across a user who lost pwds without identity safe...

Comment 20

[Paul Goldberg]

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.

Comment 21

[Paul Goldberg]

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.

Comment 22

[Paul Goldberg]

Attachment: Browser Console.txt

Comment 23

[Paul Goldberg]

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

[Ada [:adalucinet]]

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!

Comment 25

[Matthew N. [:MattN]]

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.

Comment 26

[Matthew N. [:MattN]]

(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

Comment 27

[Paul Goldberg]

Attachment: prefs.js

Comment 28

[Matthew N. [:MattN]]

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…

Comment 29

[Matthew N. [:MattN]]

(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… :(

Comment 30

[Matthew N. [:MattN]]

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

[Robert (rrayborn, he/him)]

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

Comment 32

[Paul Goldberg]

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.

Comment 33

[Matthew N. [:MattN]]

Attachment: v.1 Check privacy.sanitize.sanitizeOnShutdown = true

Comment 34

[Justin Dolske [: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. :(

Comment 35

[Matthew N. [:MattN]]

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.

Comment 36

[Matthew N. [:MattN]]

(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

[noghere]

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.

Comment 38

[Matthew N. [:MattN]]

(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.

Comment 39

[Matthew N. [:MattN]]

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 40

[Matthew N. [:MattN]]

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

Comment 41

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/92cc1d89929b

Comment 42

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Tracked. We are planning to hotfix this issue soon (today if possible).

Comment 43

[Matthew N. [:MattN]]

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?

Comment 44

[Matthew N. [:MattN]]

Never mind, I got the 2016.5.6.90 version of the extension by installing the trial and updating many times.

Comment 45

[Paul Goldberg]

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.

Comment 46

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

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.

Comment 48

[Matthew N. [:MattN]]

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.

Comment 49

[Avi Halachmi (:avih)]

(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?

Comment 50

[Matthew N. [:MattN]]

(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.

Comment 51

[Avi Halachmi (:avih)]

(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?

Comment 52

[Matthew N. [:MattN]]

(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

Comment 53

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

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.

Comment 54

[David Teller [:Yoric] - still alive but not very active]

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.

Comment 55

[David Teller [:Yoric] - still alive but not very active]

As well as offline apps, list of downloads, http sessions and site-specific settings.

Comment 56

[Matthew N. [:MattN]]

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.

Comment 57

[Marco Bonardo [:mak]]

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

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/92cc1d89929b

Comment 59

[Marco Bonardo [:mak]]

I filed bug 1244064 to move the code to the proper place (regardless it needs indentation fixes).

Comment 60

[Justin Dolske [:Dolske]]

(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 61

[Sylvestre Ledru [:Sylvestre]]

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

Comment 62

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/7ca71faafccb

Comment 63

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/releases/mozilla-beta/rev/b02e8e8f06da

Comment 65

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

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.

Comment 66

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/releases/mozilla-release/rev/9e0819a359d5

Comment 67

[Paul Silaghi, QA [:pauly]]

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?

Comment 68

[Paul Silaghi, QA [:pauly]]

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/

Comment 69

[Paul Goldberg]

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.

Comment 70

[Matthew N. [:MattN]]

(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.

Comment 71

[Paul Silaghi, QA [:pauly]]

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.

Comment 72

[Avi Halachmi (:avih)]

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

[Robert Kaiser]

(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.

Comment 74

[Sylvestre Ledru [:Sylvestre]]

Added to the release notes with "Fix a rare bug which triggered the removal of stored passwords (1242176)" as wording

Comment 75

[Paul Silaghi, QA [:pauly]]

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.

Comment 76

[Matthew N. [:MattN]]

(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.

Comment 77

[Paul Silaghi, QA [:pauly]]

Ty.
Verified fixed Fx 47.0a1 (2016-02-02).

Comment 78

[Marco Bonardo [:mak]]

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.

Comment 79

[Matthew N. [:MattN]]

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.

Comment 80

[Rob N]

Hi folks.
I don't know how PRECISELY, but there is still some kind of issue with FF61 that I discovered yesterday (30/08/2019). All my passwords were completely wiped after an innocent procedure in Windows 7 due to this "privacy.sanitize.migrateClearSavedPwdsOnExitflag" being added to about:config and set to "True" somehow.

Shall I open a new bug report or just put basic details here?

Comment 81

[Rob N]

(In reply to Rob N from comment #80)

"privacy.sanitize.migrateClearSavedPwdsOnExitflag" being added to about:config and set to "True" somehow.

Oops. I meant that to say "privacy.sanitize.migrateClearSavedPwdsOnExit" not "privacy.sanitize.migrateClearSavedPwdsOnExitflag"

Comment 82

[Matthew N. [:MattN]]

(In reply to Rob N from comment #80)

Hi folks.
I don't know how PRECISELY, but there is still some kind of issue with FF61 that I discovered yesterday (30/08/2019). All my passwords were completely wiped after an innocent procedure in Windows 7 due to this "privacy.sanitize.migrateClearSavedPwdsOnExitflag" being added to about:config and set to "True" somehow.

Shall I open a new bug report or just put basic details here?

Please file a new bug since this one is already resolved. Explain what you did and what happened, especially why you think this preference has anything to do with your issue.