This means that sub-frames will get injected with the same set of whitelisted config values from the top level.
It’s good that there’s a whitelisting of the config before reaching this point, so there’s less of a security concern with the injection

This was done so I can have the sub-frame guests read the `config.showHighlights` option in order to set the initial highlight visibility at that level.

I want to prevent the potential chaining of config params here since I plan to pass the config object around in new places, the sub-frame guest level for example.

Adding waitForFrameObserver in frame manipulation tests

Multiple frame detection improvements

Improve tests for different localStorage-not-accessible situations

Run all of the existing tests to check behavior when localStorage is not
accessible, for the case where accessing `window.localStorage` throws.

The previous tests for this situation only tested the behavior of the
service constructor.

Use fallback when local storage throws

Whitelist config settings needed by multi-frame support

Better differentiation from .isLoaded

The tests are in a response to an issue found when frames get added/removed in quick succession. It was due to the timing of the debounce used in FrameObserver.
This also works to test against possible edge cases and ensures robustness of the feature by going full circle.

Reduces the footprint of CrossFrame by shifting away responsibility into this new module.

To my knowledge this is temporarily until a better flagging or set of options comes by

Use CrossFrame to show/hide the Sidebar

Enable feature flagged highlighter interface

Fix sidebar app failing to load in Firefox extension.

In some environments, accessing the "localStorage" property of the
window is enough to throw an error.

`Sidebar` no longer handles the click/touchstart on the document itself, therefore the test for this was replaced with a
 test in `Guest`, a test for if it’s sending “hideSidebar” event via `CrossFrame` when the document is clicked

Convert "flash" service to JS

Enable feature flagging in the annotation layer

Angular has a check for Chrome Packaged Apps in its `$sniffer` service
which changes the behavior of the $location service and in the Firefox
extension, triggers a redirect from `/client/app.html` to
`/#client/app.html` on startup, breaking the sidebar app.

This commit works around the problem by adding a fake
`window.chrome.app` object to convince Angular that the Firefox
extension is not a Chrome Packaged App.

Issue reported upstream at https://github.com/angular/angular.js/issues/16068

Remove `angular.bind` dependency since `Function.prototype.bind` is now
ubiquitous.

Upgrade Sinon.JS to its latest version

Rename config.app to sidebarAppUrl

The code in `src/boot/` reads the `sidebarAppUrl` setting from
`js-hypothesis-config` JSON objects in the host page (defaulting to the
value of the build-time `__SIDEBAR_APP_URL__` template variable, if there's
no `sidebarAppUrl` setting in the host page).

`boot/` then writes `sidebarAppUrl` as the value of the `href` of a
`<link type="application/annotator+html">` element that it injects into
the host page.

Later, the code in `src/annotator/` reads this `<link>` element's `href`
in as the `config.app` setting, which it uses as the `src` of the
sidebar app's `<iframe>` that it injects into the host page.

So the variable that's named `sidebarAppUrl` / `__SIDEBAR_APP_URL__` at
boot / build time* gets renamed to `config.app` when it makes it into
the `src/annotator` code.

Fix this by renaming `config.app` in `src/annotator` to
`config.sidebarAppUrl` so that the variable is named consistently.

`*` In the build-time code there's also a `defaultSidebarAppUrl`
variable, and an `H_SERVICE_URL` environment variable, which also belong to
the same sidebarAppUrl config setting.