* 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
- `visibility:hidden` also hides text from assistive technologies, leading to the settings link lacking an accessible name when not hovered (focused with keyboard only, for instance)
- turn the styles around and hide the non-hovered link's span with "visually hidden" styles https://www.a11yproject.com/posts/2013-01-11-how-to-hide-content/
- also include `:focus` to make the text visible when hovered (for sighted keyboard users)