Flip pref in test_basic_form_autocomplete.html to allow eval() temporarily.
Differential Revision: https://phabricator.services.mozilla.com/D30016
--HG--
extra : moz-landing-system : lando
This patch was intended to fix behavior observed on us.hsbc.com, where the username was being replaced with a single 'x', but that is now being tracked in bug 1546749.
--HG--
extra : amend_source : a8eaeefe4a91c5fcd6210537edd4a8a499158c79
In certain straight-forward cases where we detect a credit card number being used with password fields we will show a dismissed password manager doorhanger. The user can still choose to save in case the valid credit card number is actually their username or password.
1) If the Luhn checksum matches on the username field (see CreditCard.jsm) AND the password is 3 numerical digits (don't handle 4 for now even though it's used by Visa since there are banks that use 4 digits passwords for online banking still).
2) If the Luhn checksum matches on the password value AND we detect that the type=password field is a credit card field via autocomplete=cc-number.
** We must include the @autocomplete check otherwise sites will abuse this loophole on legit login forms and set autocomplete=cc-number on their password fields to avoid saving.
For both of these cases we should `dismissed:true` doorhanger, rather than not showing one at all, in case there are false-negatives.
Differential Revision: https://phabricator.services.mozilla.com/D25485
--HG--
extra : source : e9be442c871e173a409f3b969f5bcea0e1ae4d71
extra : histedit_source : c942a81512be954abe595fa41ca44c26cd89b0e6
In certain straight-forward cases where we detect a credit card number being used with password fields we will show a dismissed password manager doorhanger. The user can still choose to save in case the valid credit card number is actually their username or password.
1) If the Luhn checksum matches on the username field (see CreditCard.jsm) AND the password is 3 numerical digits (don't handle 4 for now even though it's used by Visa since there are banks that use 4 digits passwords for online banking still).
2) If the Luhn checksum matches on the password value AND we detect that the type=password field is a credit card field via autocomplete=cc-number.
** We must include the @autocomplete check otherwise sites will abuse this loophole on legit login forms and set autocomplete=cc-number on their password fields to avoid saving.
For both of these cases we should `dismissed:true` doorhanger, rather than not showing one at all, in case there are false-negatives.
Differential Revision: https://phabricator.services.mozilla.com/D25485
--HG--
extra : transplant_source : %A9%94_%9A%03%00%A1u%F3%28%C6%00H%16z%8A%8F%D6%18O
This excludes dom/, otherwise the file size is too large for phabricator to handle.
This is an autogenerated commit to handle scripts loading mochitest harness files, in
the simple case where the script src is on the same line as the tag.
This was generated with https://bug1544322.bmoattachments.org/attachment.cgi?id=9058170
using the `--part 2` argument.
Differential Revision: https://phabricator.services.mozilla.com/D27456
--HG--
extra : moz-landing-system : lando
* Use Services.(ppmm|cpmm).sharedData to make isMasterPasswordSet value available to the content process
* We don't handle runtime enable/disable of MP
Differential Revision: https://phabricator.services.mozilla.com/D26939
--HG--
extra : moz-landing-system : lando
Password manager should not offer to save credit card numbers in certain straight-forward cases.
Differential Revision: https://phabricator.services.mozilla.com/D25485
--HG--
extra : moz-landing-system : lando
* Use Services.(ppmm|cpmm).sharedData to make isMasterPasswordSet value available to the content process
* We don't handle runtime enable/disable of MP
Differential Revision: https://phabricator.services.mozilla.com/D26939
--HG--
extra : moz-landing-system : lando
Some sites use `email`, `tel` and `tel-national` values for @autocomplete even when they are used as the username and 'username' would be more appropriate.
We already allowed type=email / type=tel so allowing the autocomplete equivalents is reasonable.
Differential Revision: https://phabricator.services.mozilla.com/D25883
--HG--
extra : moz-landing-system : lando
This login should not show up in tests that don't expect it once we allow non-matching formSubmitURLs.
Differential Revision: https://phabricator.services.mozilla.com/D23443
--HG--
extra : moz-landing-system : lando
Normally autocomplete results are cached based upon the search string but to get the desired behaviour we want two different sets of results for the same search string depending on how the autocomplete search was started:
a) Via automatically focusing a password field.
b) Every other method of starting an autocomplete search.
In order to not have cached results used, the result code for case (a) [an empty result] will be `RESULT_FAILURE` and I've updated the autocomplete code to not re-use an error result.
In the coming months we may be rewriting our content autocomplete code but that would be too risky to uplift to 67 so for now I'm tracking when satchel automatically opens the popup upon focus and then using that state in the autocomplete result creation code to know whether to include the footer.
Differential Revision: https://phabricator.services.mozilla.com/D25173
--HG--
extra : moz-landing-system : lando
This login should not show up in tests that don't expect it once we allow non-matching formSubmitURLs.
Differential Revision: https://phabricator.services.mozilla.com/D23443
--HG--
extra : moz-landing-system : lando
This login should not show up in tests that don't expect it once we allow non-matching formSubmitURLs.
Differential Revision: https://phabricator.services.mozilla.com/D23443
--HG--
extra : moz-landing-system : lando