User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/601.4.4 (KHTML, like Gecko) Version/9.0.3 Safari/601.4.4 Steps to reproduce: Configured firefox to clear Forms and Search Data on exit. This is on OS X 10.10.5 Actual results: The data was not cleared Expected results: The data should have been cleared. Clearing using the history menu does work, only the automatic clearing on exit is failing. This appears to be regression in Firefox 44. I hadn't noticed it failing on previous versions and it's certainly been working recently for me before upgrading to 44

WFM Could you test with a fresh profile, please. https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles

Doing some more testing in and entirely fresh profile in an entirely fresh user account if it clears form data is associated with if firefox is configured to *also* clear cookies on exit. If the cookies check box is ticked then the form data also gets cleared, if it is clear then the form data is not cleared. I was using http://www.w3schools.com/html/tryit.asp?filename=tryhtml_form_submit as a test vector.

Still WFM with FF45, in both situations with cookies cleared or not.

I've tried it on 45a2 under OS X downloaded from https://ftp.mozilla.org/pub/firefox/nightly/latest-mozilla-aurora/firefox-45.0a2.en-US.mac.dmg and that's worse. There it doesn't matter if the cookie box is ticked or not it fails to clear in either case. I've also tried it on release Firefox 44 under Windows 7 SP 1 64 bit OS with 32 bit Firefox again with a completely fresh profile except for making the following changes: - Use Custom Settings For History - Selecting 'Clear history when firefox closes' Again it doesn't work and on this configuration it doesn't seem to matter if the cookie box is ticked or not. Specifically what I am doing is: - Loading http://www.w3schools.com/html/tryit.asp?filename=tryhtml_form_submit - Typing ABCD in the 'First name' field and hitting submit - Hitting 'See Result' to go back to the from - Noting that if I type 'A' in the "First name" field I get a drop down offering to complete it to ABCD - Quit and restart firefox - Loading http://www.w3schools.com/html/tryit.asp?filename=tryhtml_form_submit - Typing A in the 'First name' field. In the failure case I will get a dropdown offering to complete to ABCD. In the working case I won't.

Though I cannot reproduce it with 44.0(20160123151951) and 45.0b1(20160127070712), I can reproduce it with 46.0a2(20160131004012) and 47.0a1(20160131030347) on Windows10. (all x64) Form & Search History(form data, history in searchbar) and Cookies are not cleared on exit. mozregression tells https://hg.mozilla.org/integration/fx-team/pushloghtml?fromchange=c3c230a896320099bc14a1ef4b78e41ecc657b1f&tochange=ea9e749bb86bfb584e8591959ac57278bf43c0e4 in my case...

> Though I cannot reproduce it with 44.0(20160123151951) and > 45.0b1(20160127070712), I can reproduce it with 46.0a2(20160131004012) and > 47.0a1(20160131030347) on Windows10. (all x64) > Form & Search History(form data, history in searchbar) and Cookies are not > cleared on exit. > > mozregression tells > https://hg.mozilla.org/integration/fx-team/ > pushloghtml?fromchange=c3c230a896320099bc14a1ef4b78e41ecc657b1f&tochange=ea9e > 749bb86bfb584e8591959ac57278bf43c0e4 > in my case... Filed Bug 1244650 for the regression.

Any reason this is not a dupe of bug 1244650?

(In reply to Marco Bonardo [::mak] from comment #7) > Any reason this is not a dupe of bug 1244650? Only that the other bug does not recognise that this occurs on the released FireFox 44. From looking at the other bug it's possible that this bug is at least partially timing sensitive which would account for the differing ability of different people to reproduce it on various versions of Firefox and OSes.

Based on my current investigation, the bug goes well over Firefox 44, it is related to when we moved Places shutdown to async shutdown, many versions ago. It's is definitely timing dependent. I think bug 1243549 will remove the worse part, sanitization will happen on startup then, as before. in bug 1244650 I am trying to solve it by fixing the shutdown path (again). Thank you for clarifying.

The interesting thing is many people on Mac OSX have reported this bug.

Any idea if this is still a live issue?

I have no idea, but regardless the code pointed out in this bug is likely changed from 2 years ago. Even if it should still exist, having a new report would be far more useful than keeping this bug open forever without good STR.