* 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
- 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
Patrick H. Lauke
Thomas Rittson
Vincent Salucci
Oscar Hinton
Matt Gibson
Kyle Spearrin