![Firefox logo](https://assets-prod.sumo.prod.webservices.mozgcp.net/media/uploads/products/2020-04-14-08-36-13-8dda6f.png)
signon.useDOMFormHasPassword no longer working with FF 30
Seems that the "signon.useDOMFormHasPassword" workaround (latest working version is FF 29.0.1) to automatically populate username/password fields protected by "autocomplete=off" no longer works with FF 30. Now with FF 30 I always have to double click each of those "protected" username input field to select the only one entry to automatically populate the corresponding password input field. This is pretty annoying as there is only ONE username to select (which should be auto filled). Why did you disable the above workaround? Is there an other way to re-enable username/password autofill for autocomplete=off protected input fields?
I already tried the following parameters, but nothing changed:
signon.autofillForms;true signon.overrideAutocomplete;true
Todas as respostas (20)
Firefox 30 doesn't use the signon.overrideAutocomplete pref as that pref has been renamed to signon.storeWhenAutocompleteOff and is now true by default, so the presence of autocomplete=off for a log in form no longer disables the Password Manager from asking to store the name and password.
I assume that autocomplete="off" will still prevent Firefox from filling the name/password like before, so you will have to double-click the name field and select the name and password from the drop-down list. The signon.autofillForms pref doesn't have effect when autocomplete="off" is present.
Yes, sorry I posted this question from FF 29.0.1 where it is still named "signon.overrideAutocomplete".
> I assume that autocomplete="off" will still prevent Firefox from filling the name/password like before
Yes, previous to FF 30 my greasmonkey script and the "signon.useDOMFormHasPassword" workaround seemed to enable FF to autofill the password field. So there is no option to enable this again? I don't understand why this workaround was disabled, it is very annoying to always double click the username field. I will need to stick with FF 29.0.1 until this is solved (and finally check Chrome as an alternative...).
- bug 999354 - Changes to password manager breaks 'autocomplete="off"' greasemonkey scripts (RESOLVED WONTFIX)
Please do not comment in bug reports
https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
Modificado por cor-el a
I came across this bug already and it describes exactly my issue. Previous to FF 30 the combination of the greasmonkey script AND the signon.useDOMFormHasPassword pref enabled the autofill of password fields. Now that the signon.useDOMFormHasPassword pref is gone in FF 30 this no longer works. I don't think it can be solved by updating the greasmonkey script, the bug explains the reason why:
I'v tried moving the GreaseMonkey script to run as early as I can using "@run-at document-start" and a DOMContentLoaded eventListener on the document but it still runs too late, by the time it runs the new Password Manager has already seen the page content.
So it seems that the workaround was removed in FF 30 without providing a fix for the issue. Again my problem is not about saving passwords on autocomplete=off fields (this is working fine) but on loading them back into this fields without the need to double click the username field and select the single entry.
Ok, did some more tests with disabled greasmonkey script. Seems I was too quick and the signon.useDOMFormHasPassword pref was doing nothing already in FF 29.0.1 (same for the greasmonkey script)... So I checked signon.overrideAutocomplete pref and after swithing it to false the passwords were no longer autofilled. Switching back to true again and autofill works - so this is the real workaround for FF 29.0.1! Now the funny thing is, this pref was renamed in FF 30 to signon.storeWhenAutocompleteOff but it does no longer enable FF 30 to autofill passwords.... Any solution for this?
I don't think that there is a solution possible because you can see from the bug report that the Password Manager runs before the GreaseMonkey script, so it won't be possible for that GM script to modify the page and let the PW manager act upon this. You would need proxy software (e.g. Privoxy) that modifies the page source before it reaches Firefox.
- Bug 946549 - Remove dead code obsoleted by bug 355063 to fill passwords on load
Modificado por cor-el a
Forget about the Greasmonkey script, it does not do anything actually (sorry for that, it is my mistake) - same for signon.useDOMFormHasPassword pref (maybe it fixed the issue before signon.overrideAutocomplete was introduced). As stated in my previous post the signon.overrideAutocomplete pref enabled FF 29 to autofill forms. This pref was renamed to signon.storeWhenAutocompleteOff in FF 30 but it does no longer enable FF 30 to autofill passwords. So it is not an issue with greasmonkey scripts, in my opinion it is a FF 30 bug.
having this same problem. the pref is no longer autocompleting passwords on sites that have autocomplete set to "off". those sites worked fine before upgrading to v30 but now no longer work.
as Thubb states "this pref was renamed in FF 30 to signon.storeWhenAutocompleteOff but it does no longer enable FF 30 to autofill passwords". so this pref no longer seems to have any effect on autocompleting passwords. it must be a bug indeed.
Modificado por shape5 a
I think the point of the original bug 956906 was two pronged
- Allow the password manager to be used even if the site misused autocomplete=off
- But Retain security by making sure a real user is present.
If passwords autocompleted on loading sites that opens up the possibility of automated and scripting attacks that could easily gain access to passwords.
A comment in the bug sumarising it says:
(Bug 956906 - ignore autocomplete="off" when offering to save passwords via the password manager #c100)
- This change makes it so that `autocomplete=off` does not stop the Password Manager from working. Normal form autofill can be disabled as usual. - The password manager *always* prompts if it wants to save a password. Passwords are not saved without permission from the user. - We are the third browser to implement this change, after IE and Chrome. - This can be undone locally by flipping the `signon.storeWhenAutocompleteOff` pref (from about:config) off. - The rationale behind this change was the widespread abuse of the `autocomplete` attribute to prevent password saving where no prevention is required. This change gives users full control over password saving, without compromising on security (again, the user is always prompted).
Interesting test case bug35506 attachment 694735 & detail. Note as example demo makes use of this.
But until FF 30, passwords did autocomplete upon site loading by setting the about:config signon.overrideAutocomplete pref to true. and they still do, but not sites that have autocomplete set to off.
saving passwords has not given me any issues. it's only been with filling them in upon page load. as far as level of security, this should be a user choice, which is how it worked before with signon.overrideAutocomplete.
Exactly, now signon.overrideAutocomplete does no longer exist and the signon.storeWhenAutocompleteOff pref set to true does not autofill input fields protected by autocomplete=off.
So what can we do here? Create a bug report in bugzilla?
The only solution I've found is to go back to the good old times of: unzipping the omni.ja file, editing modules/LoginManagerContent.jsm, adding a 'return false;' at the beginning of the _isAutoCompleteDisabled function, and zipping the omni.ja file again.
I'm not sure about the security implications of this change, but I was using it for years without any problem before the signon.useDOMFormHasPassword, signon.overrideAutocomplete or signon.storeWhenAutocompleteOff stuff appeared.
I will tag the question as escalate. Staff from HelpDesk or one of the Admins may comment to clarify the situation.
Thank you melendro for the hint, but actually this does not/no longer work with FF 30...
It seems you have to additionally replace jsloader\resource\gre\modules\LoginManagerContent.jsm in omni.ja with the one from FF 29. After that password autofill is working again!!
Anyway, I think this is a bug and should be fixed.
Changing the _isAutoCompleteDisabled function for returning always false does work, but on some sites the form is not filled until you click on the login field. If you don't hack this function, the form is never filled even if you click on the field. I think this is caused by the change in the moment the password manager is run.
But yes, I agree that this a bug that should be fixed. Not sure that everybody will think the same.
By the way, I cannot find the file you mention (jsloader\resource\gre\modules\LoginManagerContent.jsm) in omni.ja. Maybe it is because you're using the windows version (I guess because of the backslashes) and I'm using Linux version.
Yes I am on Windows and no it does not work for me when modifying modules/LoginManagerContent.jsm only. I did several tests to confirm it and it only works here with modified modules/LoginManagerContent.jsm AND jsloader\resource\gre\modules\LoginManagerContent.jsm from FF 29. The latter one is not a simple text file but a kind of binary file (maybe compiled JS?) so I dunno why it is necessary to replace this file to make autofill work again. Anyway, for now I can upgrade to FF 30 with this workaround, let's see how next versions behave.
Btw this also works on Macs (OS X), here also both files must be modifed/replaced.
Still not working with FF 31....