* Make <content> element explicitly non-focusable
Some browsers (Firefox, upcoming versions of Chrome https://bugs.chromium.org/p/chromium/issues/detail?id=585413) make containers with `overflow: auto` / `overflow: scroll` (and the `-x` / `-y` variants) keyboard-focusable. This leads to a very awkward experience for assistive technology users navigating through the extension window, as for every view, the entire `<content>` container receives focus (and screen readers try to announce all its content in one go) before you reach the actual first control. To counteract this behaviour, this adds an explicit `tabindex="-1"` to these elements.
* Change `<content>` to `<main>`
More semantically accurate. See https://github.com/bitwarden/browser/pull/2245#issuecomment-1104553312
* Update scss to target `main` instead of `content`
* Change the previously existing `<main>` to generic `<div>`, tweak styles accordingly
Can't have two separate `<main>` elements, especially not nested ones. The original `<main>` was really just a handy wrapper for the component, but semantically should be neutral
* Create background in popup if private mode, remove gates
* Add messaging support to runtime in private mode
* Fix messaging services and general bootstrap logic
* Add private mode warning, remove old component
* Deprecate launchGuardService
* Require in memory account for user to be considered authenticated
* Don't change icon for private mode windows
* Set all icons from background page
* Pull in jslib
* Create new state models
* Create browser specific stateService
* Remove registration deprecated services, register stateService
* Replace usage of deprecated services (user, constants)
* Add missing properties to BrowserGroupingsComponentState
* Remove StorageService from initFactory
* Clear the correct state
* Add null check when restoring send-grouping state
* add remember email
* Initialize stateservice in services.module
* Fix 'lock now' not working
* Comment to remove setting defaults on install
* Pull jslib
* Remove setting defaults on install
* Bump jslib
* Pass the current userId to services when logging out
* Bump jslib
* Override vaultTimeout default on account addition
* Pull latest jslib
* Retrieve vaultTimeout from stateService
* Record activity per Account
* Add userId to logout and add fallback if not present
* Register AccountFactory
* Pass userId in messages
* Base changes for account switching di fixes (#2280)
* [bug] Null checks on Account init
* [bug] Use same stateService instance for all operations
We override the stateService in browser, but currently don't pull the background service into popup and allow jslib to create its own instance of the base StateService for jslib services.
This causes a split in in memory state between the three isntances that results in many errors, namely locking not working.
* [chore] Update jslib
* Pull in jslib
* Pull in jslib
* Pull in latest jslib to multiple stateservice inits
* Check vault states before executing processReload
* Adjust iterator
* Update native messaging to include the userId (#2290)
* Re-Add UserVerificationService
* Fix email not being remembered by base component
* Improve readability of reloadProcess
* Removed unneeded null check
* Fix constructor dependency (stateService)
* Added missing await
* Simplify dependency registration
* Fixed typos
* Reverted back to simple loop
* Use vaultTimeoutService to retrieve Timeout
Co-authored-by: Addison Beck <abeck@bitwarden.com>
Co-authored-by: Oscar Hinton <oscar@oscarhinton.com>
* Add iframe allow to initial load
Chrome seems to balk at this attribute being added after the fact. It
may be a race condition or an intentional block, but adding to the
template fixes our missing allow attribute problem.
* Update jslib
- more semantically accurate, will expose these as buttons to assistive technologies
- note: while having block-level elements like `<div>` inside a `<button>` is an html validation error, it does not affect functionality as long as there's no more structure inside it