bitwarden-browser/apps/browser/src/autofill/content/notification-bar.ts

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

1010 lines
38 KiB
TypeScript
Raw Normal View History

[SG-998] and [SG-999] Vault and Autofill team refactor (#4542) * Move DeprecatedVaultFilterService to vault folder * [libs] move VaultItemsComponent * [libs] move AddEditComponent * [libs] move AddEditCustomFields * [libs] move attachmentsComponent * [libs] folderAddEditComponent * [libs] IconComponent * [libs] PasswordRepormptComponent * [libs] PremiumComponent * [libs] ViewCustomFieldsComponent * [libs] ViewComponent * [libs] PasswordRepromptService * [libs] Move FolderService and FolderApiService abstractions * [libs] FolderService imports * [libs] PasswordHistoryComponent * [libs] move Sync and SyncNotifier abstractions * [libs] SyncService imports * [libs] fix file casing for passwordReprompt abstraction * [libs] SyncNotifier import fix * [libs] CipherServiceAbstraction * [libs] PasswordRepromptService abstraction * [libs] Fix file casing for angular passwordReprompt service * [libs] fix file casing for SyncNotifierService * [libs] CipherRepromptType * [libs] rename CipherRepromptType * [libs] CipherType * [libs] Rename CipherType * [libs] CipherData * [libs] FolderData * [libs] PasswordHistoryData * [libs] AttachmentData * [libs] CardData * [libs] FieldData * [libs] IdentityData * [libs] LocalData * [libs] LoginData * [libs] SecureNoteData * [libs] LoginUriData * [libs] Domain classes * [libs] SecureNote * [libs] Request models * [libs] Response models * [libs] View part 1 * [libs] Views part 2 * [libs] Move folder services * [libs] Views fixes * [libs] Move sync services * [libs] cipher service * [libs] Types * [libs] Sync file casing * [libs] Fix folder service import * [libs] Move spec files * [libs] casing fixes on spec files * [browser] Autofill background, clipboard, commands * [browser] Fix ContextMenusBackground casing * [browser] Rename fix * [browser] Autofill content * [browser] autofill.js * [libs] enpass importer spec fix * [browser] autofill models * [browser] autofill manifest path updates * [browser] Autofill notification files * [browser] autofill services * [browser] Fix file casing * [browser] Vault popup loose components * [browser] Vault components * [browser] Manifest fixes * [browser] Vault services * [cli] vault commands and models * [browser] File capitilization fixes * [desktop] Vault components and services * [web] vault loose components * [web] Vault components * [browser] Fix misc-utils import * [libs] Fix psono spec imports * [fix] Add comments to address lint rules
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";
import { GlobalSettings, UserSettings } from "../types";
[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
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
*/
[PM-3285] Autofill v2 Feature Branch (#5939) * [PM-3285] Autofill v2 Feature Branch * [PM-2130] - Audit, Modularize, and Refactor Core autofill.js File (#5453) * split up autofill.ts, first pass * remove modification tracking comments * lessen and localize eslint disables * additional typing and formatting * update autofill v2 with PR #5364 changes (update/i18n confirm dialogs) * update autofill v2 with PR #4155 changes (add autofill support for textarea) Co-Authored-By: Manuel <mr-manuel@outlook.it> * move commonly used string values to constants * ts cleanup * [PM-2130] Starting work to re-architect autofillv2.ts * [PM-2130] Starting work to re-architect autofillv2.ts * [PM-2130] Working through autofill collect method * [PM-2130] Marking Removal of documentUUID as dead code * [PM-2130] Refining the implementation of collect and moving broken out utils back into class implementation * [PM-2130] Applying small refactors to AutofillCollect * [PM-2130] Refining the implementation of getAutofillFieldLabelTag to help with readability of the method * [PM-2130] Implementing jest tests for AutofillCollect methods * [PM-2130] Refining implementation for AutofillCollect * [PM-2200] Unit tests for autofill content script utilities with slight refactors (#5544) * add unit tests for urlNotSecure * add test coverage command * add unit tests for canSeeElementToStyle * canSeeElementToStyle should not return true if `animateTheFilling` or `currentEl` is false * add tests for selectAllFromDoc and getElementByOpId * clean up getElementByOpId * address some typing issues * add tests for setValueForElementByEvent, setValueForElement, and doSimpleSetByQuery * clean up setValueForElement and setValueForElementByEvent * more typescript cleanup * add tests for doClickByOpId and touchAllPasswordFields * add tests for doFocusByOpId and doClickByQuery * misc fill cleanup * move functions between collect and fill utils and replace getElementForOPID for duplicate getElementByOpId * add tests for isKnownTag and isElementVisible * rename addProp and remove redundant focusElement in favor of doFocusElement * cleanup * fix checkNodeType * add tests for shiftForLeftLabel * clean up and rename checkNodeType, isKnownTag, and shiftForLeftLabel * add tests for getFormElements * clean up getFormElements * add tests for getElementAttrValue, getElementValue, getSelectElementOptions, getLabelTop, and queryDoc * clean up and rename queryDoc to queryDocument * misc cleanup and rename getElementAttrValue to getPropertyOrAttribute * rebase cleanup * prettier formatting * [PM-2130] Fixing linting issues * [PM-2130] Fixing linting issues * [PM-2130] Migrating implementation for collect methods and tests for those methods into AutofillCollect context * [PM-2130] Migrating getPropertyOrAttribute method from utils to AutofillCollect * [PM-2130] Continuing migration of methods from collect utils into AutofillCollect * [PM-2130] Rework of isViewable method to better handle behavior for how we identify if an element is currently within the viewport * [PM-2130] Filling out implementation of autofill-insert * [PM-2130] Refining AutofillInsert * [PM-2130] Implementing jest tests for AutofillCollect methods and breaking out visibility related logic to a separate service * [PM-2130] Fixing jest tests for AutofillCollect * [PM-2130] Fixing jest tests for AutofillInit * [PM-2130] Adjusting how the AutofillFieldVisibilityService class is used in AutofillCollect * [PM-2130] Working through AutofillInsert implementation * [PM-2130] Migrating methods from fill.ts to AutofillInsert * [PM-2130] Migrating methods from fill.ts to AutofillInsert * [PM-2130] Applying fix for IntersectionObserver when triggering behavior in Safari and fixing issue with how we trigger an input event shortly after filling in a field * [PM-2130] Refactoring AutofillCollect to service CollectAutofillContentService * [PM-2130] Refactoring AutofillInsert to service InsertAutofillContentService * [PM-2130] Further organization of implementation * [PM-2130] Filling out missing jest test for AutofillInit.fillForm method * [PM-2130] Migrating the last of the collect jest tests to InsertAutofillContentService * [PM-2130] Further refactoring of elements including typing information * [PM-2130] Implementing jest tests for InsertAutofillContentService * [PM-2130] Implementing jest tests for InsertAutofillContentService * [PM-2130] Organization and refactoring of methods within InsertAutofillContent * [PM-2130] Implementation of jest tests for InsertAutofillContentService * [PM-2130] Implementation of Jest Test for IntertAutofillContentService * [PM-2130] Finalizing migration of methods and jest tests from util files into Autofill serivces * [PM-2130] Cleaning up dead code comments * [PM-2130] Removing unnecessary constants * [PM-2130] Finalizing jest tests for InsertAutofillContentService * [PM-2130] Refactoring FieldVisibiltyService to DomElementVisibilityService to allow service to act in a more general manner * [PM-2130] Implementing jest tests for DomElementVisibilityService * [PM-2130] Implementing jest tests for DomElementVisibilityService * [PM-2130] Implementing jest tests for DomElementVisibilityService * [PM-2130] Implementing jest tests for DomElementVisibilityService * [PM-2130] Breaking out the callback method used to resolve the IntersectionObserver promise * [PM-2130] Adding a comment explaining a fix for Safari * [PM-2130] Adding a comment explaining a fix for Safari * [PM-2130] Applying changes required for PM-2762 to implementation, and ensuring jest tests exist to validate the behavior * [PM-2130] Removing usage of IntersectionObserver when identifying element visibility due to broken interactions with React Components * [PM-2130] Fixing issue found when attempting to capture the elementAtCenterPoint in determining file visibility * [PM-2100] Create Unit Test Suite for autofill.service.ts (#5371) * [PM-2100] Create Unit Test Suite for Autofill.service.ts * [PM-2100] Finishing out tests for the getFormsWithPasswordFields method * [PM-2100] Implementing tests for the doAutofill method within the autofill service * [PM-2100] Working through implementation of doAutofill method * [PM-2100] Working through implementation of doAutofill method * [PM-2100] Finishing implementatino of isUntrustedIframe method within autofill service * [PM-2100] Finishing implementation of doAutoFill method within autofill service * [PM-2100] Finishing implementation of doAutoFillOnTab method within autofill service * [PM-2100] Working through tests for generateFillScript * [PM-2100] Finalizing generateFillScript method testing * [PM-2100] Starting implementation of generateLoginFillScript * [PM-2100] Working through tests for generateLoginFillScript * [PM-2100] Finalizing generateLoginFillScript method testing * [PM-2100] Removing unnecessary jest config file * [PM-2100] Fixing jest tests based on changes implemented within PM-2130 * [PM-2100] Fixing autofill mocks * [PM-2100] Fixing AutofillService jest tests * [PM-2100] Handling missing tests within coverage of AutofillService * [PM-2100] Handling missing tests within coverage of AutofillService.generateLoginFillScript * [PM-2100] Writing tests for AutofillService.generateCardFillScript * [PM-2100] Finalizing tests for AutofillService.generateCardFillScript * [PM-2100] Adding additional tests to cover changes introduced by TOTOP autofill PR * [PM-2100] Adding jest tests for Autofill.generateIdentityFillScript * [PM-2100] Finalizing tests for AutofillService.generateIdentityFillScript * [PM-2100] Implementing tests for AutofillService * [PM-2100] Implementing tests for AutofillService.loadPasswordFields * [PM-2100] Implementing tests for AutofillService.findUsernameField * [PM-2100] Implementing tests for AutofillService.findTotpField * [PM-2100] Implementing tests for AutofillService.fieldPropertyIsPrefixMatch * [PM-2100] Finalizing tests for AutofillService * [PM-2100] Modyfing placement of autofill-mocks * [PM-2100] Modyfing placement of autofill-mocks * [PM-2100] Removal of jest transform declaration * [PM-2130] Fixing issue with autofill service unit tests * [PM-2130] Fixing issue with autofill service unit tests * [PM-2130] Fixing test test for when we need to handle a password reprompt --------- Co-authored-by: Manuel <mr-manuel@outlook.it> Co-authored-by: Cesar Gonzalez <cgonzalez@bitwarden.com> Co-authored-by: Cesar Gonzalez <cesar.a.gonzalezcs@gmail.com> * [PM-3285] Migrating Changes from PM-1407 into autofill v2 refactor implementation * [PM-2747] Add Support for Feature Flag of Autofill Version (#5695) * [PM-2100] Create Unit Test Suite for Autofill.service.ts * [PM-2100] Finishing out tests for the getFormsWithPasswordFields method * [PM-2100] Implementing tests for the doAutofill method within the autofill service * [PM-2100] Working through implementation of doAutofill method * [PM-2100] Working through implementation of doAutofill method * [PM-2100] Finishing implementatino of isUntrustedIframe method within autofill service * [PM-2100] Finishing implementation of doAutoFill method within autofill service * [PM-2100] Finishing implementation of doAutoFillOnTab method within autofill service * [PM-2100] Working through tests for generateFillScript * split up autofill.ts, first pass * remove modification tracking comments * lessen and localize eslint disables * additional typing and formatting * update autofill v2 with PR #5364 changes (update/i18n confirm dialogs) * update autofill v2 with PR #4155 changes (add autofill support for textarea) Co-Authored-By: Manuel <mr-manuel@outlook.it> * move commonly used string values to constants * ts cleanup * [PM-2100] Finalizing generateFillScript method testing * [PM-2100] Starting implementation of generateLoginFillScript * [PM-2100] Working through tests for generateLoginFillScript * [PM-2100] Finalizing generateLoginFillScript method testing * [PM-2130] Starting work to re-architect autofillv2.ts * [PM-2130] Starting work to re-architect autofillv2.ts * [PM-2130] Working through autofill collect method * [PM-2130] Marking Removal of documentUUID as dead code * [PM-2130] Refining the implementation of collect and moving broken out utils back into class implementation * [PM-2130] Applying small refactors to AutofillCollect * [PM-2130] Refining the implementation of getAutofillFieldLabelTag to help with readability of the method * [PM-2130] Implementing jest tests for AutofillCollect methods * [PM-2130] Refining implementation for AutofillCollect * [PM-2200] Unit tests for autofill content script utilities with slight refactors (#5544) * add unit tests for urlNotSecure * add test coverage command * add unit tests for canSeeElementToStyle * canSeeElementToStyle should not return true if `animateTheFilling` or `currentEl` is false * add tests for selectAllFromDoc and getElementByOpId * clean up getElementByOpId * address some typing issues * add tests for setValueForElementByEvent, setValueForElement, and doSimpleSetByQuery * clean up setValueForElement and setValueForElementByEvent * more typescript cleanup * add tests for doClickByOpId and touchAllPasswordFields * add tests for doFocusByOpId and doClickByQuery * misc fill cleanup * move functions between collect and fill utils and replace getElementForOPID for duplicate getElementByOpId * add tests for isKnownTag and isElementVisible * rename addProp and remove redundant focusElement in favor of doFocusElement * cleanup * fix checkNodeType * add tests for shiftForLeftLabel * clean up and rename checkNodeType, isKnownTag, and shiftForLeftLabel * add tests for getFormElements * clean up getFormElements * add tests for getElementAttrValue, getElementValue, getSelectElementOptions, getLabelTop, and queryDoc * clean up and rename queryDoc to queryDocument * misc cleanup and rename getElementAttrValue to getPropertyOrAttribute * rebase cleanup * prettier formatting * [PM-2130] Fixing linting issues * [PM-2130] Fixing linting issues * [PM-2130] Migrating implementation for collect methods and tests for those methods into AutofillCollect context * [PM-2130] Migrating getPropertyOrAttribute method from utils to AutofillCollect * [PM-2130] Continuing migration of methods from collect utils into AutofillCollect * [PM-2130] Rework of isViewable method to better handle behavior for how we identify if an element is currently within the viewport * [PM-2130] Filling out implementation of autofill-insert * [PM-2130] Refining AutofillInsert * [PM-2130] Implementing jest tests for AutofillCollect methods and breaking out visibility related logic to a separate service * [PM-2130] Fixing jest tests for AutofillCollect * [PM-2130] Fixing jest tests for AutofillInit * [PM-2130] Adjusting how the AutofillFieldVisibilityService class is used in AutofillCollect * [PM-2130] Working through AutofillInsert implementation * [PM-2130] Migrating methods from fill.ts to AutofillInsert * [PM-2130] Migrating methods from fill.ts to AutofillInsert * [PM-2130] Applying fix for IntersectionObserver when triggering behavior in Safari and fixing issue with how we trigger an input event shortly after filling in a field * [PM-2130] Refactoring AutofillCollect to service CollectAutofillContentService * [PM-2130] Refactoring AutofillInsert to service InsertAutofillContentService * [PM-2130] Further organization of implementation * [PM-2130] Filling out missing jest test for AutofillInit.fillForm method * [PM-2130] Migrating the last of the collect jest tests to InsertAutofillContentService * [PM-2130] Further refactoring of elements including typing information * [PM-2130] Implementing jest tests for InsertAutofillContentService * [PM-2130] Implementing jest tests for InsertAutofillContentService * [PM-2130] Organization and refactoring of methods within InsertAutofillContent * [PM-2130] Implementation of jest tests for InsertAutofillContentService * [PM-2130] Implementation of Jest Test for IntertAutofillContentService * [PM-2130] Finalizing migration of methods and jest tests from util files into Autofill serivces * [PM-2130] Cleaning up dead code comments * [PM-2130] Removing unnecessary constants * [PM-2130] Finalizing jest tests for InsertAutofillContentService * [PM-2130] Refactoring FieldVisibiltyService to DomElementVisibilityService to allow service to act in a more general manner * [PM-2130] Implementing jest tests for DomElementVisibilityService * [PM-2130] Implementing jest tests for DomElementVisibilityService * [PM-2130] Implementing jest tests for DomElementVisibilityService * [PM-2130] Implementing jest tests for DomElementVisibilityService * [PM-2130] Breaking out the callback method used to resolve the IntersectionObserver promise * [PM-2100] Removing unnecessary jest config file * [PM-2100] Fixing jest tests based on changes implemented within PM-2130 * [PM-2100] Fixing autofill mocks * [PM-2100] Fixing AutofillService jest tests * [PM-2100] Handling missing tests within coverage of AutofillService * [PM-2100] Handling missing tests within coverage of AutofillService.generateLoginFillScript * [PM-2100] Writing tests for AutofillService.generateCardFillScript * [PM-2100] Finalizing tests for AutofillService.generateCardFillScript * [PM-2100] Adding additional tests to cover changes introduced by TOTOP autofill PR * [PM-2100] Adding jest tests for Autofill.generateIdentityFillScript * [PM-2100] Finalizing tests for AutofillService.generateIdentityFillScript * [PM-2100] Implementing tests for AutofillService * [PM-2130] Adding a comment explaining a fix for Safari * [PM-2130] Adding a comment explaining a fix for Safari * [PM-2100] Implementing tests for AutofillService.loadPasswordFields * [PM-2100] Implementing tests for AutofillService.findUsernameField * [PM-2100] Implementing tests for AutofillService.findTotpField * [PM-2100] Implementing tests for AutofillService.fieldPropertyIsPrefixMatch * [PM-2100] Finalizing tests for AutofillService * [PM-2747] Add Support for Feature Flag of Autofill Version * [PM-2747] Adding Support for Manifest v3 within the implementation * [PM-2747] Modifying how the feature flag for autofill is named * [PM-2747] Modifying main.background.ts to load the ConfigApiService correctly * [PM-2747] Refactoring trigger of autofill scripts to be a simple immediately invoked function * [PM-2100] Modyfing placement of autofill-mocks * [PM-2100] Modyfing placement of autofill-mocks * [PM-2100] Removal of jest transform declaration * [PM-2130] Applying changes required for PM-2762 to implementation, and ensuring jest tests exist to validate the behavior * [PM-2747] Modifying how we inject the autofill scripts to ensure we are injecting into all frames within a page * [PM-2130] Removing usage of IntersectionObserver when identifying element visibility due to broken interactions with React Components * [PM-2130] Fixing issue found when attempting to capture the elementAtCenterPoint in determining file visibility * [PM-2100] Create Unit Test Suite for autofill.service.ts (#5371) * [PM-2100] Create Unit Test Suite for Autofill.service.ts * [PM-2100] Finishing out tests for the getFormsWithPasswordFields method * [PM-2100] Implementing tests for the doAutofill method within the autofill service * [PM-2100] Working through implementation of doAutofill method * [PM-2100] Working through implementation of doAutofill method * [PM-2100] Finishing implementatino of isUntrustedIframe method within autofill service * [PM-2100] Finishing implementation of doAutoFill method within autofill service * [PM-2100] Finishing implementation of doAutoFillOnTab method within autofill service * [PM-2100] Working through tests for generateFillScript * [PM-2100] Finalizing generateFillScript method testing * [PM-2100] Starting implementation of generateLoginFillScript * [PM-2100] Working through tests for generateLoginFillScript * [PM-2100] Finalizing generateLoginFillScript method testing * [PM-2100] Removing unnecessary jest config file * [PM-2100] Fixing jest tests based on changes implemented within PM-2130 * [PM-2100] Fixing autofill mocks * [PM-2100] Fixing AutofillService jest tests * [PM-2100] Handling missing tests within coverage of AutofillService * [PM-2100] Handling missing tests within coverage of AutofillService.generateLoginFillScript * [PM-2100] Writing tests for AutofillService.generateCardFillScript * [PM-2100] Finalizing tests for AutofillService.generateCardFillScript * [PM-2100] Adding additional tests to cover changes introduced by TOTOP autofill PR * [PM-2100] Adding jest tests for Autofill.generateIdentityFillScript * [PM-2100] Finalizing tests for AutofillService.generateIdentityFillScript * [PM-2100] Implementing tests for AutofillService * [PM-2100] Implementing tests for AutofillService.loadPasswordFields * [PM-2100] Implementing tests for AutofillService.findUsernameField * [PM-2100] Implementing tests for AutofillService.findTotpField * [PM-2100] Implementing tests for AutofillService.fieldPropertyIsPrefixMatch * [PM-2100] Finalizing tests for AutofillService * [PM-2100] Modyfing placement of autofill-mocks * [PM-2100] Modyfing placement of autofill-mocks * [PM-2100] Removal of jest transform declaration * [PM-2747] Applying a fix for a race condition that can occur when loading the notification bar and autofiller script login * [PM-2747] Reverting removal of autofill npm action. Now this will force usage of autofill-v2 regardless of whether a feature flag is set or not * [PM-2747] Fixing logic error incorporated when merging in master * [PM-2130] Fixing issue with autofill service unit tests * [PM-2130] Fixing issue with autofill service unit tests * [PM-2747] Fixing issue present with notification bar merge * [PM-2130] Fixing test test for when we need to handle a password reprompt * [PM-2747] Fixing wording for webpack script * [PM-2747] Addressing stylistic changes requested from code review * [PM-2747] Addressing stylistic changes requested from code review --------- Co-authored-by: Jonathan Prusik <jprusik@classynemesis.com> Co-authored-by: Manuel <mr-manuel@outlook.it> Co-authored-by: Jonathan Prusik <jprusik@users.noreply.github.com> * [PM-3285] Applying stylistic changes suggested by code review for the feature flag implementation * [PM-3285] Adding temporary console log to validate which version is being used * [PM-3285] Removing temporary console log indicating which version of autofill the user is currently loading --------- Co-authored-by: Jonathan Prusik <jprusik@users.noreply.github.com> Co-authored-by: Manuel <mr-manuel@outlook.it> Co-authored-by: Jonathan Prusik <jprusik@classynemesis.com>
2023-09-07 22:33:04 +02:00
if (document.readyState === "loading") {
document.addEventListener("DOMContentLoaded", loadNotificationBar);
} else {
loadNotificationBar();
}
2021-12-21 15:43:35 +01:00
[PM-3285] Autofill v2 Feature Branch (#5939) * [PM-3285] Autofill v2 Feature Branch * [PM-2130] - Audit, Modularize, and Refactor Core autofill.js File (#5453) * split up autofill.ts, first pass * remove modification tracking comments * lessen and localize eslint disables * additional typing and formatting * update autofill v2 with PR #5364 changes (update/i18n confirm dialogs) * update autofill v2 with PR #4155 changes (add autofill support for textarea) Co-Authored-By: Manuel <mr-manuel@outlook.it> * move commonly used string values to constants * ts cleanup * [PM-2130] Starting work to re-architect autofillv2.ts * [PM-2130] Starting work to re-architect autofillv2.ts * [PM-2130] Working through autofill collect method * [PM-2130] Marking Removal of documentUUID as dead code * [PM-2130] Refining the implementation of collect and moving broken out utils back into class implementation * [PM-2130] Applying small refactors to AutofillCollect * [PM-2130] Refining the implementation of getAutofillFieldLabelTag to help with readability of the method * [PM-2130] Implementing jest tests for AutofillCollect methods * [PM-2130] Refining implementation for AutofillCollect * [PM-2200] Unit tests for autofill content script utilities with slight refactors (#5544) * add unit tests for urlNotSecure * add test coverage command * add unit tests for canSeeElementToStyle * canSeeElementToStyle should not return true if `animateTheFilling` or `currentEl` is false * add tests for selectAllFromDoc and getElementByOpId * clean up getElementByOpId * address some typing issues * add tests for setValueForElementByEvent, setValueForElement, and doSimpleSetByQuery * clean up setValueForElement and setValueForElementByEvent * more typescript cleanup * add tests for doClickByOpId and touchAllPasswordFields * add tests for doFocusByOpId and doClickByQuery * misc fill cleanup * move functions between collect and fill utils and replace getElementForOPID for duplicate getElementByOpId * add tests for isKnownTag and isElementVisible * rename addProp and remove redundant focusElement in favor of doFocusElement * cleanup * fix checkNodeType * add tests for shiftForLeftLabel * clean up and rename checkNodeType, isKnownTag, and shiftForLeftLabel * add tests for getFormElements * clean up getFormElements * add tests for getElementAttrValue, getElementValue, getSelectElementOptions, getLabelTop, and queryDoc * clean up and rename queryDoc to queryDocument * misc cleanup and rename getElementAttrValue to getPropertyOrAttribute * rebase cleanup * prettier formatting * [PM-2130] Fixing linting issues * [PM-2130] Fixing linting issues * [PM-2130] Migrating implementation for collect methods and tests for those methods into AutofillCollect context * [PM-2130] Migrating getPropertyOrAttribute method from utils to AutofillCollect * [PM-2130] Continuing migration of methods from collect utils into AutofillCollect * [PM-2130] Rework of isViewable method to better handle behavior for how we identify if an element is currently within the viewport * [PM-2130] Filling out implementation of autofill-insert * [PM-2130] Refining AutofillInsert * [PM-2130] Implementing jest tests for AutofillCollect methods and breaking out visibility related logic to a separate service * [PM-2130] Fixing jest tests for AutofillCollect * [PM-2130] Fixing jest tests for AutofillInit * [PM-2130] Adjusting how the AutofillFieldVisibilityService class is used in AutofillCollect * [PM-2130] Working through AutofillInsert implementation * [PM-2130] Migrating methods from fill.ts to AutofillInsert * [PM-2130] Migrating methods from fill.ts to AutofillInsert * [PM-2130] Applying fix for IntersectionObserver when triggering behavior in Safari and fixing issue with how we trigger an input event shortly after filling in a field * [PM-2130] Refactoring AutofillCollect to service CollectAutofillContentService * [PM-2130] Refactoring AutofillInsert to service InsertAutofillContentService * [PM-2130] Further organization of implementation * [PM-2130] Filling out missing jest test for AutofillInit.fillForm method * [PM-2130] Migrating the last of the collect jest tests to InsertAutofillContentService * [PM-2130] Further refactoring of elements including typing information * [PM-2130] Implementing jest tests for InsertAutofillContentService * [PM-2130] Implementing jest tests for InsertAutofillContentService * [PM-2130] Organization and refactoring of methods within InsertAutofillContent * [PM-2130] Implementation of jest tests for InsertAutofillContentService * [PM-2130] Implementation of Jest Test for IntertAutofillContentService * [PM-2130] Finalizing migration of methods and jest tests from util files into Autofill serivces * [PM-2130] Cleaning up dead code comments * [PM-2130] Removing unnecessary constants * [PM-2130] Finalizing jest tests for InsertAutofillContentService * [PM-2130] Refactoring FieldVisibiltyService to DomElementVisibilityService to allow service to act in a more general manner * [PM-2130] Implementing jest tests for DomElementVisibilityService * [PM-2130] Implementing jest tests for DomElementVisibilityService * [PM-2130] Implementing jest tests for DomElementVisibilityService * [PM-2130] Implementing jest tests for DomElementVisibilityService * [PM-2130] Breaking out the callback method used to resolve the IntersectionObserver promise * [PM-2130] Adding a comment explaining a fix for Safari * [PM-2130] Adding a comment explaining a fix for Safari * [PM-2130] Applying changes required for PM-2762 to implementation, and ensuring jest tests exist to validate the behavior * [PM-2130] Removing usage of IntersectionObserver when identifying element visibility due to broken interactions with React Components * [PM-2130] Fixing issue found when attempting to capture the elementAtCenterPoint in determining file visibility * [PM-2100] Create Unit Test Suite for autofill.service.ts (#5371) * [PM-2100] Create Unit Test Suite for Autofill.service.ts * [PM-2100] Finishing out tests for the getFormsWithPasswordFields method * [PM-2100] Implementing tests for the doAutofill method within the autofill service * [PM-2100] Working through implementation of doAutofill method * [PM-2100] Working through implementation of doAutofill method * [PM-2100] Finishing implementatino of isUntrustedIframe method within autofill service * [PM-2100] Finishing implementation of doAutoFill method within autofill service * [PM-2100] Finishing implementation of doAutoFillOnTab method within autofill service * [PM-2100] Working through tests for generateFillScript * [PM-2100] Finalizing generateFillScript method testing * [PM-2100] Starting implementation of generateLoginFillScript * [PM-2100] Working through tests for generateLoginFillScript * [PM-2100] Finalizing generateLoginFillScript method testing * [PM-2100] Removing unnecessary jest config file * [PM-2100] Fixing jest tests based on changes implemented within PM-2130 * [PM-2100] Fixing autofill mocks * [PM-2100] Fixing AutofillService jest tests * [PM-2100] Handling missing tests within coverage of AutofillService * [PM-2100] Handling missing tests within coverage of AutofillService.generateLoginFillScript * [PM-2100] Writing tests for AutofillService.generateCardFillScript * [PM-2100] Finalizing tests for AutofillService.generateCardFillScript * [PM-2100] Adding additional tests to cover changes introduced by TOTOP autofill PR * [PM-2100] Adding jest tests for Autofill.generateIdentityFillScript * [PM-2100] Finalizing tests for AutofillService.generateIdentityFillScript * [PM-2100] Implementing tests for AutofillService * [PM-2100] Implementing tests for AutofillService.loadPasswordFields * [PM-2100] Implementing tests for AutofillService.findUsernameField * [PM-2100] Implementing tests for AutofillService.findTotpField * [PM-2100] Implementing tests for AutofillService.fieldPropertyIsPrefixMatch * [PM-2100] Finalizing tests for AutofillService * [PM-2100] Modyfing placement of autofill-mocks * [PM-2100] Modyfing placement of autofill-mocks * [PM-2100] Removal of jest transform declaration * [PM-2130] Fixing issue with autofill service unit tests * [PM-2130] Fixing issue with autofill service unit tests * [PM-2130] Fixing test test for when we need to handle a password reprompt --------- Co-authored-by: Manuel <mr-manuel@outlook.it> Co-authored-by: Cesar Gonzalez <cgonzalez@bitwarden.com> Co-authored-by: Cesar Gonzalez <cesar.a.gonzalezcs@gmail.com> * [PM-3285] Migrating Changes from PM-1407 into autofill v2 refactor implementation * [PM-2747] Add Support for Feature Flag of Autofill Version (#5695) * [PM-2100] Create Unit Test Suite for Autofill.service.ts * [PM-2100] Finishing out tests for the getFormsWithPasswordFields method * [PM-2100] Implementing tests for the doAutofill method within the autofill service * [PM-2100] Working through implementation of doAutofill method * [PM-2100] Working through implementation of doAutofill method * [PM-2100] Finishing implementatino of isUntrustedIframe method within autofill service * [PM-2100] Finishing implementation of doAutoFill method within autofill service * [PM-2100] Finishing implementation of doAutoFillOnTab method within autofill service * [PM-2100] Working through tests for generateFillScript * split up autofill.ts, first pass * remove modification tracking comments * lessen and localize eslint disables * additional typing and formatting * update autofill v2 with PR #5364 changes (update/i18n confirm dialogs) * update autofill v2 with PR #4155 changes (add autofill support for textarea) Co-Authored-By: Manuel <mr-manuel@outlook.it> * move commonly used string values to constants * ts cleanup * [PM-2100] Finalizing generateFillScript method testing * [PM-2100] Starting implementation of generateLoginFillScript * [PM-2100] Working through tests for generateLoginFillScript * [PM-2100] Finalizing generateLoginFillScript method testing * [PM-2130] Starting work to re-architect autofillv2.ts * [PM-2130] Starting work to re-architect autofillv2.ts * [PM-2130] Working through autofill collect method * [PM-2130] Marking Removal of documentUUID as dead code * [PM-2130] Refining the implementation of collect and moving broken out utils back into class implementation * [PM-2130] Applying small refactors to AutofillCollect * [PM-2130] Refining the implementation of getAutofillFieldLabelTag to help with readability of the method * [PM-2130] Implementing jest tests for AutofillCollect methods * [PM-2130] Refining implementation for AutofillCollect * [PM-2200] Unit tests for autofill content script utilities with slight refactors (#5544) * add unit tests for urlNotSecure * add test coverage command * add unit tests for canSeeElementToStyle * canSeeElementToStyle should not return true if `animateTheFilling` or `currentEl` is false * add tests for selectAllFromDoc and getElementByOpId * clean up getElementByOpId * address some typing issues * add tests for setValueForElementByEvent, setValueForElement, and doSimpleSetByQuery * clean up setValueForElement and setValueForElementByEvent * more typescript cleanup * add tests for doClickByOpId and touchAllPasswordFields * add tests for doFocusByOpId and doClickByQuery * misc fill cleanup * move functions between collect and fill utils and replace getElementForOPID for duplicate getElementByOpId * add tests for isKnownTag and isElementVisible * rename addProp and remove redundant focusElement in favor of doFocusElement * cleanup * fix checkNodeType * add tests for shiftForLeftLabel * clean up and rename checkNodeType, isKnownTag, and shiftForLeftLabel * add tests for getFormElements * clean up getFormElements * add tests for getElementAttrValue, getElementValue, getSelectElementOptions, getLabelTop, and queryDoc * clean up and rename queryDoc to queryDocument * misc cleanup and rename getElementAttrValue to getPropertyOrAttribute * rebase cleanup * prettier formatting * [PM-2130] Fixing linting issues * [PM-2130] Fixing linting issues * [PM-2130] Migrating implementation for collect methods and tests for those methods into AutofillCollect context * [PM-2130] Migrating getPropertyOrAttribute method from utils to AutofillCollect * [PM-2130] Continuing migration of methods from collect utils into AutofillCollect * [PM-2130] Rework of isViewable method to better handle behavior for how we identify if an element is currently within the viewport * [PM-2130] Filling out implementation of autofill-insert * [PM-2130] Refining AutofillInsert * [PM-2130] Implementing jest tests for AutofillCollect methods and breaking out visibility related logic to a separate service * [PM-2130] Fixing jest tests for AutofillCollect * [PM-2130] Fixing jest tests for AutofillInit * [PM-2130] Adjusting how the AutofillFieldVisibilityService class is used in AutofillCollect * [PM-2130] Working through AutofillInsert implementation * [PM-2130] Migrating methods from fill.ts to AutofillInsert * [PM-2130] Migrating methods from fill.ts to AutofillInsert * [PM-2130] Applying fix for IntersectionObserver when triggering behavior in Safari and fixing issue with how we trigger an input event shortly after filling in a field * [PM-2130] Refactoring AutofillCollect to service CollectAutofillContentService * [PM-2130] Refactoring AutofillInsert to service InsertAutofillContentService * [PM-2130] Further organization of implementation * [PM-2130] Filling out missing jest test for AutofillInit.fillForm method * [PM-2130] Migrating the last of the collect jest tests to InsertAutofillContentService * [PM-2130] Further refactoring of elements including typing information * [PM-2130] Implementing jest tests for InsertAutofillContentService * [PM-2130] Implementing jest tests for InsertAutofillContentService * [PM-2130] Organization and refactoring of methods within InsertAutofillContent * [PM-2130] Implementation of jest tests for InsertAutofillContentService * [PM-2130] Implementation of Jest Test for IntertAutofillContentService * [PM-2130] Finalizing migration of methods and jest tests from util files into Autofill serivces * [PM-2130] Cleaning up dead code comments * [PM-2130] Removing unnecessary constants * [PM-2130] Finalizing jest tests for InsertAutofillContentService * [PM-2130] Refactoring FieldVisibiltyService to DomElementVisibilityService to allow service to act in a more general manner * [PM-2130] Implementing jest tests for DomElementVisibilityService * [PM-2130] Implementing jest tests for DomElementVisibilityService * [PM-2130] Implementing jest tests for DomElementVisibilityService * [PM-2130] Implementing jest tests for DomElementVisibilityService * [PM-2130] Breaking out the callback method used to resolve the IntersectionObserver promise * [PM-2100] Removing unnecessary jest config file * [PM-2100] Fixing jest tests based on changes implemented within PM-2130 * [PM-2100] Fixing autofill mocks * [PM-2100] Fixing AutofillService jest tests * [PM-2100] Handling missing tests within coverage of AutofillService * [PM-2100] Handling missing tests within coverage of AutofillService.generateLoginFillScript * [PM-2100] Writing tests for AutofillService.generateCardFillScript * [PM-2100] Finalizing tests for AutofillService.generateCardFillScript * [PM-2100] Adding additional tests to cover changes introduced by TOTOP autofill PR * [PM-2100] Adding jest tests for Autofill.generateIdentityFillScript * [PM-2100] Finalizing tests for AutofillService.generateIdentityFillScript * [PM-2100] Implementing tests for AutofillService * [PM-2130] Adding a comment explaining a fix for Safari * [PM-2130] Adding a comment explaining a fix for Safari * [PM-2100] Implementing tests for AutofillService.loadPasswordFields * [PM-2100] Implementing tests for AutofillService.findUsernameField * [PM-2100] Implementing tests for AutofillService.findTotpField * [PM-2100] Implementing tests for AutofillService.fieldPropertyIsPrefixMatch * [PM-2100] Finalizing tests for AutofillService * [PM-2747] Add Support for Feature Flag of Autofill Version * [PM-2747] Adding Support for Manifest v3 within the implementation * [PM-2747] Modifying how the feature flag for autofill is named * [PM-2747] Modifying main.background.ts to load the ConfigApiService correctly * [PM-2747] Refactoring trigger of autofill scripts to be a simple immediately invoked function * [PM-2100] Modyfing placement of autofill-mocks * [PM-2100] Modyfing placement of autofill-mocks * [PM-2100] Removal of jest transform declaration * [PM-2130] Applying changes required for PM-2762 to implementation, and ensuring jest tests exist to validate the behavior * [PM-2747] Modifying how we inject the autofill scripts to ensure we are injecting into all frames within a page * [PM-2130] Removing usage of IntersectionObserver when identifying element visibility due to broken interactions with React Components * [PM-2130] Fixing issue found when attempting to capture the elementAtCenterPoint in determining file visibility * [PM-2100] Create Unit Test Suite for autofill.service.ts (#5371) * [PM-2100] Create Unit Test Suite for Autofill.service.ts * [PM-2100] Finishing out tests for the getFormsWithPasswordFields method * [PM-2100] Implementing tests for the doAutofill method within the autofill service * [PM-2100] Working through implementation of doAutofill method * [PM-2100] Working through implementation of doAutofill method * [PM-2100] Finishing implementatino of isUntrustedIframe method within autofill service * [PM-2100] Finishing implementation of doAutoFill method within autofill service * [PM-2100] Finishing implementation of doAutoFillOnTab method within autofill service * [PM-2100] Working through tests for generateFillScript * [PM-2100] Finalizing generateFillScript method testing * [PM-2100] Starting implementation of generateLoginFillScript * [PM-2100] Working through tests for generateLoginFillScript * [PM-2100] Finalizing generateLoginFillScript method testing * [PM-2100] Removing unnecessary jest config file * [PM-2100] Fixing jest tests based on changes implemented within PM-2130 * [PM-2100] Fixing autofill mocks * [PM-2100] Fixing AutofillService jest tests * [PM-2100] Handling missing tests within coverage of AutofillService * [PM-2100] Handling missing tests within coverage of AutofillService.generateLoginFillScript * [PM-2100] Writing tests for AutofillService.generateCardFillScript * [PM-2100] Finalizing tests for AutofillService.generateCardFillScript * [PM-2100] Adding additional tests to cover changes introduced by TOTOP autofill PR * [PM-2100] Adding jest tests for Autofill.generateIdentityFillScript * [PM-2100] Finalizing tests for AutofillService.generateIdentityFillScript * [PM-2100] Implementing tests for AutofillService * [PM-2100] Implementing tests for AutofillService.loadPasswordFields * [PM-2100] Implementing tests for AutofillService.findUsernameField * [PM-2100] Implementing tests for AutofillService.findTotpField * [PM-2100] Implementing tests for AutofillService.fieldPropertyIsPrefixMatch * [PM-2100] Finalizing tests for AutofillService * [PM-2100] Modyfing placement of autofill-mocks * [PM-2100] Modyfing placement of autofill-mocks * [PM-2100] Removal of jest transform declaration * [PM-2747] Applying a fix for a race condition that can occur when loading the notification bar and autofiller script login * [PM-2747] Reverting removal of autofill npm action. Now this will force usage of autofill-v2 regardless of whether a feature flag is set or not * [PM-2747] Fixing logic error incorporated when merging in master * [PM-2130] Fixing issue with autofill service unit tests * [PM-2130] Fixing issue with autofill service unit tests * [PM-2747] Fixing issue present with notification bar merge * [PM-2130] Fixing test test for when we need to handle a password reprompt * [PM-2747] Fixing wording for webpack script * [PM-2747] Addressing stylistic changes requested from code review * [PM-2747] Addressing stylistic changes requested from code review --------- Co-authored-by: Jonathan Prusik <jprusik@classynemesis.com> Co-authored-by: Manuel <mr-manuel@outlook.it> Co-authored-by: Jonathan Prusik <jprusik@users.noreply.github.com> * [PM-3285] Applying stylistic changes suggested by code review for the feature flag implementation * [PM-3285] Adding temporary console log to validate which version is being used * [PM-3285] Removing temporary console log indicating which version of autofill the user is currently loading --------- Co-authored-by: Jonathan Prusik <jprusik@users.noreply.github.com> Co-authored-by: Manuel <mr-manuel@outlook.it> Co-authored-by: Jonathan Prusik <jprusik@classynemesis.com>
2023-09-07 22:33:04 +02:00
async function loadNotificationBar() {
[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;
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();
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",
]);
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
]);
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
[PM-3285] Autofill v2 Feature Branch (#5939) * [PM-3285] Autofill v2 Feature Branch * [PM-2130] - Audit, Modularize, and Refactor Core autofill.js File (#5453) * split up autofill.ts, first pass * remove modification tracking comments * lessen and localize eslint disables * additional typing and formatting * update autofill v2 with PR #5364 changes (update/i18n confirm dialogs) * update autofill v2 with PR #4155 changes (add autofill support for textarea) Co-Authored-By: Manuel <mr-manuel@outlook.it> * move commonly used string values to constants * ts cleanup * [PM-2130] Starting work to re-architect autofillv2.ts * [PM-2130] Starting work to re-architect autofillv2.ts * [PM-2130] Working through autofill collect method * [PM-2130] Marking Removal of documentUUID as dead code * [PM-2130] Refining the implementation of collect and moving broken out utils back into class implementation * [PM-2130] Applying small refactors to AutofillCollect * [PM-2130] Refining the implementation of getAutofillFieldLabelTag to help with readability of the method * [PM-2130] Implementing jest tests for AutofillCollect methods * [PM-2130] Refining implementation for AutofillCollect * [PM-2200] Unit tests for autofill content script utilities with slight refactors (#5544) * add unit tests for urlNotSecure * add test coverage command * add unit tests for canSeeElementToStyle * canSeeElementToStyle should not return true if `animateTheFilling` or `currentEl` is false * add tests for selectAllFromDoc and getElementByOpId * clean up getElementByOpId * address some typing issues * add tests for setValueForElementByEvent, setValueForElement, and doSimpleSetByQuery * clean up setValueForElement and setValueForElementByEvent * more typescript cleanup * add tests for doClickByOpId and touchAllPasswordFields * add tests for doFocusByOpId and doClickByQuery * misc fill cleanup * move functions between collect and fill utils and replace getElementForOPID for duplicate getElementByOpId * add tests for isKnownTag and isElementVisible * rename addProp and remove redundant focusElement in favor of doFocusElement * cleanup * fix checkNodeType * add tests for shiftForLeftLabel * clean up and rename checkNodeType, isKnownTag, and shiftForLeftLabel * add tests for getFormElements * clean up getFormElements * add tests for getElementAttrValue, getElementValue, getSelectElementOptions, getLabelTop, and queryDoc * clean up and rename queryDoc to queryDocument * misc cleanup and rename getElementAttrValue to getPropertyOrAttribute * rebase cleanup * prettier formatting * [PM-2130] Fixing linting issues * [PM-2130] Fixing linting issues * [PM-2130] Migrating implementation for collect methods and tests for those methods into AutofillCollect context * [PM-2130] Migrating getPropertyOrAttribute method from utils to AutofillCollect * [PM-2130] Continuing migration of methods from collect utils into AutofillCollect * [PM-2130] Rework of isViewable method to better handle behavior for how we identify if an element is currently within the viewport * [PM-2130] Filling out implementation of autofill-insert * [PM-2130] Refining AutofillInsert * [PM-2130] Implementing jest tests for AutofillCollect methods and breaking out visibility related logic to a separate service * [PM-2130] Fixing jest tests for AutofillCollect * [PM-2130] Fixing jest tests for AutofillInit * [PM-2130] Adjusting how the AutofillFieldVisibilityService class is used in AutofillCollect * [PM-2130] Working through AutofillInsert implementation * [PM-2130] Migrating methods from fill.ts to AutofillInsert * [PM-2130] Migrating methods from fill.ts to AutofillInsert * [PM-2130] Applying fix for IntersectionObserver when triggering behavior in Safari and fixing issue with how we trigger an input event shortly after filling in a field * [PM-2130] Refactoring AutofillCollect to service CollectAutofillContentService * [PM-2130] Refactoring AutofillInsert to service InsertAutofillContentService * [PM-2130] Further organization of implementation * [PM-2130] Filling out missing jest test for AutofillInit.fillForm method * [PM-2130] Migrating the last of the collect jest tests to InsertAutofillContentService * [PM-2130] Further refactoring of elements including typing information * [PM-2130] Implementing jest tests for InsertAutofillContentService * [PM-2130] Implementing jest tests for InsertAutofillContentService * [PM-2130] Organization and refactoring of methods within InsertAutofillContent * [PM-2130] Implementation of jest tests for InsertAutofillContentService * [PM-2130] Implementation of Jest Test for IntertAutofillContentService * [PM-2130] Finalizing migration of methods and jest tests from util files into Autofill serivces * [PM-2130] Cleaning up dead code comments * [PM-2130] Removing unnecessary constants * [PM-2130] Finalizing jest tests for InsertAutofillContentService * [PM-2130] Refactoring FieldVisibiltyService to DomElementVisibilityService to allow service to act in a more general manner * [PM-2130] Implementing jest tests for DomElementVisibilityService * [PM-2130] Implementing jest tests for DomElementVisibilityService * [PM-2130] Implementing jest tests for DomElementVisibilityService * [PM-2130] Implementing jest tests for DomElementVisibilityService * [PM-2130] Breaking out the callback method used to resolve the IntersectionObserver promise * [PM-2130] Adding a comment explaining a fix for Safari * [PM-2130] Adding a comment explaining a fix for Safari * [PM-2130] Applying changes required for PM-2762 to implementation, and ensuring jest tests exist to validate the behavior * [PM-2130] Removing usage of IntersectionObserver when identifying element visibility due to broken interactions with React Components * [PM-2130] Fixing issue found when attempting to capture the elementAtCenterPoint in determining file visibility * [PM-2100] Create Unit Test Suite for autofill.service.ts (#5371) * [PM-2100] Create Unit Test Suite for Autofill.service.ts * [PM-2100] Finishing out tests for the getFormsWithPasswordFields method * [PM-2100] Implementing tests for the doAutofill method within the autofill service * [PM-2100] Working through implementation of doAutofill method * [PM-2100] Working through implementation of doAutofill method * [PM-2100] Finishing implementatino of isUntrustedIframe method within autofill service * [PM-2100] Finishing implementation of doAutoFill method within autofill service * [PM-2100] Finishing implementation of doAutoFillOnTab method within autofill service * [PM-2100] Working through tests for generateFillScript * [PM-2100] Finalizing generateFillScript method testing * [PM-2100] Starting implementation of generateLoginFillScript * [PM-2100] Working through tests for generateLoginFillScript * [PM-2100] Finalizing generateLoginFillScript method testing * [PM-2100] Removing unnecessary jest config file * [PM-2100] Fixing jest tests based on changes implemented within PM-2130 * [PM-2100] Fixing autofill mocks * [PM-2100] Fixing AutofillService jest tests * [PM-2100] Handling missing tests within coverage of AutofillService * [PM-2100] Handling missing tests within coverage of AutofillService.generateLoginFillScript * [PM-2100] Writing tests for AutofillService.generateCardFillScript * [PM-2100] Finalizing tests for AutofillService.generateCardFillScript * [PM-2100] Adding additional tests to cover changes introduced by TOTOP autofill PR * [PM-2100] Adding jest tests for Autofill.generateIdentityFillScript * [PM-2100] Finalizing tests for AutofillService.generateIdentityFillScript * [PM-2100] Implementing tests for AutofillService * [PM-2100] Implementing tests for AutofillService.loadPasswordFields * [PM-2100] Implementing tests for AutofillService.findUsernameField * [PM-2100] Implementing tests for AutofillService.findTotpField * [PM-2100] Implementing tests for AutofillService.fieldPropertyIsPrefixMatch * [PM-2100] Finalizing tests for AutofillService * [PM-2100] Modyfing placement of autofill-mocks * [PM-2100] Modyfing placement of autofill-mocks * [PM-2100] Removal of jest transform declaration * [PM-2130] Fixing issue with autofill service unit tests * [PM-2130] Fixing issue with autofill service unit tests * [PM-2130] Fixing test test for when we need to handle a password reprompt --------- Co-authored-by: Manuel <mr-manuel@outlook.it> Co-authored-by: Cesar Gonzalez <cgonzalez@bitwarden.com> Co-authored-by: Cesar Gonzalez <cesar.a.gonzalezcs@gmail.com> * [PM-3285] Migrating Changes from PM-1407 into autofill v2 refactor implementation * [PM-2747] Add Support for Feature Flag of Autofill Version (#5695) * [PM-2100] Create Unit Test Suite for Autofill.service.ts * [PM-2100] Finishing out tests for the getFormsWithPasswordFields method * [PM-2100] Implementing tests for the doAutofill method within the autofill service * [PM-2100] Working through implementation of doAutofill method * [PM-2100] Working through implementation of doAutofill method * [PM-2100] Finishing implementatino of isUntrustedIframe method within autofill service * [PM-2100] Finishing implementation of doAutoFill method within autofill service * [PM-2100] Finishing implementation of doAutoFillOnTab method within autofill service * [PM-2100] Working through tests for generateFillScript * split up autofill.ts, first pass * remove modification tracking comments * lessen and localize eslint disables * additional typing and formatting * update autofill v2 with PR #5364 changes (update/i18n confirm dialogs) * update autofill v2 with PR #4155 changes (add autofill support for textarea) Co-Authored-By: Manuel <mr-manuel@outlook.it> * move commonly used string values to constants * ts cleanup * [PM-2100] Finalizing generateFillScript method testing * [PM-2100] Starting implementation of generateLoginFillScript * [PM-2100] Working through tests for generateLoginFillScript * [PM-2100] Finalizing generateLoginFillScript method testing * [PM-2130] Starting work to re-architect autofillv2.ts * [PM-2130] Starting work to re-architect autofillv2.ts * [PM-2130] Working through autofill collect method * [PM-2130] Marking Removal of documentUUID as dead code * [PM-2130] Refining the implementation of collect and moving broken out utils back into class implementation * [PM-2130] Applying small refactors to AutofillCollect * [PM-2130] Refining the implementation of getAutofillFieldLabelTag to help with readability of the method * [PM-2130] Implementing jest tests for AutofillCollect methods * [PM-2130] Refining implementation for AutofillCollect * [PM-2200] Unit tests for autofill content script utilities with slight refactors (#5544) * add unit tests for urlNotSecure * add test coverage command * add unit tests for canSeeElementToStyle * canSeeElementToStyle should not return true if `animateTheFilling` or `currentEl` is false * add tests for selectAllFromDoc and getElementByOpId * clean up getElementByOpId * address some typing issues * add tests for setValueForElementByEvent, setValueForElement, and doSimpleSetByQuery * clean up setValueForElement and setValueForElementByEvent * more typescript cleanup * add tests for doClickByOpId and touchAllPasswordFields * add tests for doFocusByOpId and doClickByQuery * misc fill cleanup * move functions between collect and fill utils and replace getElementForOPID for duplicate getElementByOpId * add tests for isKnownTag and isElementVisible * rename addProp and remove redundant focusElement in favor of doFocusElement * cleanup * fix checkNodeType * add tests for shiftForLeftLabel * clean up and rename checkNodeType, isKnownTag, and shiftForLeftLabel * add tests for getFormElements * clean up getFormElements * add tests for getElementAttrValue, getElementValue, getSelectElementOptions, getLabelTop, and queryDoc * clean up and rename queryDoc to queryDocument * misc cleanup and rename getElementAttrValue to getPropertyOrAttribute * rebase cleanup * prettier formatting * [PM-2130] Fixing linting issues * [PM-2130] Fixing linting issues * [PM-2130] Migrating implementation for collect methods and tests for those methods into AutofillCollect context * [PM-2130] Migrating getPropertyOrAttribute method from utils to AutofillCollect * [PM-2130] Continuing migration of methods from collect utils into AutofillCollect * [PM-2130] Rework of isViewable method to better handle behavior for how we identify if an element is currently within the viewport * [PM-2130] Filling out implementation of autofill-insert * [PM-2130] Refining AutofillInsert * [PM-2130] Implementing jest tests for AutofillCollect methods and breaking out visibility related logic to a separate service * [PM-2130] Fixing jest tests for AutofillCollect * [PM-2130] Fixing jest tests for AutofillInit * [PM-2130] Adjusting how the AutofillFieldVisibilityService class is used in AutofillCollect * [PM-2130] Working through AutofillInsert implementation * [PM-2130] Migrating methods from fill.ts to AutofillInsert * [PM-2130] Migrating methods from fill.ts to AutofillInsert * [PM-2130] Applying fix for IntersectionObserver when triggering behavior in Safari and fixing issue with how we trigger an input event shortly after filling in a field * [PM-2130] Refactoring AutofillCollect to service CollectAutofillContentService * [PM-2130] Refactoring AutofillInsert to service InsertAutofillContentService * [PM-2130] Further organization of implementation * [PM-2130] Filling out missing jest test for AutofillInit.fillForm method * [PM-2130] Migrating the last of the collect jest tests to InsertAutofillContentService * [PM-2130] Further refactoring of elements including typing information * [PM-2130] Implementing jest tests for InsertAutofillContentService * [PM-2130] Implementing jest tests for InsertAutofillContentService * [PM-2130] Organization and refactoring of methods within InsertAutofillContent * [PM-2130] Implementation of jest tests for InsertAutofillContentService * [PM-2130] Implementation of Jest Test for IntertAutofillContentService * [PM-2130] Finalizing migration of methods and jest tests from util files into Autofill serivces * [PM-2130] Cleaning up dead code comments * [PM-2130] Removing unnecessary constants * [PM-2130] Finalizing jest tests for InsertAutofillContentService * [PM-2130] Refactoring FieldVisibiltyService to DomElementVisibilityService to allow service to act in a more general manner * [PM-2130] Implementing jest tests for DomElementVisibilityService * [PM-2130] Implementing jest tests for DomElementVisibilityService * [PM-2130] Implementing jest tests for DomElementVisibilityService * [PM-2130] Implementing jest tests for DomElementVisibilityService * [PM-2130] Breaking out the callback method used to resolve the IntersectionObserver promise * [PM-2100] Removing unnecessary jest config file * [PM-2100] Fixing jest tests based on changes implemented within PM-2130 * [PM-2100] Fixing autofill mocks * [PM-2100] Fixing AutofillService jest tests * [PM-2100] Handling missing tests within coverage of AutofillService * [PM-2100] Handling missing tests within coverage of AutofillService.generateLoginFillScript * [PM-2100] Writing tests for AutofillService.generateCardFillScript * [PM-2100] Finalizing tests for AutofillService.generateCardFillScript * [PM-2100] Adding additional tests to cover changes introduced by TOTOP autofill PR * [PM-2100] Adding jest tests for Autofill.generateIdentityFillScript * [PM-2100] Finalizing tests for AutofillService.generateIdentityFillScript * [PM-2100] Implementing tests for AutofillService * [PM-2130] Adding a comment explaining a fix for Safari * [PM-2130] Adding a comment explaining a fix for Safari * [PM-2100] Implementing tests for AutofillService.loadPasswordFields * [PM-2100] Implementing tests for AutofillService.findUsernameField * [PM-2100] Implementing tests for AutofillService.findTotpField * [PM-2100] Implementing tests for AutofillService.fieldPropertyIsPrefixMatch * [PM-2100] Finalizing tests for AutofillService * [PM-2747] Add Support for Feature Flag of Autofill Version * [PM-2747] Adding Support for Manifest v3 within the implementation * [PM-2747] Modifying how the feature flag for autofill is named * [PM-2747] Modifying main.background.ts to load the ConfigApiService correctly * [PM-2747] Refactoring trigger of autofill scripts to be a simple immediately invoked function * [PM-2100] Modyfing placement of autofill-mocks * [PM-2100] Modyfing placement of autofill-mocks * [PM-2100] Removal of jest transform declaration * [PM-2130] Applying changes required for PM-2762 to implementation, and ensuring jest tests exist to validate the behavior * [PM-2747] Modifying how we inject the autofill scripts to ensure we are injecting into all frames within a page * [PM-2130] Removing usage of IntersectionObserver when identifying element visibility due to broken interactions with React Components * [PM-2130] Fixing issue found when attempting to capture the elementAtCenterPoint in determining file visibility * [PM-2100] Create Unit Test Suite for autofill.service.ts (#5371) * [PM-2100] Create Unit Test Suite for Autofill.service.ts * [PM-2100] Finishing out tests for the getFormsWithPasswordFields method * [PM-2100] Implementing tests for the doAutofill method within the autofill service * [PM-2100] Working through implementation of doAutofill method * [PM-2100] Working through implementation of doAutofill method * [PM-2100] Finishing implementatino of isUntrustedIframe method within autofill service * [PM-2100] Finishing implementation of doAutoFill method within autofill service * [PM-2100] Finishing implementation of doAutoFillOnTab method within autofill service * [PM-2100] Working through tests for generateFillScript * [PM-2100] Finalizing generateFillScript method testing * [PM-2100] Starting implementation of generateLoginFillScript * [PM-2100] Working through tests for generateLoginFillScript * [PM-2100] Finalizing generateLoginFillScript method testing * [PM-2100] Removing unnecessary jest config file * [PM-2100] Fixing jest tests based on changes implemented within PM-2130 * [PM-2100] Fixing autofill mocks * [PM-2100] Fixing AutofillService jest tests * [PM-2100] Handling missing tests within coverage of AutofillService * [PM-2100] Handling missing tests within coverage of AutofillService.generateLoginFillScript * [PM-2100] Writing tests for AutofillService.generateCardFillScript * [PM-2100] Finalizing tests for AutofillService.generateCardFillScript * [PM-2100] Adding additional tests to cover changes introduced by TOTOP autofill PR * [PM-2100] Adding jest tests for Autofill.generateIdentityFillScript * [PM-2100] Finalizing tests for AutofillService.generateIdentityFillScript * [PM-2100] Implementing tests for AutofillService * [PM-2100] Implementing tests for AutofillService.loadPasswordFields * [PM-2100] Implementing tests for AutofillService.findUsernameField * [PM-2100] Implementing tests for AutofillService.findTotpField * [PM-2100] Implementing tests for AutofillService.fieldPropertyIsPrefixMatch * [PM-2100] Finalizing tests for AutofillService * [PM-2100] Modyfing placement of autofill-mocks * [PM-2100] Modyfing placement of autofill-mocks * [PM-2100] Removal of jest transform declaration * [PM-2747] Applying a fix for a race condition that can occur when loading the notification bar and autofiller script login * [PM-2747] Reverting removal of autofill npm action. Now this will force usage of autofill-v2 regardless of whether a feature flag is set or not * [PM-2747] Fixing logic error incorporated when merging in master * [PM-2130] Fixing issue with autofill service unit tests * [PM-2130] Fixing issue with autofill service unit tests * [PM-2747] Fixing issue present with notification bar merge * [PM-2130] Fixing test test for when we need to handle a password reprompt * [PM-2747] Fixing wording for webpack script * [PM-2747] Addressing stylistic changes requested from code review * [PM-2747] Addressing stylistic changes requested from code review --------- Co-authored-by: Jonathan Prusik <jprusik@classynemesis.com> Co-authored-by: Manuel <mr-manuel@outlook.it> Co-authored-by: Jonathan Prusik <jprusik@users.noreply.github.com> * [PM-3285] Applying stylistic changes suggested by code review for the feature flag implementation * [PM-3285] Adding temporary console log to validate which version is being used * [PM-3285] Removing temporary console log indicating which version of autofill the user is currently loading --------- Co-authored-by: Jonathan Prusik <jprusik@users.noreply.github.com> Co-authored-by: Manuel <mr-manuel@outlook.it> Co-authored-by: Jonathan Prusik <jprusik@classynemesis.com>
2023-09-07 22:33:04 +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.
let disabledAddLoginNotification = false;
let disabledChangedPasswordNotification = false;
let showNotificationBar = true;
// Look up the active user id from storage
const activeUserIdKey = "activeUserId";
let activeUserId: string;
const activeUserStorageValue = await getFromLocalStorage(activeUserIdKey);
if (activeUserStorageValue[activeUserIdKey]) {
activeUserId = activeUserStorageValue[activeUserIdKey];
}
// Look up the user's settings from storage
const userSettingsStorageValue = await getFromLocalStorage(activeUserId);
if (userSettingsStorageValue[activeUserId]) {
const userSettings: UserSettings = userSettingsStorageValue[activeUserId].settings;
const globalSettings: GlobalSettings = await getFromLocalStorage("global");
[PM-3285] Autofill v2 Feature Branch (#5939) * [PM-3285] Autofill v2 Feature Branch * [PM-2130] - Audit, Modularize, and Refactor Core autofill.js File (#5453) * split up autofill.ts, first pass * remove modification tracking comments * lessen and localize eslint disables * additional typing and formatting * update autofill v2 with PR #5364 changes (update/i18n confirm dialogs) * update autofill v2 with PR #4155 changes (add autofill support for textarea) Co-Authored-By: Manuel <mr-manuel@outlook.it> * move commonly used string values to constants * ts cleanup * [PM-2130] Starting work to re-architect autofillv2.ts * [PM-2130] Starting work to re-architect autofillv2.ts * [PM-2130] Working through autofill collect method * [PM-2130] Marking Removal of documentUUID as dead code * [PM-2130] Refining the implementation of collect and moving broken out utils back into class implementation * [PM-2130] Applying small refactors to AutofillCollect * [PM-2130] Refining the implementation of getAutofillFieldLabelTag to help with readability of the method * [PM-2130] Implementing jest tests for AutofillCollect methods * [PM-2130] Refining implementation for AutofillCollect * [PM-2200] Unit tests for autofill content script utilities with slight refactors (#5544) * add unit tests for urlNotSecure * add test coverage command * add unit tests for canSeeElementToStyle * canSeeElementToStyle should not return true if `animateTheFilling` or `currentEl` is false * add tests for selectAllFromDoc and getElementByOpId * clean up getElementByOpId * address some typing issues * add tests for setValueForElementByEvent, setValueForElement, and doSimpleSetByQuery * clean up setValueForElement and setValueForElementByEvent * more typescript cleanup * add tests for doClickByOpId and touchAllPasswordFields * add tests for doFocusByOpId and doClickByQuery * misc fill cleanup * move functions between collect and fill utils and replace getElementForOPID for duplicate getElementByOpId * add tests for isKnownTag and isElementVisible * rename addProp and remove redundant focusElement in favor of doFocusElement * cleanup * fix checkNodeType * add tests for shiftForLeftLabel * clean up and rename checkNodeType, isKnownTag, and shiftForLeftLabel * add tests for getFormElements * clean up getFormElements * add tests for getElementAttrValue, getElementValue, getSelectElementOptions, getLabelTop, and queryDoc * clean up and rename queryDoc to queryDocument * misc cleanup and rename getElementAttrValue to getPropertyOrAttribute * rebase cleanup * prettier formatting * [PM-2130] Fixing linting issues * [PM-2130] Fixing linting issues * [PM-2130] Migrating implementation for collect methods and tests for those methods into AutofillCollect context * [PM-2130] Migrating getPropertyOrAttribute method from utils to AutofillCollect * [PM-2130] Continuing migration of methods from collect utils into AutofillCollect * [PM-2130] Rework of isViewable method to better handle behavior for how we identify if an element is currently within the viewport * [PM-2130] Filling out implementation of autofill-insert * [PM-2130] Refining AutofillInsert * [PM-2130] Implementing jest tests for AutofillCollect methods and breaking out visibility related logic to a separate service * [PM-2130] Fixing jest tests for AutofillCollect * [PM-2130] Fixing jest tests for AutofillInit * [PM-2130] Adjusting how the AutofillFieldVisibilityService class is used in AutofillCollect * [PM-2130] Working through AutofillInsert implementation * [PM-2130] Migrating methods from fill.ts to AutofillInsert * [PM-2130] Migrating methods from fill.ts to AutofillInsert * [PM-2130] Applying fix for IntersectionObserver when triggering behavior in Safari and fixing issue with how we trigger an input event shortly after filling in a field * [PM-2130] Refactoring AutofillCollect to service CollectAutofillContentService * [PM-2130] Refactoring AutofillInsert to service InsertAutofillContentService * [PM-2130] Further organization of implementation * [PM-2130] Filling out missing jest test for AutofillInit.fillForm method * [PM-2130] Migrating the last of the collect jest tests to InsertAutofillContentService * [PM-2130] Further refactoring of elements including typing information * [PM-2130] Implementing jest tests for InsertAutofillContentService * [PM-2130] Implementing jest tests for InsertAutofillContentService * [PM-2130] Organization and refactoring of methods within InsertAutofillContent * [PM-2130] Implementation of jest tests for InsertAutofillContentService * [PM-2130] Implementation of Jest Test for IntertAutofillContentService * [PM-2130] Finalizing migration of methods and jest tests from util files into Autofill serivces * [PM-2130] Cleaning up dead code comments * [PM-2130] Removing unnecessary constants * [PM-2130] Finalizing jest tests for InsertAutofillContentService * [PM-2130] Refactoring FieldVisibiltyService to DomElementVisibilityService to allow service to act in a more general manner * [PM-2130] Implementing jest tests for DomElementVisibilityService * [PM-2130] Implementing jest tests for DomElementVisibilityService * [PM-2130] Implementing jest tests for DomElementVisibilityService * [PM-2130] Implementing jest tests for DomElementVisibilityService * [PM-2130] Breaking out the callback method used to resolve the IntersectionObserver promise * [PM-2130] Adding a comment explaining a fix for Safari * [PM-2130] Adding a comment explaining a fix for Safari * [PM-2130] Applying changes required for PM-2762 to implementation, and ensuring jest tests exist to validate the behavior * [PM-2130] Removing usage of IntersectionObserver when identifying element visibility due to broken interactions with React Components * [PM-2130] Fixing issue found when attempting to capture the elementAtCenterPoint in determining file visibility * [PM-2100] Create Unit Test Suite for autofill.service.ts (#5371) * [PM-2100] Create Unit Test Suite for Autofill.service.ts * [PM-2100] Finishing out tests for the getFormsWithPasswordFields method * [PM-2100] Implementing tests for the doAutofill method within the autofill service * [PM-2100] Working through implementation of doAutofill method * [PM-2100] Working through implementation of doAutofill method * [PM-2100] Finishing implementatino of isUntrustedIframe method within autofill service * [PM-2100] Finishing implementation of doAutoFill method within autofill service * [PM-2100] Finishing implementation of doAutoFillOnTab method within autofill service * [PM-2100] Working through tests for generateFillScript * [PM-2100] Finalizing generateFillScript method testing * [PM-2100] Starting implementation of generateLoginFillScript * [PM-2100] Working through tests for generateLoginFillScript * [PM-2100] Finalizing generateLoginFillScript method testing * [PM-2100] Removing unnecessary jest config file * [PM-2100] Fixing jest tests based on changes implemented within PM-2130 * [PM-2100] Fixing autofill mocks * [PM-2100] Fixing AutofillService jest tests * [PM-2100] Handling missing tests within coverage of AutofillService * [PM-2100] Handling missing tests within coverage of AutofillService.generateLoginFillScript * [PM-2100] Writing tests for AutofillService.generateCardFillScript * [PM-2100] Finalizing tests for AutofillService.generateCardFillScript * [PM-2100] Adding additional tests to cover changes introduced by TOTOP autofill PR * [PM-2100] Adding jest tests for Autofill.generateIdentityFillScript * [PM-2100] Finalizing tests for AutofillService.generateIdentityFillScript * [PM-2100] Implementing tests for AutofillService * [PM-2100] Implementing tests for AutofillService.loadPasswordFields * [PM-2100] Implementing tests for AutofillService.findUsernameField * [PM-2100] Implementing tests for AutofillService.findTotpField * [PM-2100] Implementing tests for AutofillService.fieldPropertyIsPrefixMatch * [PM-2100] Finalizing tests for AutofillService * [PM-2100] Modyfing placement of autofill-mocks * [PM-2100] Modyfing placement of autofill-mocks * [PM-2100] Removal of jest transform declaration * [PM-2130] Fixing issue with autofill service unit tests * [PM-2130] Fixing issue with autofill service unit tests * [PM-2130] Fixing test test for when we need to handle a password reprompt --------- Co-authored-by: Manuel <mr-manuel@outlook.it> Co-authored-by: Cesar Gonzalez <cgonzalez@bitwarden.com> Co-authored-by: Cesar Gonzalez <cesar.a.gonzalezcs@gmail.com> * [PM-3285] Migrating Changes from PM-1407 into autofill v2 refactor implementation * [PM-2747] Add Support for Feature Flag of Autofill Version (#5695) * [PM-2100] Create Unit Test Suite for Autofill.service.ts * [PM-2100] Finishing out tests for the getFormsWithPasswordFields method * [PM-2100] Implementing tests for the doAutofill method within the autofill service * [PM-2100] Working through implementation of doAutofill method * [PM-2100] Working through implementation of doAutofill method * [PM-2100] Finishing implementatino of isUntrustedIframe method within autofill service * [PM-2100] Finishing implementation of doAutoFill method within autofill service * [PM-2100] Finishing implementation of doAutoFillOnTab method within autofill service * [PM-2100] Working through tests for generateFillScript * split up autofill.ts, first pass * remove modification tracking comments * lessen and localize eslint disables * additional typing and formatting * update autofill v2 with PR #5364 changes (update/i18n confirm dialogs) * update autofill v2 with PR #4155 changes (add autofill support for textarea) Co-Authored-By: Manuel <mr-manuel@outlook.it> * move commonly used string values to constants * ts cleanup * [PM-2100] Finalizing generateFillScript method testing * [PM-2100] Starting implementation of generateLoginFillScript * [PM-2100] Working through tests for generateLoginFillScript * [PM-2100] Finalizing generateLoginFillScript method testing * [PM-2130] Starting work to re-architect autofillv2.ts * [PM-2130] Starting work to re-architect autofillv2.ts * [PM-2130] Working through autofill collect method * [PM-2130] Marking Removal of documentUUID as dead code * [PM-2130] Refining the implementation of collect and moving broken out utils back into class implementation * [PM-2130] Applying small refactors to AutofillCollect * [PM-2130] Refining the implementation of getAutofillFieldLabelTag to help with readability of the method * [PM-2130] Implementing jest tests for AutofillCollect methods * [PM-2130] Refining implementation for AutofillCollect * [PM-2200] Unit tests for autofill content script utilities with slight refactors (#5544) * add unit tests for urlNotSecure * add test coverage command * add unit tests for canSeeElementToStyle * canSeeElementToStyle should not return true if `animateTheFilling` or `currentEl` is false * add tests for selectAllFromDoc and getElementByOpId * clean up getElementByOpId * address some typing issues * add tests for setValueForElementByEvent, setValueForElement, and doSimpleSetByQuery * clean up setValueForElement and setValueForElementByEvent * more typescript cleanup * add tests for doClickByOpId and touchAllPasswordFields * add tests for doFocusByOpId and doClickByQuery * misc fill cleanup * move functions between collect and fill utils and replace getElementForOPID for duplicate getElementByOpId * add tests for isKnownTag and isElementVisible * rename addProp and remove redundant focusElement in favor of doFocusElement * cleanup * fix checkNodeType * add tests for shiftForLeftLabel * clean up and rename checkNodeType, isKnownTag, and shiftForLeftLabel * add tests for getFormElements * clean up getFormElements * add tests for getElementAttrValue, getElementValue, getSelectElementOptions, getLabelTop, and queryDoc * clean up and rename queryDoc to queryDocument * misc cleanup and rename getElementAttrValue to getPropertyOrAttribute * rebase cleanup * prettier formatting * [PM-2130] Fixing linting issues * [PM-2130] Fixing linting issues * [PM-2130] Migrating implementation for collect methods and tests for those methods into AutofillCollect context * [PM-2130] Migrating getPropertyOrAttribute method from utils to AutofillCollect * [PM-2130] Continuing migration of methods from collect utils into AutofillCollect * [PM-2130] Rework of isViewable method to better handle behavior for how we identify if an element is currently within the viewport * [PM-2130] Filling out implementation of autofill-insert * [PM-2130] Refining AutofillInsert * [PM-2130] Implementing jest tests for AutofillCollect methods and breaking out visibility related logic to a separate service * [PM-2130] Fixing jest tests for AutofillCollect * [PM-2130] Fixing jest tests for AutofillInit * [PM-2130] Adjusting how the AutofillFieldVisibilityService class is used in AutofillCollect * [PM-2130] Working through AutofillInsert implementation * [PM-2130] Migrating methods from fill.ts to AutofillInsert * [PM-2130] Migrating methods from fill.ts to AutofillInsert * [PM-2130] Applying fix for IntersectionObserver when triggering behavior in Safari and fixing issue with how we trigger an input event shortly after filling in a field * [PM-2130] Refactoring AutofillCollect to service CollectAutofillContentService * [PM-2130] Refactoring AutofillInsert to service InsertAutofillContentService * [PM-2130] Further organization of implementation * [PM-2130] Filling out missing jest test for AutofillInit.fillForm method * [PM-2130] Migrating the last of the collect jest tests to InsertAutofillContentService * [PM-2130] Further refactoring of elements including typing information * [PM-2130] Implementing jest tests for InsertAutofillContentService * [PM-2130] Implementing jest tests for InsertAutofillContentService * [PM-2130] Organization and refactoring of methods within InsertAutofillContent * [PM-2130] Implementation of jest tests for InsertAutofillContentService * [PM-2130] Implementation of Jest Test for IntertAutofillContentService * [PM-2130] Finalizing migration of methods and jest tests from util files into Autofill serivces * [PM-2130] Cleaning up dead code comments * [PM-2130] Removing unnecessary constants * [PM-2130] Finalizing jest tests for InsertAutofillContentService * [PM-2130] Refactoring FieldVisibiltyService to DomElementVisibilityService to allow service to act in a more general manner * [PM-2130] Implementing jest tests for DomElementVisibilityService * [PM-2130] Implementing jest tests for DomElementVisibilityService * [PM-2130] Implementing jest tests for DomElementVisibilityService * [PM-2130] Implementing jest tests for DomElementVisibilityService * [PM-2130] Breaking out the callback method used to resolve the IntersectionObserver promise * [PM-2100] Removing unnecessary jest config file * [PM-2100] Fixing jest tests based on changes implemented within PM-2130 * [PM-2100] Fixing autofill mocks * [PM-2100] Fixing AutofillService jest tests * [PM-2100] Handling missing tests within coverage of AutofillService * [PM-2100] Handling missing tests within coverage of AutofillService.generateLoginFillScript * [PM-2100] Writing tests for AutofillService.generateCardFillScript * [PM-2100] Finalizing tests for AutofillService.generateCardFillScript * [PM-2100] Adding additional tests to cover changes introduced by TOTOP autofill PR * [PM-2100] Adding jest tests for Autofill.generateIdentityFillScript * [PM-2100] Finalizing tests for AutofillService.generateIdentityFillScript * [PM-2100] Implementing tests for AutofillService * [PM-2130] Adding a comment explaining a fix for Safari * [PM-2130] Adding a comment explaining a fix for Safari * [PM-2100] Implementing tests for AutofillService.loadPasswordFields * [PM-2100] Implementing tests for AutofillService.findUsernameField * [PM-2100] Implementing tests for AutofillService.findTotpField * [PM-2100] Implementing tests for AutofillService.fieldPropertyIsPrefixMatch * [PM-2100] Finalizing tests for AutofillService * [PM-2747] Add Support for Feature Flag of Autofill Version * [PM-2747] Adding Support for Manifest v3 within the implementation * [PM-2747] Modifying how the feature flag for autofill is named * [PM-2747] Modifying main.background.ts to load the ConfigApiService correctly * [PM-2747] Refactoring trigger of autofill scripts to be a simple immediately invoked function * [PM-2100] Modyfing placement of autofill-mocks * [PM-2100] Modyfing placement of autofill-mocks * [PM-2100] Removal of jest transform declaration * [PM-2130] Applying changes required for PM-2762 to implementation, and ensuring jest tests exist to validate the behavior * [PM-2747] Modifying how we inject the autofill scripts to ensure we are injecting into all frames within a page * [PM-2130] Removing usage of IntersectionObserver when identifying element visibility due to broken interactions with React Components * [PM-2130] Fixing issue found when attempting to capture the elementAtCenterPoint in determining file visibility * [PM-2100] Create Unit Test Suite for autofill.service.ts (#5371) * [PM-2100] Create Unit Test Suite for Autofill.service.ts * [PM-2100] Finishing out tests for the getFormsWithPasswordFields method * [PM-2100] Implementing tests for the doAutofill method within the autofill service * [PM-2100] Working through implementation of doAutofill method * [PM-2100] Working through implementation of doAutofill method * [PM-2100] Finishing implementatino of isUntrustedIframe method within autofill service * [PM-2100] Finishing implementation of doAutoFill method within autofill service * [PM-2100] Finishing implementation of doAutoFillOnTab method within autofill service * [PM-2100] Working through tests for generateFillScript * [PM-2100] Finalizing generateFillScript method testing * [PM-2100] Starting implementation of generateLoginFillScript * [PM-2100] Working through tests for generateLoginFillScript * [PM-2100] Finalizing generateLoginFillScript method testing * [PM-2100] Removing unnecessary jest config file * [PM-2100] Fixing jest tests based on changes implemented within PM-2130 * [PM-2100] Fixing autofill mocks * [PM-2100] Fixing AutofillService jest tests * [PM-2100] Handling missing tests within coverage of AutofillService * [PM-2100] Handling missing tests within coverage of AutofillService.generateLoginFillScript * [PM-2100] Writing tests for AutofillService.generateCardFillScript * [PM-2100] Finalizing tests for AutofillService.generateCardFillScript * [PM-2100] Adding additional tests to cover changes introduced by TOTOP autofill PR * [PM-2100] Adding jest tests for Autofill.generateIdentityFillScript * [PM-2100] Finalizing tests for AutofillService.generateIdentityFillScript * [PM-2100] Implementing tests for AutofillService * [PM-2100] Implementing tests for AutofillService.loadPasswordFields * [PM-2100] Implementing tests for AutofillService.findUsernameField * [PM-2100] Implementing tests for AutofillService.findTotpField * [PM-2100] Implementing tests for AutofillService.fieldPropertyIsPrefixMatch * [PM-2100] Finalizing tests for AutofillService * [PM-2100] Modyfing placement of autofill-mocks * [PM-2100] Modyfing placement of autofill-mocks * [PM-2100] Removal of jest transform declaration * [PM-2747] Applying a fix for a race condition that can occur when loading the notification bar and autofiller script login * [PM-2747] Reverting removal of autofill npm action. Now this will force usage of autofill-v2 regardless of whether a feature flag is set or not * [PM-2747] Fixing logic error incorporated when merging in master * [PM-2130] Fixing issue with autofill service unit tests * [PM-2130] Fixing issue with autofill service unit tests * [PM-2747] Fixing issue present with notification bar merge * [PM-2130] Fixing test test for when we need to handle a password reprompt * [PM-2747] Fixing wording for webpack script * [PM-2747] Addressing stylistic changes requested from code review * [PM-2747] Addressing stylistic changes requested from code review --------- Co-authored-by: Jonathan Prusik <jprusik@classynemesis.com> Co-authored-by: Manuel <mr-manuel@outlook.it> Co-authored-by: Jonathan Prusik <jprusik@users.noreply.github.com> * [PM-3285] Applying stylistic changes suggested by code review for the feature flag implementation * [PM-3285] Adding temporary console log to validate which version is being used * [PM-3285] Removing temporary console log indicating which version of autofill the user is currently loading --------- Co-authored-by: Jonathan Prusik <jprusik@users.noreply.github.com> Co-authored-by: Manuel <mr-manuel@outlook.it> Co-authored-by: Jonathan Prusik <jprusik@classynemesis.com>
2023-09-07 22:33:04 +02:00
// Do not show the notification bar on the Bitwarden vault
// because they can add logins and change passwords there
if (window.location.origin === userSettings.serverConfig.environment.vault) {
showNotificationBar = false;
} else {
// 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 = globalSettings.neverDomains;
[PM-3285] Autofill v2 Feature Branch (#5939) * [PM-3285] Autofill v2 Feature Branch * [PM-2130] - Audit, Modularize, and Refactor Core autofill.js File (#5453) * split up autofill.ts, first pass * remove modification tracking comments * lessen and localize eslint disables * additional typing and formatting * update autofill v2 with PR #5364 changes (update/i18n confirm dialogs) * update autofill v2 with PR #4155 changes (add autofill support for textarea) Co-Authored-By: Manuel <mr-manuel@outlook.it> * move commonly used string values to constants * ts cleanup * [PM-2130] Starting work to re-architect autofillv2.ts * [PM-2130] Starting work to re-architect autofillv2.ts * [PM-2130] Working through autofill collect method * [PM-2130] Marking Removal of documentUUID as dead code * [PM-2130] Refining the implementation of collect and moving broken out utils back into class implementation * [PM-2130] Applying small refactors to AutofillCollect * [PM-2130] Refining the implementation of getAutofillFieldLabelTag to help with readability of the method * [PM-2130] Implementing jest tests for AutofillCollect methods * [PM-2130] Refining implementation for AutofillCollect * [PM-2200] Unit tests for autofill content script utilities with slight refactors (#5544) * add unit tests for urlNotSecure * add test coverage command * add unit tests for canSeeElementToStyle * canSeeElementToStyle should not return true if `animateTheFilling` or `currentEl` is false * add tests for selectAllFromDoc and getElementByOpId * clean up getElementByOpId * address some typing issues * add tests for setValueForElementByEvent, setValueForElement, and doSimpleSetByQuery * clean up setValueForElement and setValueForElementByEvent * more typescript cleanup * add tests for doClickByOpId and touchAllPasswordFields * add tests for doFocusByOpId and doClickByQuery * misc fill cleanup * move functions between collect and fill utils and replace getElementForOPID for duplicate getElementByOpId * add tests for isKnownTag and isElementVisible * rename addProp and remove redundant focusElement in favor of doFocusElement * cleanup * fix checkNodeType * add tests for shiftForLeftLabel * clean up and rename checkNodeType, isKnownTag, and shiftForLeftLabel * add tests for getFormElements * clean up getFormElements * add tests for getElementAttrValue, getElementValue, getSelectElementOptions, getLabelTop, and queryDoc * clean up and rename queryDoc to queryDocument * misc cleanup and rename getElementAttrValue to getPropertyOrAttribute * rebase cleanup * prettier formatting * [PM-2130] Fixing linting issues * [PM-2130] Fixing linting issues * [PM-2130] Migrating implementation for collect methods and tests for those methods into AutofillCollect context * [PM-2130] Migrating getPropertyOrAttribute method from utils to AutofillCollect * [PM-2130] Continuing migration of methods from collect utils into AutofillCollect * [PM-2130] Rework of isViewable method to better handle behavior for how we identify if an element is currently within the viewport * [PM-2130] Filling out implementation of autofill-insert * [PM-2130] Refining AutofillInsert * [PM-2130] Implementing jest tests for AutofillCollect methods and breaking out visibility related logic to a separate service * [PM-2130] Fixing jest tests for AutofillCollect * [PM-2130] Fixing jest tests for AutofillInit * [PM-2130] Adjusting how the AutofillFieldVisibilityService class is used in AutofillCollect * [PM-2130] Working through AutofillInsert implementation * [PM-2130] Migrating methods from fill.ts to AutofillInsert * [PM-2130] Migrating methods from fill.ts to AutofillInsert * [PM-2130] Applying fix for IntersectionObserver when triggering behavior in Safari and fixing issue with how we trigger an input event shortly after filling in a field * [PM-2130] Refactoring AutofillCollect to service CollectAutofillContentService * [PM-2130] Refactoring AutofillInsert to service InsertAutofillContentService * [PM-2130] Further organization of implementation * [PM-2130] Filling out missing jest test for AutofillInit.fillForm method * [PM-2130] Migrating the last of the collect jest tests to InsertAutofillContentService * [PM-2130] Further refactoring of elements including typing information * [PM-2130] Implementing jest tests for InsertAutofillContentService * [PM-2130] Implementing jest tests for InsertAutofillContentService * [PM-2130] Organization and refactoring of methods within InsertAutofillContent * [PM-2130] Implementation of jest tests for InsertAutofillContentService * [PM-2130] Implementation of Jest Test for IntertAutofillContentService * [PM-2130] Finalizing migration of methods and jest tests from util files into Autofill serivces * [PM-2130] Cleaning up dead code comments * [PM-2130] Removing unnecessary constants * [PM-2130] Finalizing jest tests for InsertAutofillContentService * [PM-2130] Refactoring FieldVisibiltyService to DomElementVisibilityService to allow service to act in a more general manner * [PM-2130] Implementing jest tests for DomElementVisibilityService * [PM-2130] Implementing jest tests for DomElementVisibilityService * [PM-2130] Implementing jest tests for DomElementVisibilityService * [PM-2130] Implementing jest tests for DomElementVisibilityService * [PM-2130] Breaking out the callback method used to resolve the IntersectionObserver promise * [PM-2130] Adding a comment explaining a fix for Safari * [PM-2130] Adding a comment explaining a fix for Safari * [PM-2130] Applying changes required for PM-2762 to implementation, and ensuring jest tests exist to validate the behavior * [PM-2130] Removing usage of IntersectionObserver when identifying element visibility due to broken interactions with React Components * [PM-2130] Fixing issue found when attempting to capture the elementAtCenterPoint in determining file visibility * [PM-2100] Create Unit Test Suite for autofill.service.ts (#5371) * [PM-2100] Create Unit Test Suite for Autofill.service.ts * [PM-2100] Finishing out tests for the getFormsWithPasswordFields method * [PM-2100] Implementing tests for the doAutofill method within the autofill service * [PM-2100] Working through implementation of doAutofill method * [PM-2100] Working through implementation of doAutofill method * [PM-2100] Finishing implementatino of isUntrustedIframe method within autofill service * [PM-2100] Finishing implementation of doAutoFill method within autofill service * [PM-2100] Finishing implementation of doAutoFillOnTab method within autofill service * [PM-2100] Working through tests for generateFillScript * [PM-2100] Finalizing generateFillScript method testing * [PM-2100] Starting implementation of generateLoginFillScript * [PM-2100] Working through tests for generateLoginFillScript * [PM-2100] Finalizing generateLoginFillScript method testing * [PM-2100] Removing unnecessary jest config file * [PM-2100] Fixing jest tests based on changes implemented within PM-2130 * [PM-2100] Fixing autofill mocks * [PM-2100] Fixing AutofillService jest tests * [PM-2100] Handling missing tests within coverage of AutofillService * [PM-2100] Handling missing tests within coverage of AutofillService.generateLoginFillScript * [PM-2100] Writing tests for AutofillService.generateCardFillScript * [PM-2100] Finalizing tests for AutofillService.generateCardFillScript * [PM-2100] Adding additional tests to cover changes introduced by TOTOP autofill PR * [PM-2100] Adding jest tests for Autofill.generateIdentityFillScript * [PM-2100] Finalizing tests for AutofillService.generateIdentityFillScript * [PM-2100] Implementing tests for AutofillService * [PM-2100] Implementing tests for AutofillService.loadPasswordFields * [PM-2100] Implementing tests for AutofillService.findUsernameField * [PM-2100] Implementing tests for AutofillService.findTotpField * [PM-2100] Implementing tests for AutofillService.fieldPropertyIsPrefixMatch * [PM-2100] Finalizing tests for AutofillService * [PM-2100] Modyfing placement of autofill-mocks * [PM-2100] Modyfing placement of autofill-mocks * [PM-2100] Removal of jest transform declaration * [PM-2130] Fixing issue with autofill service unit tests * [PM-2130] Fixing issue with autofill service unit tests * [PM-2130] Fixing test test for when we need to handle a password reprompt --------- Co-authored-by: Manuel <mr-manuel@outlook.it> Co-authored-by: Cesar Gonzalez <cgonzalez@bitwarden.com> Co-authored-by: Cesar Gonzalez <cesar.a.gonzalezcs@gmail.com> * [PM-3285] Migrating Changes from PM-1407 into autofill v2 refactor implementation * [PM-2747] Add Support for Feature Flag of Autofill Version (#5695) * [PM-2100] Create Unit Test Suite for Autofill.service.ts * [PM-2100] Finishing out tests for the getFormsWithPasswordFields method * [PM-2100] Implementing tests for the doAutofill method within the autofill service * [PM-2100] Working through implementation of doAutofill method * [PM-2100] Working through implementation of doAutofill method * [PM-2100] Finishing implementatino of isUntrustedIframe method within autofill service * [PM-2100] Finishing implementation of doAutoFill method within autofill service * [PM-2100] Finishing implementation of doAutoFillOnTab method within autofill service * [PM-2100] Working through tests for generateFillScript * split up autofill.ts, first pass * remove modification tracking comments * lessen and localize eslint disables * additional typing and formatting * update autofill v2 with PR #5364 changes (update/i18n confirm dialogs) * update autofill v2 with PR #4155 changes (add autofill support for textarea) Co-Authored-By: Manuel <mr-manuel@outlook.it> * move commonly used string values to constants * ts cleanup * [PM-2100] Finalizing generateFillScript method testing * [PM-2100] Starting implementation of generateLoginFillScript * [PM-2100] Working through tests for generateLoginFillScript * [PM-2100] Finalizing generateLoginFillScript method testing * [PM-2130] Starting work to re-architect autofillv2.ts * [PM-2130] Starting work to re-architect autofillv2.ts * [PM-2130] Working through autofill collect method * [PM-2130] Marking Removal of documentUUID as dead code * [PM-2130] Refining the implementation of collect and moving broken out utils back into class implementation * [PM-2130] Applying small refactors to AutofillCollect * [PM-2130] Refining the implementation of getAutofillFieldLabelTag to help with readability of the method * [PM-2130] Implementing jest tests for AutofillCollect methods * [PM-2130] Refining implementation for AutofillCollect * [PM-2200] Unit tests for autofill content script utilities with slight refactors (#5544) * add unit tests for urlNotSecure * add test coverage command * add unit tests for canSeeElementToStyle * canSeeElementToStyle should not return true if `animateTheFilling` or `currentEl` is false * add tests for selectAllFromDoc and getElementByOpId * clean up getElementByOpId * address some typing issues * add tests for setValueForElementByEvent, setValueForElement, and doSimpleSetByQuery * clean up setValueForElement and setValueForElementByEvent * more typescript cleanup * add tests for doClickByOpId and touchAllPasswordFields * add tests for doFocusByOpId and doClickByQuery * misc fill cleanup * move functions between collect and fill utils and replace getElementForOPID for duplicate getElementByOpId * add tests for isKnownTag and isElementVisible * rename addProp and remove redundant focusElement in favor of doFocusElement * cleanup * fix checkNodeType * add tests for shiftForLeftLabel * clean up and rename checkNodeType, isKnownTag, and shiftForLeftLabel * add tests for getFormElements * clean up getFormElements * add tests for getElementAttrValue, getElementValue, getSelectElementOptions, getLabelTop, and queryDoc * clean up and rename queryDoc to queryDocument * misc cleanup and rename getElementAttrValue to getPropertyOrAttribute * rebase cleanup * prettier formatting * [PM-2130] Fixing linting issues * [PM-2130] Fixing linting issues * [PM-2130] Migrating implementation for collect methods and tests for those methods into AutofillCollect context * [PM-2130] Migrating getPropertyOrAttribute method from utils to AutofillCollect * [PM-2130] Continuing migration of methods from collect utils into AutofillCollect * [PM-2130] Rework of isViewable method to better handle behavior for how we identify if an element is currently within the viewport * [PM-2130] Filling out implementation of autofill-insert * [PM-2130] Refining AutofillInsert * [PM-2130] Implementing jest tests for AutofillCollect methods and breaking out visibility related logic to a separate service * [PM-2130] Fixing jest tests for AutofillCollect * [PM-2130] Fixing jest tests for AutofillInit * [PM-2130] Adjusting how the AutofillFieldVisibilityService class is used in AutofillCollect * [PM-2130] Working through AutofillInsert implementation * [PM-2130] Migrating methods from fill.ts to AutofillInsert * [PM-2130] Migrating methods from fill.ts to AutofillInsert * [PM-2130] Applying fix for IntersectionObserver when triggering behavior in Safari and fixing issue with how we trigger an input event shortly after filling in a field * [PM-2130] Refactoring AutofillCollect to service CollectAutofillContentService * [PM-2130] Refactoring AutofillInsert to service InsertAutofillContentService * [PM-2130] Further organization of implementation * [PM-2130] Filling out missing jest test for AutofillInit.fillForm method * [PM-2130] Migrating the last of the collect jest tests to InsertAutofillContentService * [PM-2130] Further refactoring of elements including typing information * [PM-2130] Implementing jest tests for InsertAutofillContentService * [PM-2130] Implementing jest tests for InsertAutofillContentService * [PM-2130] Organization and refactoring of methods within InsertAutofillContent * [PM-2130] Implementation of jest tests for InsertAutofillContentService * [PM-2130] Implementation of Jest Test for IntertAutofillContentService * [PM-2130] Finalizing migration of methods and jest tests from util files into Autofill serivces * [PM-2130] Cleaning up dead code comments * [PM-2130] Removing unnecessary constants * [PM-2130] Finalizing jest tests for InsertAutofillContentService * [PM-2130] Refactoring FieldVisibiltyService to DomElementVisibilityService to allow service to act in a more general manner * [PM-2130] Implementing jest tests for DomElementVisibilityService * [PM-2130] Implementing jest tests for DomElementVisibilityService * [PM-2130] Implementing jest tests for DomElementVisibilityService * [PM-2130] Implementing jest tests for DomElementVisibilityService * [PM-2130] Breaking out the callback method used to resolve the IntersectionObserver promise * [PM-2100] Removing unnecessary jest config file * [PM-2100] Fixing jest tests based on changes implemented within PM-2130 * [PM-2100] Fixing autofill mocks * [PM-2100] Fixing AutofillService jest tests * [PM-2100] Handling missing tests within coverage of AutofillService * [PM-2100] Handling missing tests within coverage of AutofillService.generateLoginFillScript * [PM-2100] Writing tests for AutofillService.generateCardFillScript * [PM-2100] Finalizing tests for AutofillService.generateCardFillScript * [PM-2100] Adding additional tests to cover changes introduced by TOTOP autofill PR * [PM-2100] Adding jest tests for Autofill.generateIdentityFillScript * [PM-2100] Finalizing tests for AutofillService.generateIdentityFillScript * [PM-2100] Implementing tests for AutofillService * [PM-2130] Adding a comment explaining a fix for Safari * [PM-2130] Adding a comment explaining a fix for Safari * [PM-2100] Implementing tests for AutofillService.loadPasswordFields * [PM-2100] Implementing tests for AutofillService.findUsernameField * [PM-2100] Implementing tests for AutofillService.findTotpField * [PM-2100] Implementing tests for AutofillService.fieldPropertyIsPrefixMatch * [PM-2100] Finalizing tests for AutofillService * [PM-2747] Add Support for Feature Flag of Autofill Version * [PM-2747] Adding Support for Manifest v3 within the implementation * [PM-2747] Modifying how the feature flag for autofill is named * [PM-2747] Modifying main.background.ts to load the ConfigApiService correctly * [PM-2747] Refactoring trigger of autofill scripts to be a simple immediately invoked function * [PM-2100] Modyfing placement of autofill-mocks * [PM-2100] Modyfing placement of autofill-mocks * [PM-2100] Removal of jest transform declaration * [PM-2130] Applying changes required for PM-2762 to implementation, and ensuring jest tests exist to validate the behavior * [PM-2747] Modifying how we inject the autofill scripts to ensure we are injecting into all frames within a page * [PM-2130] Removing usage of IntersectionObserver when identifying element visibility due to broken interactions with React Components * [PM-2130] Fixing issue found when attempting to capture the elementAtCenterPoint in determining file visibility * [PM-2100] Create Unit Test Suite for autofill.service.ts (#5371) * [PM-2100] Create Unit Test Suite for Autofill.service.ts * [PM-2100] Finishing out tests for the getFormsWithPasswordFields method * [PM-2100] Implementing tests for the doAutofill method within the autofill service * [PM-2100] Working through implementation of doAutofill method * [PM-2100] Working through implementation of doAutofill method * [PM-2100] Finishing implementatino of isUntrustedIframe method within autofill service * [PM-2100] Finishing implementation of doAutoFill method within autofill service * [PM-2100] Finishing implementation of doAutoFillOnTab method within autofill service * [PM-2100] Working through tests for generateFillScript * [PM-2100] Finalizing generateFillScript method testing * [PM-2100] Starting implementation of generateLoginFillScript * [PM-2100] Working through tests for generateLoginFillScript * [PM-2100] Finalizing generateLoginFillScript method testing * [PM-2100] Removing unnecessary jest config file * [PM-2100] Fixing jest tests based on changes implemented within PM-2130 * [PM-2100] Fixing autofill mocks * [PM-2100] Fixing AutofillService jest tests * [PM-2100] Handling missing tests within coverage of AutofillService * [PM-2100] Handling missing tests within coverage of AutofillService.generateLoginFillScript * [PM-2100] Writing tests for AutofillService.generateCardFillScript * [PM-2100] Finalizing tests for AutofillService.generateCardFillScript * [PM-2100] Adding additional tests to cover changes introduced by TOTOP autofill PR * [PM-2100] Adding jest tests for Autofill.generateIdentityFillScript * [PM-2100] Finalizing tests for AutofillService.generateIdentityFillScript * [PM-2100] Implementing tests for AutofillService * [PM-2100] Implementing tests for AutofillService.loadPasswordFields * [PM-2100] Implementing tests for AutofillService.findUsernameField * [PM-2100] Implementing tests for AutofillService.findTotpField * [PM-2100] Implementing tests for AutofillService.fieldPropertyIsPrefixMatch * [PM-2100] Finalizing tests for AutofillService * [PM-2100] Modyfing placement of autofill-mocks * [PM-2100] Modyfing placement of autofill-mocks * [PM-2100] Removal of jest transform declaration * [PM-2747] Applying a fix for a race condition that can occur when loading the notification bar and autofiller script login * [PM-2747] Reverting removal of autofill npm action. Now this will force usage of autofill-v2 regardless of whether a feature flag is set or not * [PM-2747] Fixing logic error incorporated when merging in master * [PM-2130] Fixing issue with autofill service unit tests * [PM-2130] Fixing issue with autofill service unit tests * [PM-2747] Fixing issue present with notification bar merge * [PM-2130] Fixing test test for when we need to handle a password reprompt * [PM-2747] Fixing wording for webpack script * [PM-2747] Addressing stylistic changes requested from code review * [PM-2747] Addressing stylistic changes requested from code review --------- Co-authored-by: Jonathan Prusik <jprusik@classynemesis.com> Co-authored-by: Manuel <mr-manuel@outlook.it> Co-authored-by: Jonathan Prusik <jprusik@users.noreply.github.com> * [PM-3285] Applying stylistic changes suggested by code review for the feature flag implementation * [PM-3285] Adding temporary console log to validate which version is being used * [PM-3285] Removing temporary console log indicating which version of autofill the user is currently loading --------- Co-authored-by: Jonathan Prusik <jprusik@users.noreply.github.com> Co-authored-by: Manuel <mr-manuel@outlook.it> Co-authored-by: Jonathan Prusik <jprusik@classynemesis.com>
2023-09-07 22:33:04 +02:00
if (!excludedDomainsDict || !(window.location.hostname in excludedDomainsDict)) {
// Set local disabled preferences
disabledAddLoginNotification = globalSettings.disableAddLoginNotification;
disabledChangedPasswordNotification = globalSettings.disableChangedPasswordNotification;
[PM-3285] Autofill v2 Feature Branch (#5939) * [PM-3285] Autofill v2 Feature Branch * [PM-2130] - Audit, Modularize, and Refactor Core autofill.js File (#5453) * split up autofill.ts, first pass * remove modification tracking comments * lessen and localize eslint disables * additional typing and formatting * update autofill v2 with PR #5364 changes (update/i18n confirm dialogs) * update autofill v2 with PR #4155 changes (add autofill support for textarea) Co-Authored-By: Manuel <mr-manuel@outlook.it> * move commonly used string values to constants * ts cleanup * [PM-2130] Starting work to re-architect autofillv2.ts * [PM-2130] Starting work to re-architect autofillv2.ts * [PM-2130] Working through autofill collect method * [PM-2130] Marking Removal of documentUUID as dead code * [PM-2130] Refining the implementation of collect and moving broken out utils back into class implementation * [PM-2130] Applying small refactors to AutofillCollect * [PM-2130] Refining the implementation of getAutofillFieldLabelTag to help with readability of the method * [PM-2130] Implementing jest tests for AutofillCollect methods * [PM-2130] Refining implementation for AutofillCollect * [PM-2200] Unit tests for autofill content script utilities with slight refactors (#5544) * add unit tests for urlNotSecure * add test coverage command * add unit tests for canSeeElementToStyle * canSeeElementToStyle should not return true if `animateTheFilling` or `currentEl` is false * add tests for selectAllFromDoc and getElementByOpId * clean up getElementByOpId * address some typing issues * add tests for setValueForElementByEvent, setValueForElement, and doSimpleSetByQuery * clean up setValueForElement and setValueForElementByEvent * more typescript cleanup * add tests for doClickByOpId and touchAllPasswordFields * add tests for doFocusByOpId and doClickByQuery * misc fill cleanup * move functions between collect and fill utils and replace getElementForOPID for duplicate getElementByOpId * add tests for isKnownTag and isElementVisible * rename addProp and remove redundant focusElement in favor of doFocusElement * cleanup * fix checkNodeType * add tests for shiftForLeftLabel * clean up and rename checkNodeType, isKnownTag, and shiftForLeftLabel * add tests for getFormElements * clean up getFormElements * add tests for getElementAttrValue, getElementValue, getSelectElementOptions, getLabelTop, and queryDoc * clean up and rename queryDoc to queryDocument * misc cleanup and rename getElementAttrValue to getPropertyOrAttribute * rebase cleanup * prettier formatting * [PM-2130] Fixing linting issues * [PM-2130] Fixing linting issues * [PM-2130] Migrating implementation for collect methods and tests for those methods into AutofillCollect context * [PM-2130] Migrating getPropertyOrAttribute method from utils to AutofillCollect * [PM-2130] Continuing migration of methods from collect utils into AutofillCollect * [PM-2130] Rework of isViewable method to better handle behavior for how we identify if an element is currently within the viewport * [PM-2130] Filling out implementation of autofill-insert * [PM-2130] Refining AutofillInsert * [PM-2130] Implementing jest tests for AutofillCollect methods and breaking out visibility related logic to a separate service * [PM-2130] Fixing jest tests for AutofillCollect * [PM-2130] Fixing jest tests for AutofillInit * [PM-2130] Adjusting how the AutofillFieldVisibilityService class is used in AutofillCollect * [PM-2130] Working through AutofillInsert implementation * [PM-2130] Migrating methods from fill.ts to AutofillInsert * [PM-2130] Migrating methods from fill.ts to AutofillInsert * [PM-2130] Applying fix for IntersectionObserver when triggering behavior in Safari and fixing issue with how we trigger an input event shortly after filling in a field * [PM-2130] Refactoring AutofillCollect to service CollectAutofillContentService * [PM-2130] Refactoring AutofillInsert to service InsertAutofillContentService * [PM-2130] Further organization of implementation * [PM-2130] Filling out missing jest test for AutofillInit.fillForm method * [PM-2130] Migrating the last of the collect jest tests to InsertAutofillContentService * [PM-2130] Further refactoring of elements including typing information * [PM-2130] Implementing jest tests for InsertAutofillContentService * [PM-2130] Implementing jest tests for InsertAutofillContentService * [PM-2130] Organization and refactoring of methods within InsertAutofillContent * [PM-2130] Implementation of jest tests for InsertAutofillContentService * [PM-2130] Implementation of Jest Test for IntertAutofillContentService * [PM-2130] Finalizing migration of methods and jest tests from util files into Autofill serivces * [PM-2130] Cleaning up dead code comments * [PM-2130] Removing unnecessary constants * [PM-2130] Finalizing jest tests for InsertAutofillContentService * [PM-2130] Refactoring FieldVisibiltyService to DomElementVisibilityService to allow service to act in a more general manner * [PM-2130] Implementing jest tests for DomElementVisibilityService * [PM-2130] Implementing jest tests for DomElementVisibilityService * [PM-2130] Implementing jest tests for DomElementVisibilityService * [PM-2130] Implementing jest tests for DomElementVisibilityService * [PM-2130] Breaking out the callback method used to resolve the IntersectionObserver promise * [PM-2130] Adding a comment explaining a fix for Safari * [PM-2130] Adding a comment explaining a fix for Safari * [PM-2130] Applying changes required for PM-2762 to implementation, and ensuring jest tests exist to validate the behavior * [PM-2130] Removing usage of IntersectionObserver when identifying element visibility due to broken interactions with React Components * [PM-2130] Fixing issue found when attempting to capture the elementAtCenterPoint in determining file visibility * [PM-2100] Create Unit Test Suite for autofill.service.ts (#5371) * [PM-2100] Create Unit Test Suite for Autofill.service.ts * [PM-2100] Finishing out tests for the getFormsWithPasswordFields method * [PM-2100] Implementing tests for the doAutofill method within the autofill service * [PM-2100] Working through implementation of doAutofill method * [PM-2100] Working through implementation of doAutofill method * [PM-2100] Finishing implementatino of isUntrustedIframe method within autofill service * [PM-2100] Finishing implementation of doAutoFill method within autofill service * [PM-2100] Finishing implementation of doAutoFillOnTab method within autofill service * [PM-2100] Working through tests for generateFillScript * [PM-2100] Finalizing generateFillScript method testing * [PM-2100] Starting implementation of generateLoginFillScript * [PM-2100] Working through tests for generateLoginFillScript * [PM-2100] Finalizing generateLoginFillScript method testing * [PM-2100] Removing unnecessary jest config file * [PM-2100] Fixing jest tests based on changes implemented within PM-2130 * [PM-2100] Fixing autofill mocks * [PM-2100] Fixing AutofillService jest tests * [PM-2100] Handling missing tests within coverage of AutofillService * [PM-2100] Handling missing tests within coverage of AutofillService.generateLoginFillScript * [PM-2100] Writing tests for AutofillService.generateCardFillScript * [PM-2100] Finalizing tests for AutofillService.generateCardFillScript * [PM-2100] Adding additional tests to cover changes introduced by TOTOP autofill PR * [PM-2100] Adding jest tests for Autofill.generateIdentityFillScript * [PM-2100] Finalizing tests for AutofillService.generateIdentityFillScript * [PM-2100] Implementing tests for AutofillService * [PM-2100] Implementing tests for AutofillService.loadPasswordFields * [PM-2100] Implementing tests for AutofillService.findUsernameField * [PM-2100] Implementing tests for AutofillService.findTotpField * [PM-2100] Implementing tests for AutofillService.fieldPropertyIsPrefixMatch * [PM-2100] Finalizing tests for AutofillService * [PM-2100] Modyfing placement of autofill-mocks * [PM-2100] Modyfing placement of autofill-mocks * [PM-2100] Removal of jest transform declaration * [PM-2130] Fixing issue with autofill service unit tests * [PM-2130] Fixing issue with autofill service unit tests * [PM-2130] Fixing test test for when we need to handle a password reprompt --------- Co-authored-by: Manuel <mr-manuel@outlook.it> Co-authored-by: Cesar Gonzalez <cgonzalez@bitwarden.com> Co-authored-by: Cesar Gonzalez <cesar.a.gonzalezcs@gmail.com> * [PM-3285] Migrating Changes from PM-1407 into autofill v2 refactor implementation * [PM-2747] Add Support for Feature Flag of Autofill Version (#5695) * [PM-2100] Create Unit Test Suite for Autofill.service.ts * [PM-2100] Finishing out tests for the getFormsWithPasswordFields method * [PM-2100] Implementing tests for the doAutofill method within the autofill service * [PM-2100] Working through implementation of doAutofill method * [PM-2100] Working through implementation of doAutofill method * [PM-2100] Finishing implementatino of isUntrustedIframe method within autofill service * [PM-2100] Finishing implementation of doAutoFill method within autofill service * [PM-2100] Finishing implementation of doAutoFillOnTab method within autofill service * [PM-2100] Working through tests for generateFillScript * split up autofill.ts, first pass * remove modification tracking comments * lessen and localize eslint disables * additional typing and formatting * update autofill v2 with PR #5364 changes (update/i18n confirm dialogs) * update autofill v2 with PR #4155 changes (add autofill support for textarea) Co-Authored-By: Manuel <mr-manuel@outlook.it> * move commonly used string values to constants * ts cleanup * [PM-2100] Finalizing generateFillScript method testing * [PM-2100] Starting implementation of generateLoginFillScript * [PM-2100] Working through tests for generateLoginFillScript * [PM-2100] Finalizing generateLoginFillScript method testing * [PM-2130] Starting work to re-architect autofillv2.ts * [PM-2130] Starting work to re-architect autofillv2.ts * [PM-2130] Working through autofill collect method * [PM-2130] Marking Removal of documentUUID as dead code * [PM-2130] Refining the implementation of collect and moving broken out utils back into class implementation * [PM-2130] Applying small refactors to AutofillCollect * [PM-2130] Refining the implementation of getAutofillFieldLabelTag to help with readability of the method * [PM-2130] Implementing jest tests for AutofillCollect methods * [PM-2130] Refining implementation for AutofillCollect * [PM-2200] Unit tests for autofill content script utilities with slight refactors (#5544) * add unit tests for urlNotSecure * add test coverage command * add unit tests for canSeeElementToStyle * canSeeElementToStyle should not return true if `animateTheFilling` or `currentEl` is false * add tests for selectAllFromDoc and getElementByOpId * clean up getElementByOpId * address some typing issues * add tests for setValueForElementByEvent, setValueForElement, and doSimpleSetByQuery * clean up setValueForElement and setValueForElementByEvent * more typescript cleanup * add tests for doClickByOpId and touchAllPasswordFields * add tests for doFocusByOpId and doClickByQuery * misc fill cleanup * move functions between collect and fill utils and replace getElementForOPID for duplicate getElementByOpId * add tests for isKnownTag and isElementVisible * rename addProp and remove redundant focusElement in favor of doFocusElement * cleanup * fix checkNodeType * add tests for shiftForLeftLabel * clean up and rename checkNodeType, isKnownTag, and shiftForLeftLabel * add tests for getFormElements * clean up getFormElements * add tests for getElementAttrValue, getElementValue, getSelectElementOptions, getLabelTop, and queryDoc * clean up and rename queryDoc to queryDocument * misc cleanup and rename getElementAttrValue to getPropertyOrAttribute * rebase cleanup * prettier formatting * [PM-2130] Fixing linting issues * [PM-2130] Fixing linting issues * [PM-2130] Migrating implementation for collect methods and tests for those methods into AutofillCollect context * [PM-2130] Migrating getPropertyOrAttribute method from utils to AutofillCollect * [PM-2130] Continuing migration of methods from collect utils into AutofillCollect * [PM-2130] Rework of isViewable method to better handle behavior for how we identify if an element is currently within the viewport * [PM-2130] Filling out implementation of autofill-insert * [PM-2130] Refining AutofillInsert * [PM-2130] Implementing jest tests for AutofillCollect methods and breaking out visibility related logic to a separate service * [PM-2130] Fixing jest tests for AutofillCollect * [PM-2130] Fixing jest tests for AutofillInit * [PM-2130] Adjusting how the AutofillFieldVisibilityService class is used in AutofillCollect * [PM-2130] Working through AutofillInsert implementation * [PM-2130] Migrating methods from fill.ts to AutofillInsert * [PM-2130] Migrating methods from fill.ts to AutofillInsert * [PM-2130] Applying fix for IntersectionObserver when triggering behavior in Safari and fixing issue with how we trigger an input event shortly after filling in a field * [PM-2130] Refactoring AutofillCollect to service CollectAutofillContentService * [PM-2130] Refactoring AutofillInsert to service InsertAutofillContentService * [PM-2130] Further organization of implementation * [PM-2130] Filling out missing jest test for AutofillInit.fillForm method * [PM-2130] Migrating the last of the collect jest tests to InsertAutofillContentService * [PM-2130] Further refactoring of elements including typing information * [PM-2130] Implementing jest tests for InsertAutofillContentService * [PM-2130] Implementing jest tests for InsertAutofillContentService * [PM-2130] Organization and refactoring of methods within InsertAutofillContent * [PM-2130] Implementation of jest tests for InsertAutofillContentService * [PM-2130] Implementation of Jest Test for IntertAutofillContentService * [PM-2130] Finalizing migration of methods and jest tests from util files into Autofill serivces * [PM-2130] Cleaning up dead code comments * [PM-2130] Removing unnecessary constants * [PM-2130] Finalizing jest tests for InsertAutofillContentService * [PM-2130] Refactoring FieldVisibiltyService to DomElementVisibilityService to allow service to act in a more general manner * [PM-2130] Implementing jest tests for DomElementVisibilityService * [PM-2130] Implementing jest tests for DomElementVisibilityService * [PM-2130] Implementing jest tests for DomElementVisibilityService * [PM-2130] Implementing jest tests for DomElementVisibilityService * [PM-2130] Breaking out the callback method used to resolve the IntersectionObserver promise * [PM-2100] Removing unnecessary jest config file * [PM-2100] Fixing jest tests based on changes implemented within PM-2130 * [PM-2100] Fixing autofill mocks * [PM-2100] Fixing AutofillService jest tests * [PM-2100] Handling missing tests within coverage of AutofillService * [PM-2100] Handling missing tests within coverage of AutofillService.generateLoginFillScript * [PM-2100] Writing tests for AutofillService.generateCardFillScript * [PM-2100] Finalizing tests for AutofillService.generateCardFillScript * [PM-2100] Adding additional tests to cover changes introduced by TOTOP autofill PR * [PM-2100] Adding jest tests for Autofill.generateIdentityFillScript * [PM-2100] Finalizing tests for AutofillService.generateIdentityFillScript * [PM-2100] Implementing tests for AutofillService * [PM-2130] Adding a comment explaining a fix for Safari * [PM-2130] Adding a comment explaining a fix for Safari * [PM-2100] Implementing tests for AutofillService.loadPasswordFields * [PM-2100] Implementing tests for AutofillService.findUsernameField * [PM-2100] Implementing tests for AutofillService.findTotpField * [PM-2100] Implementing tests for AutofillService.fieldPropertyIsPrefixMatch * [PM-2100] Finalizing tests for AutofillService * [PM-2747] Add Support for Feature Flag of Autofill Version * [PM-2747] Adding Support for Manifest v3 within the implementation * [PM-2747] Modifying how the feature flag for autofill is named * [PM-2747] Modifying main.background.ts to load the ConfigApiService correctly * [PM-2747] Refactoring trigger of autofill scripts to be a simple immediately invoked function * [PM-2100] Modyfing placement of autofill-mocks * [PM-2100] Modyfing placement of autofill-mocks * [PM-2100] Removal of jest transform declaration * [PM-2130] Applying changes required for PM-2762 to implementation, and ensuring jest tests exist to validate the behavior * [PM-2747] Modifying how we inject the autofill scripts to ensure we are injecting into all frames within a page * [PM-2130] Removing usage of IntersectionObserver when identifying element visibility due to broken interactions with React Components * [PM-2130] Fixing issue found when attempting to capture the elementAtCenterPoint in determining file visibility * [PM-2100] Create Unit Test Suite for autofill.service.ts (#5371) * [PM-2100] Create Unit Test Suite for Autofill.service.ts * [PM-2100] Finishing out tests for the getFormsWithPasswordFields method * [PM-2100] Implementing tests for the doAutofill method within the autofill service * [PM-2100] Working through implementation of doAutofill method * [PM-2100] Working through implementation of doAutofill method * [PM-2100] Finishing implementatino of isUntrustedIframe method within autofill service * [PM-2100] Finishing implementation of doAutoFill method within autofill service * [PM-2100] Finishing implementation of doAutoFillOnTab method within autofill service * [PM-2100] Working through tests for generateFillScript * [PM-2100] Finalizing generateFillScript method testing * [PM-2100] Starting implementation of generateLoginFillScript * [PM-2100] Working through tests for generateLoginFillScript * [PM-2100] Finalizing generateLoginFillScript method testing * [PM-2100] Removing unnecessary jest config file * [PM-2100] Fixing jest tests based on changes implemented within PM-2130 * [PM-2100] Fixing autofill mocks * [PM-2100] Fixing AutofillService jest tests * [PM-2100] Handling missing tests within coverage of AutofillService * [PM-2100] Handling missing tests within coverage of AutofillService.generateLoginFillScript * [PM-2100] Writing tests for AutofillService.generateCardFillScript * [PM-2100] Finalizing tests for AutofillService.generateCardFillScript * [PM-2100] Adding additional tests to cover changes introduced by TOTOP autofill PR * [PM-2100] Adding jest tests for Autofill.generateIdentityFillScript * [PM-2100] Finalizing tests for AutofillService.generateIdentityFillScript * [PM-2100] Implementing tests for AutofillService * [PM-2100] Implementing tests for AutofillService.loadPasswordFields * [PM-2100] Implementing tests for AutofillService.findUsernameField * [PM-2100] Implementing tests for AutofillService.findTotpField * [PM-2100] Implementing tests for AutofillService.fieldPropertyIsPrefixMatch * [PM-2100] Finalizing tests for AutofillService * [PM-2100] Modyfing placement of autofill-mocks * [PM-2100] Modyfing placement of autofill-mocks * [PM-2100] Removal of jest transform declaration * [PM-2747] Applying a fix for a race condition that can occur when loading the notification bar and autofiller script login * [PM-2747] Reverting removal of autofill npm action. Now this will force usage of autofill-v2 regardless of whether a feature flag is set or not * [PM-2747] Fixing logic error incorporated when merging in master * [PM-2130] Fixing issue with autofill service unit tests * [PM-2130] Fixing issue with autofill service unit tests * [PM-2747] Fixing issue present with notification bar merge * [PM-2130] Fixing test test for when we need to handle a password reprompt * [PM-2747] Fixing wording for webpack script * [PM-2747] Addressing stylistic changes requested from code review * [PM-2747] Addressing stylistic changes requested from code review --------- Co-authored-by: Jonathan Prusik <jprusik@classynemesis.com> Co-authored-by: Manuel <mr-manuel@outlook.it> Co-authored-by: Jonathan Prusik <jprusik@users.noreply.github.com> * [PM-3285] Applying stylistic changes suggested by code review for the feature flag implementation * [PM-3285] Adding temporary console log to validate which version is being used * [PM-3285] Removing temporary console log indicating which version of autofill the user is currently loading --------- Co-authored-by: Jonathan Prusik <jprusik@users.noreply.github.com> Co-authored-by: Manuel <mr-manuel@outlook.it> Co-authored-by: Jonathan Prusik <jprusik@classynemesis.com>
2023-09-07 22:33:04 +02:00
if (!disabledAddLoginNotification || !disabledChangedPasswordNotification) {
// If the user has not disabled both notifications, then handle the initial page change (null -> actual page)
handlePageChange();
}
}
}
}
if (!showNotificationBar) {
return;
}
// Message Processing
[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
// 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;
}
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;
} 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
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
}
// End 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 &&
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 (
(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();
sendPlatformMessage({
command: "checkNotificationQueue",
});
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",
});
}
// End Page Detail Collection Methods
[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
// Form Detection and Submission Handling
[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
/**
* 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;
let formEl: HTMLFormElement = null;
2018-08-01 05:24:11 +02:00
if (formId != null && formId !== "") {
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),
[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-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,
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[],
[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 | 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 + '"]');
}
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
if (parentModal != null) {
2018-08-01 05:24:11 +02:00
const modalForms = parentModal.querySelectorAll("form");
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;
}
} 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) {
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 !== "")
.map((el: HTMLInputElement) => el.value);
2021-12-21 15:43:35 +01: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.
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
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
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
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
const buttonText = getButtonText(getSubmitButton(form, changePasswordButtonNames));
const matches = Array.from(changePasswordButtonContainsNames).filter(
(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
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
curPass = passwords[0];
newPass = passwords[1];
}
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`
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,
};
sendPlatformMessage({
command: "bgChangedPassword",
data: changePasswordRuntimeMessage,
});
break;
}
2021-12-21 15:43:35 +01: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
/**
* 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
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) {
const possibleSubmitButtons = Array.from(
wrappingEl.querySelectorAll(
'a, span, button[type="button"], ' + 'input[type="button"], button:not([type])',
),
) 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) => {
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);
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 &&
!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
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) {
// 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;
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
}
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.
*/
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 {
buttonText = button.innerText;
2021-12-21 15:43:35 +01: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
}
// End Form Detection and Submission Handling
[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 Bar Functions (open, close, height adjustment, etc.)
2018-05-09 20:00:13 +02:00
function closeExistingAndOpenBar(type: string, typeData: any) {
const barQueryParams = {
type,
isVaultLocked: typeData.isVaultLocked,
theme: typeData.theme,
removeIndividualVault: typeData.removeIndividualVault,
webVaultURL: typeData.webVaultURL,
};
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;
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");
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";
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) {
const el = document.getElementById(elId);
2018-05-09 20:00:13 +02:00
if (el != null) {
el.style.height = heightStyle;
2018-05-09 20:00:13 +02:00
}
2021-12-21 15:43:35 +01:00
}
// End Notification Bar Functions (open, close, height adjustment, etc.)
2021-12-21 15:43:35 +01:00
// Helper Functions
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;
}
// End Helper Functions
[PM-3285] Autofill v2 Feature Branch (#5939) * [PM-3285] Autofill v2 Feature Branch * [PM-2130] - Audit, Modularize, and Refactor Core autofill.js File (#5453) * split up autofill.ts, first pass * remove modification tracking comments * lessen and localize eslint disables * additional typing and formatting * update autofill v2 with PR #5364 changes (update/i18n confirm dialogs) * update autofill v2 with PR #4155 changes (add autofill support for textarea) Co-Authored-By: Manuel <mr-manuel@outlook.it> * move commonly used string values to constants * ts cleanup * [PM-2130] Starting work to re-architect autofillv2.ts * [PM-2130] Starting work to re-architect autofillv2.ts * [PM-2130] Working through autofill collect method * [PM-2130] Marking Removal of documentUUID as dead code * [PM-2130] Refining the implementation of collect and moving broken out utils back into class implementation * [PM-2130] Applying small refactors to AutofillCollect * [PM-2130] Refining the implementation of getAutofillFieldLabelTag to help with readability of the method * [PM-2130] Implementing jest tests for AutofillCollect methods * [PM-2130] Refining implementation for AutofillCollect * [PM-2200] Unit tests for autofill content script utilities with slight refactors (#5544) * add unit tests for urlNotSecure * add test coverage command * add unit tests for canSeeElementToStyle * canSeeElementToStyle should not return true if `animateTheFilling` or `currentEl` is false * add tests for selectAllFromDoc and getElementByOpId * clean up getElementByOpId * address some typing issues * add tests for setValueForElementByEvent, setValueForElement, and doSimpleSetByQuery * clean up setValueForElement and setValueForElementByEvent * more typescript cleanup * add tests for doClickByOpId and touchAllPasswordFields * add tests for doFocusByOpId and doClickByQuery * misc fill cleanup * move functions between collect and fill utils and replace getElementForOPID for duplicate getElementByOpId * add tests for isKnownTag and isElementVisible * rename addProp and remove redundant focusElement in favor of doFocusElement * cleanup * fix checkNodeType * add tests for shiftForLeftLabel * clean up and rename checkNodeType, isKnownTag, and shiftForLeftLabel * add tests for getFormElements * clean up getFormElements * add tests for getElementAttrValue, getElementValue, getSelectElementOptions, getLabelTop, and queryDoc * clean up and rename queryDoc to queryDocument * misc cleanup and rename getElementAttrValue to getPropertyOrAttribute * rebase cleanup * prettier formatting * [PM-2130] Fixing linting issues * [PM-2130] Fixing linting issues * [PM-2130] Migrating implementation for collect methods and tests for those methods into AutofillCollect context * [PM-2130] Migrating getPropertyOrAttribute method from utils to AutofillCollect * [PM-2130] Continuing migration of methods from collect utils into AutofillCollect * [PM-2130] Rework of isViewable method to better handle behavior for how we identify if an element is currently within the viewport * [PM-2130] Filling out implementation of autofill-insert * [PM-2130] Refining AutofillInsert * [PM-2130] Implementing jest tests for AutofillCollect methods and breaking out visibility related logic to a separate service * [PM-2130] Fixing jest tests for AutofillCollect * [PM-2130] Fixing jest tests for AutofillInit * [PM-2130] Adjusting how the AutofillFieldVisibilityService class is used in AutofillCollect * [PM-2130] Working through AutofillInsert implementation * [PM-2130] Migrating methods from fill.ts to AutofillInsert * [PM-2130] Migrating methods from fill.ts to AutofillInsert * [PM-2130] Applying fix for IntersectionObserver when triggering behavior in Safari and fixing issue with how we trigger an input event shortly after filling in a field * [PM-2130] Refactoring AutofillCollect to service CollectAutofillContentService * [PM-2130] Refactoring AutofillInsert to service InsertAutofillContentService * [PM-2130] Further organization of implementation * [PM-2130] Filling out missing jest test for AutofillInit.fillForm method * [PM-2130] Migrating the last of the collect jest tests to InsertAutofillContentService * [PM-2130] Further refactoring of elements including typing information * [PM-2130] Implementing jest tests for InsertAutofillContentService * [PM-2130] Implementing jest tests for InsertAutofillContentService * [PM-2130] Organization and refactoring of methods within InsertAutofillContent * [PM-2130] Implementation of jest tests for InsertAutofillContentService * [PM-2130] Implementation of Jest Test for IntertAutofillContentService * [PM-2130] Finalizing migration of methods and jest tests from util files into Autofill serivces * [PM-2130] Cleaning up dead code comments * [PM-2130] Removing unnecessary constants * [PM-2130] Finalizing jest tests for InsertAutofillContentService * [PM-2130] Refactoring FieldVisibiltyService to DomElementVisibilityService to allow service to act in a more general manner * [PM-2130] Implementing jest tests for DomElementVisibilityService * [PM-2130] Implementing jest tests for DomElementVisibilityService * [PM-2130] Implementing jest tests for DomElementVisibilityService * [PM-2130] Implementing jest tests for DomElementVisibilityService * [PM-2130] Breaking out the callback method used to resolve the IntersectionObserver promise * [PM-2130] Adding a comment explaining a fix for Safari * [PM-2130] Adding a comment explaining a fix for Safari * [PM-2130] Applying changes required for PM-2762 to implementation, and ensuring jest tests exist to validate the behavior * [PM-2130] Removing usage of IntersectionObserver when identifying element visibility due to broken interactions with React Components * [PM-2130] Fixing issue found when attempting to capture the elementAtCenterPoint in determining file visibility * [PM-2100] Create Unit Test Suite for autofill.service.ts (#5371) * [PM-2100] Create Unit Test Suite for Autofill.service.ts * [PM-2100] Finishing out tests for the getFormsWithPasswordFields method * [PM-2100] Implementing tests for the doAutofill method within the autofill service * [PM-2100] Working through implementation of doAutofill method * [PM-2100] Working through implementation of doAutofill method * [PM-2100] Finishing implementatino of isUntrustedIframe method within autofill service * [PM-2100] Finishing implementation of doAutoFill method within autofill service * [PM-2100] Finishing implementation of doAutoFillOnTab method within autofill service * [PM-2100] Working through tests for generateFillScript * [PM-2100] Finalizing generateFillScript method testing * [PM-2100] Starting implementation of generateLoginFillScript * [PM-2100] Working through tests for generateLoginFillScript * [PM-2100] Finalizing generateLoginFillScript method testing * [PM-2100] Removing unnecessary jest config file * [PM-2100] Fixing jest tests based on changes implemented within PM-2130 * [PM-2100] Fixing autofill mocks * [PM-2100] Fixing AutofillService jest tests * [PM-2100] Handling missing tests within coverage of AutofillService * [PM-2100] Handling missing tests within coverage of AutofillService.generateLoginFillScript * [PM-2100] Writing tests for AutofillService.generateCardFillScript * [PM-2100] Finalizing tests for AutofillService.generateCardFillScript * [PM-2100] Adding additional tests to cover changes introduced by TOTOP autofill PR * [PM-2100] Adding jest tests for Autofill.generateIdentityFillScript * [PM-2100] Finalizing tests for AutofillService.generateIdentityFillScript * [PM-2100] Implementing tests for AutofillService * [PM-2100] Implementing tests for AutofillService.loadPasswordFields * [PM-2100] Implementing tests for AutofillService.findUsernameField * [PM-2100] Implementing tests for AutofillService.findTotpField * [PM-2100] Implementing tests for AutofillService.fieldPropertyIsPrefixMatch * [PM-2100] Finalizing tests for AutofillService * [PM-2100] Modyfing placement of autofill-mocks * [PM-2100] Modyfing placement of autofill-mocks * [PM-2100] Removal of jest transform declaration * [PM-2130] Fixing issue with autofill service unit tests * [PM-2130] Fixing issue with autofill service unit tests * [PM-2130] Fixing test test for when we need to handle a password reprompt --------- Co-authored-by: Manuel <mr-manuel@outlook.it> Co-authored-by: Cesar Gonzalez <cgonzalez@bitwarden.com> Co-authored-by: Cesar Gonzalez <cesar.a.gonzalezcs@gmail.com> * [PM-3285] Migrating Changes from PM-1407 into autofill v2 refactor implementation * [PM-2747] Add Support for Feature Flag of Autofill Version (#5695) * [PM-2100] Create Unit Test Suite for Autofill.service.ts * [PM-2100] Finishing out tests for the getFormsWithPasswordFields method * [PM-2100] Implementing tests for the doAutofill method within the autofill service * [PM-2100] Working through implementation of doAutofill method * [PM-2100] Working through implementation of doAutofill method * [PM-2100] Finishing implementatino of isUntrustedIframe method within autofill service * [PM-2100] Finishing implementation of doAutoFill method within autofill service * [PM-2100] Finishing implementation of doAutoFillOnTab method within autofill service * [PM-2100] Working through tests for generateFillScript * split up autofill.ts, first pass * remove modification tracking comments * lessen and localize eslint disables * additional typing and formatting * update autofill v2 with PR #5364 changes (update/i18n confirm dialogs) * update autofill v2 with PR #4155 changes (add autofill support for textarea) Co-Authored-By: Manuel <mr-manuel@outlook.it> * move commonly used string values to constants * ts cleanup * [PM-2100] Finalizing generateFillScript method testing * [PM-2100] Starting implementation of generateLoginFillScript * [PM-2100] Working through tests for generateLoginFillScript * [PM-2100] Finalizing generateLoginFillScript method testing * [PM-2130] Starting work to re-architect autofillv2.ts * [PM-2130] Starting work to re-architect autofillv2.ts * [PM-2130] Working through autofill collect method * [PM-2130] Marking Removal of documentUUID as dead code * [PM-2130] Refining the implementation of collect and moving broken out utils back into class implementation * [PM-2130] Applying small refactors to AutofillCollect * [PM-2130] Refining the implementation of getAutofillFieldLabelTag to help with readability of the method * [PM-2130] Implementing jest tests for AutofillCollect methods * [PM-2130] Refining implementation for AutofillCollect * [PM-2200] Unit tests for autofill content script utilities with slight refactors (#5544) * add unit tests for urlNotSecure * add test coverage command * add unit tests for canSeeElementToStyle * canSeeElementToStyle should not return true if `animateTheFilling` or `currentEl` is false * add tests for selectAllFromDoc and getElementByOpId * clean up getElementByOpId * address some typing issues * add tests for setValueForElementByEvent, setValueForElement, and doSimpleSetByQuery * clean up setValueForElement and setValueForElementByEvent * more typescript cleanup * add tests for doClickByOpId and touchAllPasswordFields * add tests for doFocusByOpId and doClickByQuery * misc fill cleanup * move functions between collect and fill utils and replace getElementForOPID for duplicate getElementByOpId * add tests for isKnownTag and isElementVisible * rename addProp and remove redundant focusElement in favor of doFocusElement * cleanup * fix checkNodeType * add tests for shiftForLeftLabel * clean up and rename checkNodeType, isKnownTag, and shiftForLeftLabel * add tests for getFormElements * clean up getFormElements * add tests for getElementAttrValue, getElementValue, getSelectElementOptions, getLabelTop, and queryDoc * clean up and rename queryDoc to queryDocument * misc cleanup and rename getElementAttrValue to getPropertyOrAttribute * rebase cleanup * prettier formatting * [PM-2130] Fixing linting issues * [PM-2130] Fixing linting issues * [PM-2130] Migrating implementation for collect methods and tests for those methods into AutofillCollect context * [PM-2130] Migrating getPropertyOrAttribute method from utils to AutofillCollect * [PM-2130] Continuing migration of methods from collect utils into AutofillCollect * [PM-2130] Rework of isViewable method to better handle behavior for how we identify if an element is currently within the viewport * [PM-2130] Filling out implementation of autofill-insert * [PM-2130] Refining AutofillInsert * [PM-2130] Implementing jest tests for AutofillCollect methods and breaking out visibility related logic to a separate service * [PM-2130] Fixing jest tests for AutofillCollect * [PM-2130] Fixing jest tests for AutofillInit * [PM-2130] Adjusting how the AutofillFieldVisibilityService class is used in AutofillCollect * [PM-2130] Working through AutofillInsert implementation * [PM-2130] Migrating methods from fill.ts to AutofillInsert * [PM-2130] Migrating methods from fill.ts to AutofillInsert * [PM-2130] Applying fix for IntersectionObserver when triggering behavior in Safari and fixing issue with how we trigger an input event shortly after filling in a field * [PM-2130] Refactoring AutofillCollect to service CollectAutofillContentService * [PM-2130] Refactoring AutofillInsert to service InsertAutofillContentService * [PM-2130] Further organization of implementation * [PM-2130] Filling out missing jest test for AutofillInit.fillForm method * [PM-2130] Migrating the last of the collect jest tests to InsertAutofillContentService * [PM-2130] Further refactoring of elements including typing information * [PM-2130] Implementing jest tests for InsertAutofillContentService * [PM-2130] Implementing jest tests for InsertAutofillContentService * [PM-2130] Organization and refactoring of methods within InsertAutofillContent * [PM-2130] Implementation of jest tests for InsertAutofillContentService * [PM-2130] Implementation of Jest Test for IntertAutofillContentService * [PM-2130] Finalizing migration of methods and jest tests from util files into Autofill serivces * [PM-2130] Cleaning up dead code comments * [PM-2130] Removing unnecessary constants * [PM-2130] Finalizing jest tests for InsertAutofillContentService * [PM-2130] Refactoring FieldVisibiltyService to DomElementVisibilityService to allow service to act in a more general manner * [PM-2130] Implementing jest tests for DomElementVisibilityService * [PM-2130] Implementing jest tests for DomElementVisibilityService * [PM-2130] Implementing jest tests for DomElementVisibilityService * [PM-2130] Implementing jest tests for DomElementVisibilityService * [PM-2130] Breaking out the callback method used to resolve the IntersectionObserver promise * [PM-2100] Removing unnecessary jest config file * [PM-2100] Fixing jest tests based on changes implemented within PM-2130 * [PM-2100] Fixing autofill mocks * [PM-2100] Fixing AutofillService jest tests * [PM-2100] Handling missing tests within coverage of AutofillService * [PM-2100] Handling missing tests within coverage of AutofillService.generateLoginFillScript * [PM-2100] Writing tests for AutofillService.generateCardFillScript * [PM-2100] Finalizing tests for AutofillService.generateCardFillScript * [PM-2100] Adding additional tests to cover changes introduced by TOTOP autofill PR * [PM-2100] Adding jest tests for Autofill.generateIdentityFillScript * [PM-2100] Finalizing tests for AutofillService.generateIdentityFillScript * [PM-2100] Implementing tests for AutofillService * [PM-2130] Adding a comment explaining a fix for Safari * [PM-2130] Adding a comment explaining a fix for Safari * [PM-2100] Implementing tests for AutofillService.loadPasswordFields * [PM-2100] Implementing tests for AutofillService.findUsernameField * [PM-2100] Implementing tests for AutofillService.findTotpField * [PM-2100] Implementing tests for AutofillService.fieldPropertyIsPrefixMatch * [PM-2100] Finalizing tests for AutofillService * [PM-2747] Add Support for Feature Flag of Autofill Version * [PM-2747] Adding Support for Manifest v3 within the implementation * [PM-2747] Modifying how the feature flag for autofill is named * [PM-2747] Modifying main.background.ts to load the ConfigApiService correctly * [PM-2747] Refactoring trigger of autofill scripts to be a simple immediately invoked function * [PM-2100] Modyfing placement of autofill-mocks * [PM-2100] Modyfing placement of autofill-mocks * [PM-2100] Removal of jest transform declaration * [PM-2130] Applying changes required for PM-2762 to implementation, and ensuring jest tests exist to validate the behavior * [PM-2747] Modifying how we inject the autofill scripts to ensure we are injecting into all frames within a page * [PM-2130] Removing usage of IntersectionObserver when identifying element visibility due to broken interactions with React Components * [PM-2130] Fixing issue found when attempting to capture the elementAtCenterPoint in determining file visibility * [PM-2100] Create Unit Test Suite for autofill.service.ts (#5371) * [PM-2100] Create Unit Test Suite for Autofill.service.ts * [PM-2100] Finishing out tests for the getFormsWithPasswordFields method * [PM-2100] Implementing tests for the doAutofill method within the autofill service * [PM-2100] Working through implementation of doAutofill method * [PM-2100] Working through implementation of doAutofill method * [PM-2100] Finishing implementatino of isUntrustedIframe method within autofill service * [PM-2100] Finishing implementation of doAutoFill method within autofill service * [PM-2100] Finishing implementation of doAutoFillOnTab method within autofill service * [PM-2100] Working through tests for generateFillScript * [PM-2100] Finalizing generateFillScript method testing * [PM-2100] Starting implementation of generateLoginFillScript * [PM-2100] Working through tests for generateLoginFillScript * [PM-2100] Finalizing generateLoginFillScript method testing * [PM-2100] Removing unnecessary jest config file * [PM-2100] Fixing jest tests based on changes implemented within PM-2130 * [PM-2100] Fixing autofill mocks * [PM-2100] Fixing AutofillService jest tests * [PM-2100] Handling missing tests within coverage of AutofillService * [PM-2100] Handling missing tests within coverage of AutofillService.generateLoginFillScript * [PM-2100] Writing tests for AutofillService.generateCardFillScript * [PM-2100] Finalizing tests for AutofillService.generateCardFillScript * [PM-2100] Adding additional tests to cover changes introduced by TOTOP autofill PR * [PM-2100] Adding jest tests for Autofill.generateIdentityFillScript * [PM-2100] Finalizing tests for AutofillService.generateIdentityFillScript * [PM-2100] Implementing tests for AutofillService * [PM-2100] Implementing tests for AutofillService.loadPasswordFields * [PM-2100] Implementing tests for AutofillService.findUsernameField * [PM-2100] Implementing tests for AutofillService.findTotpField * [PM-2100] Implementing tests for AutofillService.fieldPropertyIsPrefixMatch * [PM-2100] Finalizing tests for AutofillService * [PM-2100] Modyfing placement of autofill-mocks * [PM-2100] Modyfing placement of autofill-mocks * [PM-2100] Removal of jest transform declaration * [PM-2747] Applying a fix for a race condition that can occur when loading the notification bar and autofiller script login * [PM-2747] Reverting removal of autofill npm action. Now this will force usage of autofill-v2 regardless of whether a feature flag is set or not * [PM-2747] Fixing logic error incorporated when merging in master * [PM-2130] Fixing issue with autofill service unit tests * [PM-2130] Fixing issue with autofill service unit tests * [PM-2747] Fixing issue present with notification bar merge * [PM-2130] Fixing test test for when we need to handle a password reprompt * [PM-2747] Fixing wording for webpack script * [PM-2747] Addressing stylistic changes requested from code review * [PM-2747] Addressing stylistic changes requested from code review --------- Co-authored-by: Jonathan Prusik <jprusik@classynemesis.com> Co-authored-by: Manuel <mr-manuel@outlook.it> Co-authored-by: Jonathan Prusik <jprusik@users.noreply.github.com> * [PM-3285] Applying stylistic changes suggested by code review for the feature flag implementation * [PM-3285] Adding temporary console log to validate which version is being used * [PM-3285] Removing temporary console log indicating which version of autofill the user is currently loading --------- Co-authored-by: Jonathan Prusik <jprusik@users.noreply.github.com> Co-authored-by: Manuel <mr-manuel@outlook.it> Co-authored-by: Jonathan Prusik <jprusik@classynemesis.com>
2023-09-07 22:33:04 +02:00
}
async function getFromLocalStorage(keys: string | string[]): Promise<Record<string, any>> {
return new Promise((resolve) => {
chrome.storage.local.get(keys, (storage: Record<string, any>) => resolve(storage));
});
}