2023-01-31 22:08:37 +01:00
|
|
|
import AddLoginRuntimeMessage from "../../background/models/addLoginRuntimeMessage";
|
|
|
|
import ChangePasswordRuntimeMessage from "../../background/models/changePasswordRuntimeMessage";
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
import AutofillField from "../models/autofill-field";
|
|
|
|
import { WatchedForm } from "../models/watched-form";
|
|
|
|
import { FormData } from "../services/abstractions/autofill.service";
|
|
|
|
|
|
|
|
interface HTMLElementWithFormOpId extends HTMLElement {
|
|
|
|
formOpId: string;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @fileoverview This file contains the code for the Bitwarden Notification Bar content script.
|
|
|
|
* The notification bar is used to notify logged in users that they can
|
|
|
|
* save a new login, change a existing password on a password change screen,
|
|
|
|
* or update an existing login after detecting a different password on login.
|
|
|
|
*
|
|
|
|
* Note: content scripts are reloaded on non-SPA page change.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Run content script when the DOM is fully loaded
|
|
|
|
*
|
|
|
|
* The DOMContentLoaded event fires when the HTML document has been completely parsed,
|
|
|
|
* and all deferred scripts (<script defer src="…"> and <script type="module">) have
|
|
|
|
* downloaded and executed. It doesn't wait for other things like images, subframes,
|
|
|
|
* and async scripts to finish loading.
|
|
|
|
* https://developer.mozilla.org/en-US/docs/Web/API/Window/DOMContentLoaded_event
|
|
|
|
*/
|
2021-02-10 16:40:15 +01:00
|
|
|
document.addEventListener("DOMContentLoaded", (event) => {
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
// Do not show the notification bar on the Bitwarden vault
|
|
|
|
// because they can add logins and change passwords there
|
2022-02-14 02:33:58 +01:00
|
|
|
if (window.location.hostname.endsWith("vault.bitwarden.com")) {
|
2021-12-21 15:43:35 +01:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
// Initialize required variables and set default values
|
|
|
|
const watchedForms: WatchedForm[] = [];
|
2018-05-09 20:00:13 +02:00
|
|
|
let barType: string = null;
|
|
|
|
let pageHref: string = null;
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
|
|
|
|
// Provides the ability to watch for changes being made to the DOM tree.
|
2018-05-09 20:00:13 +02:00
|
|
|
let observer: MutationObserver = null;
|
2018-05-11 20:50:44 +02:00
|
|
|
const observeIgnoredElements = new Set([
|
2021-12-21 15:43:35 +01:00
|
|
|
"a",
|
|
|
|
"i",
|
|
|
|
"b",
|
|
|
|
"strong",
|
|
|
|
"span",
|
|
|
|
"code",
|
|
|
|
"br",
|
|
|
|
"img",
|
|
|
|
"small",
|
|
|
|
"em",
|
|
|
|
"hr",
|
|
|
|
]);
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
let domObservationCollectTimeoutId: number = null;
|
|
|
|
let collectPageDetailsTimeoutId: number = null;
|
|
|
|
let handlePageChangeTimeoutId: number = null;
|
|
|
|
|
2018-05-09 20:00:13 +02:00
|
|
|
const inIframe = isInIframe();
|
2018-08-01 18:25:05 +02:00
|
|
|
const cancelButtonNames = new Set(["cancel", "close", "back"]);
|
|
|
|
const logInButtonNames = new Set([
|
2021-12-21 15:43:35 +01:00
|
|
|
"log in",
|
|
|
|
"sign in",
|
|
|
|
"login",
|
|
|
|
"go",
|
|
|
|
"submit",
|
|
|
|
"continue",
|
|
|
|
"next",
|
|
|
|
]);
|
2018-08-01 18:25:05 +02:00
|
|
|
const changePasswordButtonNames = new Set([
|
|
|
|
"save password",
|
|
|
|
"update password",
|
|
|
|
"change password",
|
2021-12-21 15:43:35 +01:00
|
|
|
"change",
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
"save",
|
2021-12-21 15:43:35 +01:00
|
|
|
]);
|
2018-08-01 18:25:05 +02:00
|
|
|
const changePasswordButtonContainsNames = new Set(["pass", "change", "contras", "senha"]);
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
|
|
|
|
// These are preferences for whether to show the notification bar based on the user's settings
|
|
|
|
// and they are set in the Settings > Options page in the browser extension.
|
2018-08-01 05:48:11 +02:00
|
|
|
let disabledAddLoginNotification = false;
|
|
|
|
let disabledChangedPasswordNotification = false;
|
2021-12-21 15:43:35 +01:00
|
|
|
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
// Look up the active user id from storage
|
2022-02-07 11:31:18 +01:00
|
|
|
const activeUserIdKey = "activeUserId";
|
|
|
|
let activeUserId: string;
|
|
|
|
chrome.storage.local.get(activeUserIdKey, (obj: any) => {
|
|
|
|
if (obj == null || obj[activeUserIdKey] == null) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
activeUserId = obj[activeUserIdKey];
|
|
|
|
});
|
|
|
|
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
// Look up the user's settings from storage
|
2022-02-07 11:31:18 +01:00
|
|
|
chrome.storage.local.get(activeUserId, (obj: any) => {
|
2022-02-15 16:11:44 +01:00
|
|
|
if (obj?.[activeUserId] == null) {
|
2022-02-07 11:31:18 +01:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
const userSettings = obj[activeUserId].settings;
|
|
|
|
|
|
|
|
// NeverDomains is a dictionary of domains that the user has chosen to never
|
|
|
|
// show the notification bar on (for login detail collection or password change).
|
|
|
|
// It is managed in the Settings > Excluded Domains page in the browser extension.
|
|
|
|
// Example: '{"bitwarden.com":null}'
|
|
|
|
const excludedDomainsDict = userSettings.neverDomains;
|
|
|
|
|
|
|
|
if (
|
|
|
|
excludedDomainsDict != null &&
|
|
|
|
// eslint-disable-next-line
|
|
|
|
excludedDomainsDict.hasOwnProperty(window.location.hostname)
|
|
|
|
) {
|
2018-05-09 20:00:13 +02:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
// Set local disabled preferences
|
|
|
|
disabledAddLoginNotification = userSettings.disableAddLoginNotification;
|
|
|
|
disabledChangedPasswordNotification = userSettings.disableChangedPasswordNotification;
|
2022-02-07 11:31:18 +01:00
|
|
|
|
|
|
|
if (!disabledAddLoginNotification || !disabledChangedPasswordNotification) {
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
// If the user has not disabled both notifications, then handle the initial page change (null -> actual page)
|
|
|
|
handlePageChange();
|
2022-02-07 11:31:18 +01:00
|
|
|
}
|
2021-12-21 15:43:35 +01:00
|
|
|
});
|
2018-05-09 20:00:13 +02:00
|
|
|
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
//#region Message Processing
|
|
|
|
|
|
|
|
// Listen for messages from the background script
|
|
|
|
// Note: onMessage events are fired when a message is sent from either an extension process
|
|
|
|
// (by runtime.sendMessage) or a content script (by tabs.sendMessage).
|
|
|
|
// https://developer.chrome.com/docs/extensions/reference/runtime/#event-onMessage
|
2022-02-24 18:14:04 +01:00
|
|
|
chrome.runtime.onMessage.addListener((msg, sender, sendResponse) => {
|
2018-05-09 20:00:13 +02:00
|
|
|
processMessages(msg, sendResponse);
|
|
|
|
});
|
|
|
|
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
/**
|
|
|
|
* Processes messages received from the background script via the `chrome.runtime.onMessage` event.
|
|
|
|
* @param {Object} msg - The received message.
|
|
|
|
* @param {Function} sendResponse - The function used to send a response back to the background script.
|
|
|
|
* @returns {boolean} - Returns `true` if a response was sent, `false` otherwise.
|
|
|
|
*/
|
2022-02-24 18:14:04 +01:00
|
|
|
function processMessages(msg: any, sendResponse: (response?: any) => void) {
|
2018-05-09 20:00:13 +02:00
|
|
|
if (msg.command === "openNotificationBar") {
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
// `notification.background.ts : doNotificationQueueCheck(...)` sends
|
|
|
|
// a message to the content script to open the notification bar
|
|
|
|
// on Login Add or Password Change
|
2018-05-09 20:00:13 +02:00
|
|
|
if (inIframe) {
|
|
|
|
return;
|
|
|
|
}
|
2018-05-11 20:50:44 +02:00
|
|
|
closeExistingAndOpenBar(msg.data.type, msg.data.typeData);
|
|
|
|
sendResponse();
|
|
|
|
return true;
|
2018-05-09 20:00:13 +02:00
|
|
|
} else if (msg.command === "closeNotificationBar") {
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
// The following methods send a message to the content script to close the notification bar:
|
|
|
|
// `bar.js : closeButton click` > `notification.background.ts : processMessage(...)`
|
|
|
|
// `notification.background.ts : saveNever(...)`
|
|
|
|
// `notification.background.ts : saveOrUpdateCredentials(...)`
|
2018-05-09 20:00:13 +02:00
|
|
|
if (inIframe) {
|
|
|
|
return;
|
2021-12-21 15:43:35 +01:00
|
|
|
}
|
2018-05-09 20:00:13 +02:00
|
|
|
closeBar(true);
|
|
|
|
sendResponse();
|
|
|
|
return true;
|
2018-05-11 20:50:44 +02:00
|
|
|
} else if (msg.command === "adjustNotificationBar") {
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
// `bar.js : window resize` > `notification.background.ts : processMessage(...)`
|
|
|
|
// sends a message to the content script to adjust the notification bar
|
2018-05-11 20:50:44 +02:00
|
|
|
if (inIframe) {
|
2018-05-09 20:00:13 +02:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
adjustBar(msg.data);
|
|
|
|
sendResponse();
|
|
|
|
return true;
|
|
|
|
} else if (msg.command === "notificationBarPageDetails") {
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
// Note: we deliberately do not check for inIframe here because a lot of websites
|
|
|
|
// embed their login forms into iframes
|
|
|
|
// Ex: icloud.com uses a login form in an iframe from apple.com
|
|
|
|
|
|
|
|
// See method collectPageDetails() for full call itinerary that leads to this message
|
2018-05-09 20:00:13 +02:00
|
|
|
watchForms(msg.data.forms);
|
|
|
|
sendResponse();
|
|
|
|
return true;
|
|
|
|
}
|
2021-12-21 15:43:35 +01:00
|
|
|
}
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
//#endregion Message Processing
|
2018-05-09 20:00:13 +02:00
|
|
|
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
/**
|
|
|
|
* Observe the DOM for changes and collect page details if forms are added to the page
|
|
|
|
*/
|
2018-05-09 20:00:13 +02:00
|
|
|
function observeDom() {
|
|
|
|
const bodies = document.querySelectorAll("body");
|
|
|
|
if (bodies && bodies.length > 0) {
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
observer = new MutationObserver((mutations: MutationRecord[]) => {
|
|
|
|
// If mutation observer detects a change in the page URL, collect page details
|
|
|
|
// which will reset the observer and start watching for new forms on the new page
|
|
|
|
if (pageHref !== window.location.href) {
|
|
|
|
handlePageChange();
|
2021-12-21 15:43:35 +01:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
// If mutations are not found, return
|
|
|
|
if (mutations == null || mutations.length === 0) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
let doCollectPageDetails = false;
|
|
|
|
|
2018-05-09 20:00:13 +02:00
|
|
|
for (let i = 0; i < mutations.length; i++) {
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
const mutation: MutationRecord = mutations[i];
|
|
|
|
|
|
|
|
// If there are no added nodes, continue to next mutation
|
2018-05-09 20:00:13 +02:00
|
|
|
if (mutation.addedNodes == null || mutation.addedNodes.length === 0) {
|
|
|
|
continue;
|
2021-12-21 15:43:35 +01:00
|
|
|
}
|
|
|
|
|
2018-05-09 20:00:13 +02:00
|
|
|
for (let j = 0; j < mutation.addedNodes.length; j++) {
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
// https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement
|
2018-05-09 20:00:13 +02:00
|
|
|
const addedNode: any = mutation.addedNodes[j];
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
|
|
|
|
// If the added node is null, continue to next added node
|
2018-05-09 20:00:13 +02:00
|
|
|
if (addedNode == null) {
|
|
|
|
continue;
|
2021-12-21 15:43:35 +01:00
|
|
|
}
|
2018-05-09 20:00:13 +02:00
|
|
|
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
// Get the lowercase tag name of the added node (if it exists)
|
2018-05-09 20:00:13 +02:00
|
|
|
const tagName = addedNode.tagName != null ? addedNode.tagName.toLowerCase() : null;
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
|
|
|
|
// If tag name exists & is a form &
|
|
|
|
// (either the dataset is null or it does not have the custom data attribute: "data-bitwarden-watching"),
|
|
|
|
// then collect page details and break
|
|
|
|
// Note: The dataset read-only property of the HTMLElement interface provides
|
|
|
|
// read/write access to custom data attributes (data-*) on elements
|
|
|
|
// https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/dataset
|
2018-05-09 20:00:13 +02:00
|
|
|
if (
|
|
|
|
tagName != null &&
|
2018-05-11 20:50:44 +02:00
|
|
|
tagName === "form" &&
|
2018-05-09 20:00:13 +02:00
|
|
|
(addedNode.dataset == null || !addedNode.dataset.bitwardenWatching)
|
|
|
|
) {
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
doCollectPageDetails = true;
|
2018-05-09 20:00:13 +02:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
// If tag name exists & is in the observeIgnoredElements set
|
|
|
|
// or if the added node does not have the querySelectorAll method, continue to next added node
|
|
|
|
// Note: querySelectorAll(...) exists on the Element & Document interfaces
|
|
|
|
// It doesn't exist for nodes that are not elements, such as text nodes
|
|
|
|
// Text Node examples: https://developer.mozilla.org/en-US/docs/Web/API/Node/nodeName#example
|
2021-12-21 15:43:35 +01:00
|
|
|
if (
|
2018-05-11 20:50:44 +02:00
|
|
|
(tagName != null && observeIgnoredElements.has(tagName)) ||
|
2018-05-09 20:00:13 +02:00
|
|
|
addedNode.querySelectorAll == null
|
2021-12-21 15:43:35 +01:00
|
|
|
) {
|
2018-05-09 20:00:13 +02:00
|
|
|
continue;
|
2021-12-21 15:43:35 +01:00
|
|
|
}
|
2018-05-09 20:00:13 +02:00
|
|
|
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
// If the added node has any descendent form elements that are not yet being watched, collect page details and break
|
2018-05-09 20:00:13 +02:00
|
|
|
const forms = addedNode.querySelectorAll("form:not([data-bitwarden-watching])");
|
|
|
|
if (forms != null && forms.length > 0) {
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
doCollectPageDetails = true;
|
2018-05-09 20:00:13 +02:00
|
|
|
break;
|
|
|
|
}
|
2021-12-21 15:43:35 +01:00
|
|
|
}
|
|
|
|
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
if (doCollectPageDetails) {
|
2018-05-09 20:00:13 +02:00
|
|
|
break;
|
2021-12-21 15:43:35 +01:00
|
|
|
}
|
2018-05-09 20:00:13 +02:00
|
|
|
}
|
|
|
|
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
// If page details need to be collected, clear any existing timeout and schedule a new one
|
|
|
|
if (doCollectPageDetails) {
|
|
|
|
if (domObservationCollectTimeoutId != null) {
|
|
|
|
window.clearTimeout(domObservationCollectTimeoutId);
|
|
|
|
domObservationCollectTimeoutId = null;
|
2021-12-21 15:43:35 +01:00
|
|
|
}
|
|
|
|
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
// The timeout is used to avoid collecting page details too often on page mutation while also
|
|
|
|
// giving the DOM time to settle down after a change (ex: multi-part forms being rendered)
|
|
|
|
domObservationCollectTimeoutId = window.setTimeout(collectPageDetails, 1000);
|
2018-05-09 20:00:13 +02:00
|
|
|
}
|
|
|
|
});
|
|
|
|
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
// Watch all mutations to the body element and all of its children & descendants
|
2018-05-09 20:00:13 +02:00
|
|
|
observer.observe(bodies[0], { childList: true, subtree: true });
|
|
|
|
}
|
2021-12-21 15:43:35 +01:00
|
|
|
}
|
2018-05-09 20:00:13 +02:00
|
|
|
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
/**
|
|
|
|
* Handles initial page load and page changes
|
|
|
|
* 3 ways this method is called:
|
|
|
|
*
|
|
|
|
* (1) On initial content script load
|
|
|
|
*
|
|
|
|
* (2) On page change (detected by observer)
|
|
|
|
*
|
|
|
|
* (3) On after scheduled delay setup in `scheduleHandlePageChange()
|
|
|
|
*
|
|
|
|
* On page change, we update the page href, empty the watched forms array, call collectPageDetails (w/ 1 second timeout), and reset the observer
|
|
|
|
*/
|
|
|
|
function handlePageChange() {
|
|
|
|
// On first load the content script or any time the page changes, we need to collect the page details and setup the mutation observer
|
2018-05-09 20:00:13 +02:00
|
|
|
if (pageHref !== window.location.href) {
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
// update href
|
2018-05-09 20:00:13 +02:00
|
|
|
pageHref = window.location.href;
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
|
|
|
|
// Empty watched forms so it doesn't carry over between SPA page changes
|
|
|
|
// This allows formOpIds to be unique for each page so that we can
|
|
|
|
// associate submit buttons with their respective forms in the getSubmitButton logic.
|
|
|
|
watchedForms.length = 0;
|
|
|
|
|
|
|
|
// collect the page details after a timeout
|
|
|
|
// The timeout is used to allow more time for the page to load before collecting the page details
|
|
|
|
// as there are some cases where SPAs do not load the entire page on initial load, so we need to wait
|
|
|
|
if (collectPageDetailsTimeoutId != null) {
|
|
|
|
window.clearTimeout(collectPageDetailsTimeoutId);
|
|
|
|
collectPageDetailsTimeoutId = null;
|
|
|
|
}
|
|
|
|
collectPageDetailsTimeoutId = window.setTimeout(collectPageDetails, 1000);
|
|
|
|
|
2018-05-09 20:00:13 +02:00
|
|
|
if (observer) {
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
// reset existing DOM mutation observer so it can listen for changes to the new page body
|
2018-05-09 20:00:13 +02:00
|
|
|
observer.disconnect();
|
|
|
|
observer = null;
|
2021-12-21 15:43:35 +01:00
|
|
|
}
|
|
|
|
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
// On first load or page change, start observing the DOM as early as possible
|
|
|
|
// to avoid missing any forms that are added after the page loads
|
|
|
|
observeDom();
|
2021-12-21 15:43:35 +01:00
|
|
|
}
|
2018-05-09 20:00:13 +02:00
|
|
|
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
// This is a safeguard in case the observer misses a SPA page change.
|
|
|
|
scheduleHandlePageChange();
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Set up a timeout to call handlePageChange after 1 second
|
|
|
|
*/
|
|
|
|
function scheduleHandlePageChange() {
|
|
|
|
// Check again in 1 second (but clear any existing timeout first)
|
|
|
|
if (handlePageChangeTimeoutId != null) {
|
|
|
|
window.clearTimeout(handlePageChangeTimeoutId);
|
|
|
|
handlePageChangeTimeoutId = null;
|
2021-12-21 15:43:35 +01:00
|
|
|
}
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
handlePageChangeTimeoutId = window.setTimeout(handlePageChange, 1000);
|
2018-05-09 20:00:13 +02:00
|
|
|
}
|
|
|
|
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
/** *
|
|
|
|
* Tell the background script to collect the page details.
|
|
|
|
*
|
|
|
|
* (1) Sends a message with command `bgCollectPageDetails` to `runtime.background.ts : processMessage(...)`
|
|
|
|
*
|
|
|
|
* (2) `runtime.background.ts : processMessage(...)` calls
|
|
|
|
* `main.background.ts : collectPageDetailsForContentScript`
|
|
|
|
*
|
|
|
|
* (3) `main.background.ts : collectPageDetailsForContentScript`
|
|
|
|
* sends a message with command `collectPageDetails` to the `autofill.js` content script
|
|
|
|
*
|
|
|
|
* (4) `autofill.js` content script runs a `collect(document)` method.
|
|
|
|
* The result is sent via message with command `collectPageDetailsResponse` to `notification.background.ts : processMessage(...)`
|
|
|
|
*
|
|
|
|
* (5) `notification.background.ts : processMessage(...)` gathers forms with password fields and passes them and the page details
|
|
|
|
* via message with command `notificationBarPageDetails` back to the `processMessages` method in this content script.
|
|
|
|
*
|
|
|
|
* */
|
|
|
|
function collectPageDetails() {
|
2018-05-09 20:00:13 +02:00
|
|
|
sendPlatformMessage({
|
|
|
|
command: "bgCollectPageDetails",
|
|
|
|
sender: "notificationBar",
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
//#endregion Page Detail Collection Methods
|
|
|
|
|
|
|
|
// #region Form Detection and Submission Handling
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Iterates through the given array of forms and adds an event listener to each form.
|
|
|
|
* The purpose of the event listener is to detect changes in form data and store the changes.
|
|
|
|
*
|
|
|
|
* Note: The forms were gathered in the `notification.background.ts : processMessage(...)`
|
|
|
|
* method with command `collectPageDetailsResponse` by the `autofillService.getFormsWithPasswordFields(...)` method
|
|
|
|
* and passed to the `processMessages` method in this content script.
|
|
|
|
*
|
|
|
|
* @param {FormData[]} forms - The array of forms to be watched.
|
|
|
|
*/
|
|
|
|
function watchForms(forms: FormData[]) {
|
|
|
|
// If there are no forms, return
|
2018-05-09 20:00:13 +02:00
|
|
|
if (forms == null || forms.length === 0) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
forms.forEach((f: FormData) => {
|
|
|
|
// Get the form element by id
|
2018-05-09 20:00:13 +02:00
|
|
|
const formId: string = f.form != null ? f.form.htmlID : null;
|
2018-08-01 18:25:05 +02:00
|
|
|
let formEl: HTMLFormElement = null;
|
2018-08-01 05:24:11 +02:00
|
|
|
if (formId != null && formId !== "") {
|
2018-08-01 18:25:05 +02:00
|
|
|
formEl = document.getElementById(formId) as HTMLFormElement;
|
2021-12-21 15:43:35 +01:00
|
|
|
}
|
|
|
|
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
// If the form could not be retrieved by its HTML ID, retrieve it by its index pulled from the opid
|
2018-05-09 20:00:13 +02:00
|
|
|
if (formEl == null) {
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
// opid stands for OnePassword ID - uniquely ID's an element on a page
|
|
|
|
// and is generated in `autofill.js`
|
|
|
|
// Each form has an opid and each element has an opid and its parent form opid
|
2018-05-09 20:00:13 +02:00
|
|
|
const index = parseInt(f.form.opid.split("__")[2], null);
|
|
|
|
formEl = document.getElementsByTagName("form")[index];
|
2021-12-21 15:43:35 +01:00
|
|
|
}
|
|
|
|
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
// If the form element exists and is not yet being watched, start watching it and set it as watched
|
2018-08-01 05:24:11 +02:00
|
|
|
if (formEl != null && formEl.dataset.bitwardenWatching !== "1") {
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
const watchedForm: WatchedForm = {
|
2021-12-21 15:43:35 +01:00
|
|
|
data: f,
|
2018-05-09 20:00:13 +02:00
|
|
|
formEl: formEl,
|
|
|
|
usernameEl: null,
|
|
|
|
passwordEl: null,
|
2018-08-01 05:24:11 +02:00
|
|
|
passwordEls: null,
|
2021-12-21 15:43:35 +01:00
|
|
|
};
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
// Locate the username and password fields
|
|
|
|
locateFields(watchedForm);
|
|
|
|
// Add the form data to the array of watched forms
|
|
|
|
watchedForms.push(watchedForm);
|
|
|
|
// Add an event listener to the form
|
|
|
|
listenToForm(formEl);
|
|
|
|
// Set the form as watched
|
2018-05-09 20:00:13 +02:00
|
|
|
formEl.dataset.bitwardenWatching = "1";
|
2021-12-21 15:43:35 +01:00
|
|
|
}
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
function listenToForm(form: HTMLFormElement) {
|
|
|
|
// Remove any existing event listeners and re-add them
|
|
|
|
// for form submission and submit button click
|
2018-05-09 20:00:13 +02:00
|
|
|
form.removeEventListener("submit", formSubmitted, false);
|
|
|
|
form.addEventListener("submit", formSubmitted, false);
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
|
|
|
|
findAndListenToSubmitButton(form);
|
|
|
|
}
|
|
|
|
|
|
|
|
function findAndListenToSubmitButton(form: HTMLFormElement) {
|
|
|
|
// Use login button names and change password names since we don't
|
|
|
|
// know what type of form we are watching
|
|
|
|
const submitButton = getSubmitButton(
|
|
|
|
form,
|
|
|
|
unionSets(logInButtonNames, changePasswordButtonNames)
|
|
|
|
);
|
|
|
|
|
2018-05-09 20:00:13 +02:00
|
|
|
if (submitButton != null) {
|
|
|
|
submitButton.removeEventListener("click", formSubmitted, false);
|
|
|
|
submitButton.addEventListener("click", formSubmitted, false);
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
|
|
|
|
// Associate the form opid with the submit button so we can find the form on submit.
|
|
|
|
(submitButton as HTMLElementWithFormOpId).formOpId = form.opid;
|
2021-12-21 15:43:35 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
/**
|
|
|
|
* Locate the fields within a form element given form data.
|
|
|
|
* @param {Object} watchedForm - The object containing form data and the form element to search within.
|
|
|
|
*/
|
|
|
|
function locateFields(watchedForm: WatchedForm) {
|
|
|
|
// Get all input elements
|
2018-08-01 05:24:11 +02:00
|
|
|
const inputs = Array.from(document.getElementsByTagName("input"));
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
|
|
|
|
// Locate the username field
|
|
|
|
watchedForm.usernameEl = locateField(watchedForm.formEl, watchedForm.data.username, inputs);
|
|
|
|
|
|
|
|
// if we found a username field, try to locate a single password field
|
|
|
|
if (watchedForm.usernameEl != null && watchedForm.data.password != null) {
|
|
|
|
// This is most likely a login or create account form b/c we have a username and password
|
|
|
|
watchedForm.passwordEl = locatePassword(
|
|
|
|
watchedForm.formEl,
|
|
|
|
watchedForm.data.password,
|
2021-12-21 15:43:35 +01:00
|
|
|
inputs,
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
true // Only do fallback if we have expect to find a single password field
|
2021-12-21 15:43:35 +01:00
|
|
|
);
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
} else if (watchedForm.data.passwords != null) {
|
|
|
|
// if we didn't find a username field, try to locate multiple password fields
|
|
|
|
// This is most likely a change password form b/c we have multiple password fields
|
|
|
|
watchedForm.passwordEls = [];
|
|
|
|
watchedForm.data.passwords.forEach((passwordData: AutofillField) => {
|
|
|
|
// Note: do not do fallback here b/c we expect to find multiple password fields
|
|
|
|
// and form.querySelector always returns the first element it finds
|
|
|
|
const passwordEl = locatePassword(watchedForm.formEl, passwordData, inputs, false);
|
|
|
|
if (passwordEl != null) {
|
|
|
|
watchedForm.passwordEls.push(passwordEl);
|
2018-05-09 20:00:13 +02:00
|
|
|
}
|
2021-12-21 15:43:35 +01:00
|
|
|
});
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
if (watchedForm.passwordEls.length === 0) {
|
|
|
|
watchedForm.passwordEls = null;
|
2021-12-21 15:43:35 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-08-01 05:24:11 +02:00
|
|
|
function locatePassword(
|
|
|
|
form: HTMLFormElement,
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
passwordData: AutofillField,
|
2018-08-01 05:24:11 +02:00
|
|
|
inputs: HTMLInputElement[],
|
|
|
|
doLastFallback: boolean
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
): HTMLInputElement {
|
2018-08-01 05:24:11 +02:00
|
|
|
let el = locateField(form, passwordData, inputs);
|
|
|
|
if (el != null && el.type !== "password") {
|
|
|
|
el = null;
|
2018-05-09 20:00:13 +02:00
|
|
|
}
|
2018-08-01 05:24:11 +02:00
|
|
|
if (doLastFallback && el == null) {
|
|
|
|
el = form.querySelector('input[type="password"]');
|
2021-12-21 15:43:35 +01:00
|
|
|
}
|
2018-08-01 05:24:11 +02:00
|
|
|
return el;
|
2021-12-21 15:43:35 +01:00
|
|
|
}
|
2018-05-09 20:00:13 +02:00
|
|
|
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
/**
|
|
|
|
* Locate a field within a form element given field data.
|
|
|
|
* @param {Object} form - The form element to search within.
|
|
|
|
* @param {Object} fieldData - The field data to search for.
|
|
|
|
* @param {Object[]} inputs - The array of input elements to search within.
|
|
|
|
* @returns {Object} The located field element.
|
|
|
|
*/
|
|
|
|
function locateField(
|
|
|
|
form: HTMLFormElement,
|
|
|
|
fieldData: AutofillField,
|
|
|
|
inputs: HTMLInputElement[]
|
|
|
|
): HTMLInputElement | null {
|
|
|
|
// If we have no field data, we cannot locate the field
|
2018-08-01 05:24:11 +02:00
|
|
|
if (fieldData == null) {
|
|
|
|
return;
|
2021-12-21 15:43:35 +01:00
|
|
|
}
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
// Try to locate the field by its HTML ID, by its HTML name, or finally by its element number
|
2018-08-01 05:24:11 +02:00
|
|
|
let el: HTMLInputElement = null;
|
|
|
|
if (fieldData.htmlID != null && fieldData.htmlID !== "") {
|
2021-12-21 15:43:35 +01:00
|
|
|
try {
|
2018-08-01 05:24:11 +02:00
|
|
|
el = form.querySelector("#" + fieldData.htmlID);
|
|
|
|
} catch {
|
|
|
|
// Ignore error, we perform fallbacks below.
|
2021-12-21 15:43:35 +01:00
|
|
|
}
|
|
|
|
}
|
2018-08-01 05:24:11 +02:00
|
|
|
if (el == null && fieldData.htmlName != null && fieldData.htmlName !== "") {
|
|
|
|
el = form.querySelector('input[name="' + fieldData.htmlName + '"]');
|
2018-08-01 18:25:05 +02:00
|
|
|
}
|
|
|
|
if (el == null && fieldData.elementNumber != null) {
|
2018-08-01 05:24:11 +02:00
|
|
|
el = inputs[fieldData.elementNumber];
|
2021-12-21 15:43:35 +01:00
|
|
|
}
|
2018-08-01 05:24:11 +02:00
|
|
|
return el;
|
2021-12-21 15:43:35 +01:00
|
|
|
}
|
|
|
|
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
/*
|
|
|
|
* Event handler for form submission (submit button click or form submit)
|
|
|
|
*/
|
2018-08-01 05:24:11 +02:00
|
|
|
function formSubmitted(e: Event) {
|
|
|
|
let form: HTMLFormElement = null;
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
// If the event is a click event, we need to find the closest form element
|
|
|
|
let clickedElement: HTMLElement = null;
|
2018-05-09 20:00:13 +02:00
|
|
|
if (e.type === "click") {
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
clickedElement = e.target as HTMLElement;
|
|
|
|
|
|
|
|
// Set a flag on the clicked element so we don't set it as a submit button again
|
|
|
|
if (clickedElement?.dataset?.bitwardenClicked !== "1") {
|
|
|
|
clickedElement.dataset.bitwardenClicked = "1";
|
|
|
|
}
|
|
|
|
|
|
|
|
form = clickedElement.closest("form");
|
|
|
|
// If we didn't find a form element, check if the click was within a modal
|
2018-08-01 05:24:11 +02:00
|
|
|
if (form == null) {
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
const parentModal = clickedElement.closest("div.modal");
|
|
|
|
// If we found a modal, check if it has a single form element
|
2018-08-01 20:23:07 +02:00
|
|
|
if (parentModal != null) {
|
2018-08-01 05:24:11 +02:00
|
|
|
const modalForms = parentModal.querySelectorAll("form");
|
2018-08-01 18:25:05 +02:00
|
|
|
if (modalForms.length === 1) {
|
|
|
|
form = modalForms[0];
|
2021-12-21 15:43:35 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
|
|
|
|
// see if the event target is a submit button with a formOpId
|
|
|
|
const formOpId = (clickedElement as HTMLElementWithFormOpId).formOpId;
|
|
|
|
if (form == null && formOpId != null) {
|
|
|
|
// Find form in watched forms array via form op id
|
|
|
|
form = watchedForms.find((wf: WatchedForm) => wf.formEl.opid === formOpId).formEl;
|
|
|
|
}
|
2018-08-01 18:25:05 +02:00
|
|
|
} else {
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
// If the event is a submit event, we can get the form element from the event target
|
2018-08-01 05:24:11 +02:00
|
|
|
form = e.target as HTMLFormElement;
|
|
|
|
}
|
|
|
|
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
// if we didn't find a form element or we've already processed this form, return
|
2018-08-01 05:24:11 +02:00
|
|
|
if (form == null || form.dataset.bitwardenProcessed === "1") {
|
|
|
|
return;
|
|
|
|
}
|
2018-05-09 20:00:13 +02:00
|
|
|
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
// Find the form in the watched forms array
|
|
|
|
for (let i = 0; i < watchedForms.length; i++) {
|
|
|
|
if (watchedForms[i].formEl !== form) {
|
2018-08-01 05:24:11 +02:00
|
|
|
continue;
|
2021-12-21 15:43:35 +01:00
|
|
|
}
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
|
2018-08-01 05:24:11 +02:00
|
|
|
const disabledBoth = disabledChangedPasswordNotification && disabledAddLoginNotification;
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
// if user has not disabled both notifications and we have a username and password field,
|
|
|
|
if (
|
|
|
|
!disabledBoth &&
|
|
|
|
watchedForms[i].usernameEl != null &&
|
|
|
|
watchedForms[i].passwordEl != null
|
|
|
|
) {
|
|
|
|
// Create a login object from the form data
|
2018-08-01 05:24:11 +02:00
|
|
|
const login: AddLoginRuntimeMessage = {
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
username: watchedForms[i].usernameEl.value,
|
|
|
|
password: watchedForms[i].passwordEl.value,
|
2018-08-01 05:24:11 +02:00
|
|
|
url: document.URL,
|
2021-12-21 15:43:35 +01:00
|
|
|
};
|
|
|
|
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
// if we have values for username and password, send a message to the background script to add the login
|
|
|
|
const userNamePopulated = login.username != null && login.username !== "";
|
|
|
|
const passwordPopulated = login.password != null && login.password !== "";
|
|
|
|
if (userNamePopulated && passwordPopulated) {
|
2018-08-01 18:25:05 +02:00
|
|
|
processedForm(form);
|
|
|
|
sendPlatformMessage({
|
2018-08-01 05:24:11 +02:00
|
|
|
command: "bgAddLogin",
|
|
|
|
login: login,
|
2021-12-21 15:43:35 +01:00
|
|
|
});
|
|
|
|
break;
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
} else if (
|
|
|
|
userNamePopulated &&
|
|
|
|
!passwordPopulated &&
|
|
|
|
clickedElement !== null &&
|
|
|
|
!isElementVisible(clickedElement)
|
|
|
|
) {
|
|
|
|
// Likely a multi step login form with password missing and next button no longer visible
|
|
|
|
// Remove click listener from previous "submit" button (next button)
|
|
|
|
clickedElement.removeEventListener("click", formSubmitted);
|
|
|
|
findAndListenToSubmitButton(form);
|
2021-12-21 15:43:35 +01:00
|
|
|
}
|
|
|
|
}
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
|
|
|
|
// if user has not disabled the password changed notification and we have multiple password fields,
|
|
|
|
// then check if the user has changed their password
|
|
|
|
if (!disabledChangedPasswordNotification && watchedForms[i].passwordEls != null) {
|
|
|
|
// Get the values of the password fields
|
|
|
|
const passwords: string[] = watchedForms[i].passwordEls
|
2018-08-01 05:24:11 +02:00
|
|
|
.filter((el: HTMLInputElement) => el.value != null && el.value !== "")
|
2018-08-01 20:23:07 +02:00
|
|
|
.map((el: HTMLInputElement) => el.value);
|
2021-12-21 15:43:35 +01:00
|
|
|
|
2018-08-01 20:23:07 +02:00
|
|
|
let curPass: string = null;
|
|
|
|
let newPass: string = null;
|
|
|
|
let newPassOnly = false;
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
|
|
|
|
if (watchedForms[i].passwordEls.length === 3 && passwords.length === 3) {
|
|
|
|
// we have 3 password fields and all 3 have values
|
|
|
|
// Assume second field is new password.
|
2018-08-01 20:23:07 +02:00
|
|
|
newPass = passwords[1];
|
|
|
|
if (passwords[0] !== newPass && newPass === passwords[2]) {
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
// first field is the current password, the second field is the new password, and the third field is the new password confirmation
|
2018-08-01 20:23:07 +02:00
|
|
|
curPass = passwords[0];
|
|
|
|
} else if (newPass !== passwords[2] && passwords[0] === newPass) {
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
// first field is the new password, second field is the new password confirmation, and third field is the current password
|
2018-08-01 05:24:11 +02:00
|
|
|
curPass = passwords[2];
|
2021-12-21 15:43:35 +01:00
|
|
|
}
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
} else if (watchedForms[i].passwordEls.length === 2 && passwords.length === 2) {
|
|
|
|
// we have 2 password fields and both have values
|
2018-09-07 14:01:50 +02:00
|
|
|
if (passwords[0] === passwords[1]) {
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
// both fields have the same value, assume this is a new password
|
2018-09-07 14:01:50 +02:00
|
|
|
newPassOnly = true;
|
|
|
|
newPass = passwords[0];
|
|
|
|
curPass = null;
|
2021-12-21 15:43:35 +01:00
|
|
|
} else {
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
// both fields have different values
|
|
|
|
// Check if the submit button contains any of the change password button names as a safeguard
|
2018-08-01 20:23:07 +02:00
|
|
|
const buttonText = getButtonText(getSubmitButton(form, changePasswordButtonNames));
|
|
|
|
const matches = Array.from(changePasswordButtonContainsNames).filter(
|
2021-02-10 16:40:15 +01:00
|
|
|
(n) => buttonText.indexOf(n) > -1
|
2021-12-21 15:43:35 +01:00
|
|
|
);
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
|
2018-09-07 14:01:50 +02:00
|
|
|
if (matches.length > 0) {
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
// If there is a change password button, then
|
|
|
|
// assume first field is current password and second field is new password
|
2018-08-01 20:23:07 +02:00
|
|
|
curPass = passwords[0];
|
2018-09-07 14:01:50 +02:00
|
|
|
newPass = passwords[1];
|
2018-08-01 20:23:07 +02:00
|
|
|
}
|
2018-05-09 20:00:13 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
// if we have a new password and a current password or we only have a new password
|
2018-05-09 20:00:13 +02:00
|
|
|
if ((newPass != null && curPass != null) || (newPassOnly && newPass != null)) {
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
// Flag the form as processed so we don't process it again
|
2018-05-09 20:00:13 +02:00
|
|
|
processedForm(form);
|
|
|
|
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
// Send a message to the `notification.background.ts` background script to notify the user that their password has changed
|
|
|
|
// which eventually calls the `processMessage(...)` method in this script with command `openNotificationBar`
|
2021-10-19 12:10:31 +02:00
|
|
|
const changePasswordRuntimeMessage: ChangePasswordRuntimeMessage = {
|
2018-08-01 05:24:11 +02:00
|
|
|
newPassword: newPass,
|
2018-09-07 21:15:01 +02:00
|
|
|
currentPassword: curPass,
|
2018-08-01 05:24:11 +02:00
|
|
|
url: document.URL,
|
2018-09-07 14:01:50 +02:00
|
|
|
};
|
2018-08-01 18:25:05 +02:00
|
|
|
sendPlatformMessage({
|
2018-09-07 14:01:50 +02:00
|
|
|
command: "bgChangedPassword",
|
2021-10-19 12:10:31 +02:00
|
|
|
data: changePasswordRuntimeMessage,
|
2018-08-01 18:25:05 +02:00
|
|
|
});
|
|
|
|
break;
|
|
|
|
}
|
2021-12-21 15:43:35 +01:00
|
|
|
}
|
2018-08-01 18:25:05 +02:00
|
|
|
}
|
2021-12-21 15:43:35 +01:00
|
|
|
}
|
2018-08-01 18:25:05 +02:00
|
|
|
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
/**
|
|
|
|
* Gets a submit button element from a form or enclosing element
|
|
|
|
* @param wrappingEl - the form or enclosing element
|
|
|
|
* @param buttonNames - login button names to match against
|
|
|
|
* @returns the submit button element
|
|
|
|
*/
|
|
|
|
function getSubmitButton(wrappingEl: HTMLElement, buttonNames: Set<string>): HTMLElement {
|
|
|
|
// If wrapping element doesn't exist we can't get a submit button
|
2018-08-01 18:25:05 +02:00
|
|
|
if (wrappingEl == null) {
|
|
|
|
return null;
|
|
|
|
}
|
|
|
|
|
2018-05-09 20:00:13 +02:00
|
|
|
const wrappingElIsForm = wrappingEl.tagName.toLowerCase() === "form";
|
|
|
|
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
// query for submit button
|
|
|
|
const possibleSubmitBtnSelectors = [
|
|
|
|
'input[type="submit"]',
|
|
|
|
'input[type="image"]',
|
|
|
|
'button[type="submit"]',
|
|
|
|
];
|
|
|
|
const submitBtnSelector = possibleSubmitBtnSelectors
|
|
|
|
.map((btnSelector) => `${btnSelector}:not([data-bitwarden-clicked])`)
|
|
|
|
.join(", ");
|
|
|
|
let submitButton = wrappingEl.querySelector(submitBtnSelector) as HTMLElement;
|
|
|
|
|
|
|
|
// if we didn't find a submit button and we are in a form:
|
2018-05-09 20:00:13 +02:00
|
|
|
if (submitButton == null && wrappingElIsForm) {
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
// query for a button that doesn't have the type attribute
|
|
|
|
submitButton = wrappingEl.querySelector("button:not([type]):not([data-bitwarden-clicked])");
|
2018-05-09 20:00:13 +02:00
|
|
|
if (submitButton != null) {
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
// Retrieve "submit" button text because it might be a cancel button instead of a submit button.
|
|
|
|
// If it is a cancel button, then we don't want to use it.
|
2018-05-09 20:00:13 +02:00
|
|
|
const buttonText = getButtonText(submitButton);
|
|
|
|
if (buttonText != null && cancelButtonNames.has(buttonText.trim().toLowerCase())) {
|
|
|
|
submitButton = null;
|
|
|
|
}
|
2021-12-21 15:43:35 +01:00
|
|
|
}
|
|
|
|
}
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
|
|
|
|
// If we still don't have a submit button, then try to find a button that looks like a submit button
|
2018-11-14 14:36:29 +01:00
|
|
|
if (submitButton == null) {
|
2018-08-01 20:23:07 +02:00
|
|
|
const possibleSubmitButtons = Array.from(
|
|
|
|
wrappingEl.querySelectorAll(
|
|
|
|
'a, span, button[type="button"], ' + 'input[type="button"], button:not([type])'
|
2021-12-21 15:43:35 +01:00
|
|
|
)
|
2018-08-01 18:25:05 +02:00
|
|
|
) as HTMLElement[];
|
2018-11-14 14:36:29 +01:00
|
|
|
let typelessButton: HTMLElement = null;
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
// Loop through all possible submit buttons and find the first one that matches a submit button name
|
2021-02-10 16:40:15 +01:00
|
|
|
possibleSubmitButtons.forEach((button) => {
|
2018-08-01 18:25:05 +02:00
|
|
|
if (submitButton != null || button == null || button.tagName == null) {
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
// Continue if we already found a submit button or if the button is null or doesn't have a tag name
|
|
|
|
// Return in a forEach(...) is equivalent to continue
|
2021-12-21 15:43:35 +01:00
|
|
|
return;
|
|
|
|
}
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
// Retrieve button text
|
2018-05-09 20:00:13 +02:00
|
|
|
const buttonText = getButtonText(button);
|
2018-08-01 18:25:05 +02:00
|
|
|
if (buttonText != null) {
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
// if we have a button that doesn't have a type attribute & isn't a cancel btn,
|
|
|
|
// then save it in case we don't find a submit button
|
2021-12-21 15:43:35 +01:00
|
|
|
if (
|
2018-11-14 14:36:29 +01:00
|
|
|
typelessButton != null &&
|
|
|
|
button.tagName.toLowerCase() === "button" &&
|
|
|
|
button.getAttribute("type") == null &&
|
2018-08-01 18:25:05 +02:00
|
|
|
!cancelButtonNames.has(buttonText.trim().toLowerCase())
|
2021-12-21 15:43:35 +01:00
|
|
|
) {
|
2018-11-14 14:36:29 +01:00
|
|
|
typelessButton = button;
|
2018-05-09 20:00:13 +02:00
|
|
|
} else if (buttonNames.has(buttonText.trim().toLowerCase())) {
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
// If the button text matches a submit button name, then use it
|
2018-08-01 18:25:05 +02:00
|
|
|
submitButton = button;
|
2021-12-21 15:43:35 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
});
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
// Fallback to typeless button if it exists and we didn't find a submit button
|
2018-11-14 14:36:29 +01:00
|
|
|
if (submitButton == null && typelessButton != null) {
|
|
|
|
submitButton = typelessButton;
|
2021-12-21 15:43:35 +01:00
|
|
|
}
|
|
|
|
}
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
|
|
|
|
// If we still don't have a submit button, then try to find a submit button in a modal
|
2018-11-14 14:36:29 +01:00
|
|
|
if (submitButton == null && wrappingElIsForm) {
|
2018-08-01 20:23:07 +02:00
|
|
|
// Maybe it's in a modal?
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
// Find closest modal and check if it has only one form
|
2018-05-09 20:00:13 +02:00
|
|
|
const parentModal = wrappingEl.closest("div.modal") as HTMLElement;
|
2018-08-01 20:23:07 +02:00
|
|
|
if (parentModal != null) {
|
|
|
|
const modalForms = parentModal.querySelectorAll("form");
|
|
|
|
if (modalForms.length === 1) {
|
|
|
|
submitButton = getSubmitButton(parentModal, buttonNames);
|
2021-12-21 15:43:35 +01:00
|
|
|
}
|
|
|
|
}
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
|
|
|
|
// If we still don't have a submit button, then try to find a submit button by using the form's
|
|
|
|
// parent element as the wrapping element
|
|
|
|
if (submitButton == null) {
|
|
|
|
const parentElement = wrappingEl.parentElement;
|
|
|
|
|
|
|
|
// Going up a level and looking for loginButtonNames
|
|
|
|
if (parentElement != null) {
|
|
|
|
submitButton = getSubmitButton(parentElement, buttonNames);
|
|
|
|
}
|
|
|
|
}
|
2021-12-21 15:43:35 +01:00
|
|
|
}
|
2018-08-01 20:23:07 +02:00
|
|
|
return submitButton;
|
2021-12-21 15:43:35 +01:00
|
|
|
}
|
|
|
|
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
/**
|
|
|
|
* Returns the text of a given button element.
|
|
|
|
* @param button - The button element to get the text from.
|
|
|
|
* @returns - The text of the button.
|
|
|
|
*/
|
2018-08-01 18:25:05 +02:00
|
|
|
function getButtonText(button: HTMLElement) {
|
|
|
|
let buttonText: string = null;
|
|
|
|
if (button.tagName.toLowerCase() === "input") {
|
|
|
|
buttonText = (button as HTMLInputElement).value;
|
2021-12-21 15:43:35 +01:00
|
|
|
} else {
|
2018-08-01 18:25:05 +02:00
|
|
|
buttonText = button.innerText;
|
2021-12-21 15:43:35 +01:00
|
|
|
}
|
2018-08-01 18:25:05 +02:00
|
|
|
return buttonText;
|
2021-12-21 15:43:35 +01:00
|
|
|
}
|
|
|
|
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
/**
|
|
|
|
* Mark form as processed so we don't try to process it again.
|
|
|
|
* @param {Object} form - The form element to mark as processed.
|
|
|
|
*/
|
2018-05-09 20:00:13 +02:00
|
|
|
function processedForm(form: HTMLFormElement) {
|
2018-08-01 05:24:11 +02:00
|
|
|
form.dataset.bitwardenProcessed = "1";
|
|
|
|
window.setTimeout(() => {
|
|
|
|
form.dataset.bitwardenProcessed = "0";
|
2018-05-09 20:00:13 +02:00
|
|
|
}, 500);
|
2021-12-21 15:43:35 +01:00
|
|
|
}
|
|
|
|
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
//#endregion Form Detection and Submission Handling
|
|
|
|
|
|
|
|
//#region Notification Bar Functions (open, close, height adjustment, etc.)
|
2018-05-09 20:00:13 +02:00
|
|
|
function closeExistingAndOpenBar(type: string, typeData: any) {
|
2022-10-27 19:34:47 +02:00
|
|
|
const barQueryParams = {
|
|
|
|
type,
|
|
|
|
isVaultLocked: typeData.isVaultLocked,
|
|
|
|
theme: typeData.theme,
|
2023-03-08 23:12:43 +01:00
|
|
|
removeIndividualVault: typeData.removeIndividualVault,
|
2022-10-27 19:34:47 +02:00
|
|
|
};
|
|
|
|
const barQueryString = new URLSearchParams(barQueryParams).toString();
|
|
|
|
const barPage = "notification/bar.html?" + barQueryString;
|
2018-05-09 20:00:13 +02:00
|
|
|
|
|
|
|
const frame = document.getElementById("bit-notification-bar-iframe") as HTMLIFrameElement;
|
2021-10-18 18:48:52 +02:00
|
|
|
if (frame != null && frame.src.indexOf(barPage) >= 0) {
|
|
|
|
return;
|
2021-12-21 15:43:35 +01:00
|
|
|
}
|
2018-05-09 20:00:13 +02:00
|
|
|
|
2019-10-09 16:12:06 +02:00
|
|
|
closeBar(false);
|
2018-05-09 20:00:13 +02:00
|
|
|
openBar(type, barPage);
|
2021-12-21 15:43:35 +01:00
|
|
|
}
|
2018-05-09 20:00:13 +02:00
|
|
|
|
|
|
|
function openBar(type: string, barPage: string) {
|
|
|
|
barType = type;
|
|
|
|
|
|
|
|
if (document.body == null) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
const barPageUrl: string = chrome.extension.getURL(barPage);
|
2021-12-21 15:43:35 +01:00
|
|
|
|
2018-05-09 20:00:13 +02:00
|
|
|
const iframe = document.createElement("iframe");
|
2018-06-05 16:52:47 +02:00
|
|
|
iframe.style.cssText = "height: 42px; width: 100%; border: 0; min-height: initial;";
|
2018-05-09 20:00:13 +02:00
|
|
|
iframe.id = "bit-notification-bar-iframe";
|
2021-02-03 20:36:05 +01:00
|
|
|
iframe.src = barPageUrl;
|
2021-12-21 15:43:35 +01:00
|
|
|
|
2018-05-09 20:00:13 +02:00
|
|
|
const frameDiv = document.createElement("div");
|
2019-10-09 16:12:06 +02:00
|
|
|
frameDiv.setAttribute("aria-live", "polite");
|
2018-05-09 20:00:13 +02:00
|
|
|
frameDiv.id = "bit-notification-bar";
|
|
|
|
frameDiv.style.cssText =
|
|
|
|
"height: 42px; width: 100%; top: 0; left: 0; padding: 0; position: fixed; " +
|
|
|
|
"z-index: 2147483647; visibility: visible;";
|
|
|
|
frameDiv.appendChild(iframe);
|
|
|
|
document.body.appendChild(frameDiv);
|
2021-12-21 15:43:35 +01:00
|
|
|
|
2018-05-09 20:00:13 +02:00
|
|
|
(iframe.contentWindow.location as any) = barPageUrl;
|
2021-12-21 15:43:35 +01:00
|
|
|
|
2018-05-09 20:00:13 +02:00
|
|
|
const spacer = document.createElement("div");
|
|
|
|
spacer.id = "bit-notification-bar-spacer";
|
|
|
|
spacer.style.cssText = "height: 42px;";
|
|
|
|
document.body.insertBefore(spacer, document.body.firstChild);
|
2021-12-21 15:43:35 +01:00
|
|
|
}
|
|
|
|
|
2018-05-09 20:00:13 +02:00
|
|
|
function closeBar(explicitClose: boolean) {
|
|
|
|
const barEl = document.getElementById("bit-notification-bar");
|
|
|
|
if (barEl != null) {
|
|
|
|
barEl.parentElement.removeChild(barEl);
|
|
|
|
}
|
|
|
|
|
|
|
|
const spacerEl = document.getElementById("bit-notification-bar-spacer");
|
|
|
|
if (spacerEl) {
|
2018-08-01 05:24:11 +02:00
|
|
|
spacerEl.parentElement.removeChild(spacerEl);
|
2018-05-09 20:00:13 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
if (!explicitClose) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
switch (barType) {
|
|
|
|
case "add":
|
|
|
|
sendPlatformMessage({
|
|
|
|
command: "bgAddClose",
|
|
|
|
});
|
2021-12-21 15:43:35 +01:00
|
|
|
break;
|
2018-05-09 20:00:13 +02:00
|
|
|
case "change":
|
|
|
|
sendPlatformMessage({
|
|
|
|
command: "bgChangeClose",
|
2021-12-21 15:43:35 +01:00
|
|
|
});
|
2018-05-09 20:00:13 +02:00
|
|
|
break;
|
2021-12-21 15:43:35 +01:00
|
|
|
default:
|
|
|
|
break;
|
2018-05-09 20:00:13 +02:00
|
|
|
}
|
2021-12-21 15:43:35 +01:00
|
|
|
}
|
|
|
|
|
2018-05-09 20:00:13 +02:00
|
|
|
function adjustBar(data: any) {
|
|
|
|
if (data != null && data.height !== 42) {
|
|
|
|
const newHeight = data.height + "px";
|
|
|
|
doHeightAdjustment("bit-notification-bar-iframe", newHeight);
|
|
|
|
doHeightAdjustment("bit-notification-bar", newHeight);
|
|
|
|
doHeightAdjustment("bit-notification-bar-spacer", newHeight);
|
2021-12-21 15:43:35 +01:00
|
|
|
}
|
|
|
|
}
|
2018-05-09 20:00:13 +02:00
|
|
|
|
|
|
|
function doHeightAdjustment(elId: string, heightStyle: string) {
|
2021-02-03 20:36:05 +01:00
|
|
|
const el = document.getElementById(elId);
|
2018-05-09 20:00:13 +02:00
|
|
|
if (el != null) {
|
2021-02-03 20:36:05 +01:00
|
|
|
el.style.height = heightStyle;
|
2018-05-09 20:00:13 +02:00
|
|
|
}
|
2021-12-21 15:43:35 +01:00
|
|
|
}
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
//#endregion Notification Bar Functions (open, close, height adjustment, etc.)
|
2021-12-21 15:43:35 +01:00
|
|
|
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
//#region Helper Functions
|
2021-02-03 20:36:05 +01:00
|
|
|
function sendPlatformMessage(msg: any) {
|
|
|
|
chrome.runtime.sendMessage(msg);
|
2021-12-21 15:43:35 +01:00
|
|
|
}
|
[SG-1026 / PM-1125] - Document / Improve Form Detection in Notification Bar (#4798)
* 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>
2023-04-13 21:59:31 +02:00
|
|
|
|
|
|
|
function isInIframe() {
|
|
|
|
try {
|
|
|
|
return window.self !== window.top;
|
|
|
|
} catch {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// https://stackoverflow.com/a/41328397/20715409 - most efficient of the answers there
|
|
|
|
function unionSets(...iterables: Set<any>[]): Set<any> {
|
|
|
|
const set = new Set();
|
|
|
|
|
|
|
|
for (const iterable of iterables) {
|
|
|
|
for (const item of iterable) {
|
|
|
|
set.add(item);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return set;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Determine if the element is visible.
|
|
|
|
* Visible is define as not having `display: none` or `visibility: hidden`.
|
|
|
|
* @param {HTMLElement} el
|
|
|
|
* @returns {boolean} Returns `true` if the element is visible and `false` otherwise
|
|
|
|
*
|
|
|
|
* Copied from autofill.js and converted to TypeScript;
|
|
|
|
* TODO: could be refactored to be in a shared location if autofill.js is converted to TS
|
|
|
|
*/
|
|
|
|
function isElementVisible(el: HTMLElement): boolean {
|
|
|
|
let theEl: Node | null = el;
|
|
|
|
// Get the top level document
|
|
|
|
const elDocument = el.ownerDocument;
|
|
|
|
const elWindow = elDocument ? elDocument.defaultView : undefined;
|
|
|
|
|
|
|
|
// walk the dom tree until we reach the top
|
|
|
|
while (theEl && theEl !== document) {
|
|
|
|
// Calculate the style of the element
|
|
|
|
const elStyle = elWindow?.getComputedStyle
|
|
|
|
? elWindow.getComputedStyle(theEl as HTMLElement, null)
|
|
|
|
: (theEl as HTMLElement).style;
|
|
|
|
|
|
|
|
// If there's no computed style at all, we're done, as we know that it's not hidden
|
|
|
|
if (!elStyle) {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
// If the element's computed style includes `display: none` or `visibility: hidden`, we know it's hidden
|
|
|
|
if ("none" === elStyle.display || "hidden" === elStyle.visibility) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
// At this point, we aren't sure if the element is hidden or not, so we need to keep walking up the tree
|
|
|
|
theEl = theEl.parentNode;
|
|
|
|
}
|
|
|
|
|
|
|
|
// If we've reached the top of the tree, we know that the element is visible
|
|
|
|
return theEl === document;
|
|
|
|
}
|
|
|
|
|
|
|
|
//#endregion Helper Functions
|
2018-05-09 20:00:13 +02:00
|
|
|
});
|