* Add autofill values for german websites
* Added commonly used fieldnames for German websites
---------
Co-authored-by: Daniel James Smith <djsmith@web.de>
* SG-1026 - Documenting / slight refactoring of notification-bar - WIP
* SG-1026 - More documentation WIP
* SG-1026 - Continued documentation of notification bar + testing theories for specific sites as part of research to identify areas for possible improvement + added types where appropriate.
* SG-1026 - getSubmitButton docs
* SG-1026 - Autofill Service tweak - On account creation (ex: talkshoe.com), even if the pageDetails contained a valid form to watch, the loadPasswordFields method parameter for fillNewPassword being false for inputs with autoCompleteType of "new-password" would cause the account creation form to not be watched (null form data returned to notification bar). Setting this to true will help capture more account creations in the above specified scenario.
* SG-1026 - Additional documentation / comment clean up
* SG-1026 - Remove unused pageDetails array
* SG-1026 - These changes address form detection issues for the password change form on talkshoe.com: (1) Update autofill.service getFormsWithPasswordFields(...) method to group autofill.js found password type fields under a single form in a very specific scenario where the most likely case is that it is a password change form with poorly designed mark up in a SPA (2) Notification bar - when listening to a form, we must use both the loginButtonNames and the changePasswordButton names as we don't know what type of form we are listening to (3) Notification bar - on page change, we must empty out the watched forms array to prevent forms w/ the same opId being added to the array on SPA url change (4) Notification bar - getSubmitButton update - If we cannot find a submit button within a form, try going up one level to the parent element and searching again (+ added save to changePasswordButtonNames). (5) Notification bar - when listening to a form with a submit button, we can attach the formOpId to the button so we can only have DOM traversal in one location and retrieve the form off the button later on in the form submission logic. For now, I'm just adding it as a fallback, but it could be the primary approach with more testing.
* SG-1026 - On first load of the notification-bar content script, we should start observing the DOM immediately so we properly catch rendered forms instead of waiting for a second. This was especially prevelant on refreshing the password change form page on talkshoe.com.
* SG-1026 - Due to the previous, timeout based nature of the calls to collectPageDetailsIfNeeded (now handlePageChange), the mutation observer could get setup late and miss forms loading (ex: refreshing a password change page on talkshoe.com). DOM observation is now setup as fast as possible on page load for SPAs/Non SPAs and on change for SPAs by having the mutation observer itself detect page change and deterministically calling handlePageChange(). However, with these changes, page detail collection still only occurs after a minimum of ~1 second whether or not it was triggered from the mutation observer detecting forms being injected onto the page or the scheduleHandlePageChange running (which has a theoretical maximum time to page detail collection of ~1.999 seconds but this does require the mutation observer to miss the page change in a SPA which shouldn't happen).
* SG-1026 - Identified issue with current form retrieval step in autofill service which prevents multi-step account creation forms from being returned to the notification-bar content script from the notification.background.ts script.
* SG-1026 - Add logic to formSubmitted to try and successfully process multi-step login form (email then password on https://login.live.com/login.srf) with next button that gets swapped out for a true submit button in order to prompt for saving user credentials if not in Bitwarden. This logic works *sometimes* as the submit button page change often stops the submit button event listeners from being able to fire and send the login to the background script. However, that is a separate issue to be solved, and sometimes is better than never. This type of logic might be useful in solving the multi-step account creation form on https://signup.live.com/signup but that will require additional changes to the autofill service which current intercepts forms without passwords and prevents them from reaching the notification-bar.ts content script.
* SG-1026 - Add note explaining the persistence of the content script
* SG-1026 - Update stack overflow link to improve clarity.
---------
Co-authored-by: Robyn MacCallum <robyntmaccallum@gmail.com>
* Move URI matching logic into uriView
* Fix url parsing: always assign default protocol, otherwise no protocol with port is parsed incorrectly
* Codescene: refactor domain matching logic
* add settingsService.getEquivalentDomains
* check that an iframe URL matches cipher.login.uris before autofilling
* disable autofill on page load if it doesn't match
* show a warning to the user on regular autofill if it doesn't match
---------
Co-authored-by: Todd Martin <106564991+trmartin4@users.noreply.github.com>
Co-authored-by: Robyn MacCallum <robyntmaccallum@gmail.com>
* Move autofillConstants to autofill folder
* Remove autofillConstants from whitelist capital
* Add vault team as code owners for autofill folder
* Update codeowners for web
Cesar Gonzalez
David Gleich
Jared Snider
Thomas Rittson
Vincent Salucci
Robyn MacCallum