Bumps [@babel/core](https://github.com/babel/babel/tree/HEAD/packages/babel-core) from 7.14.6 to 7.14.8.
- [Release notes](https://github.com/babel/babel/releases)
- [Changelog](https://github.com/babel/babel/blob/main/CHANGELOG.md)
- [Commits](https://github.com/babel/babel/commits/v7.14.8/packages/babel-core)

---
updated-dependencies:
- dependency-name: "@babel/core"
  dependency-type: direct:development
  update-type: version-update:semver-patch
...
Signed-off-by: dependabot[bot] <support@github.com>

Rather than use a dedicated getter to expose the sidebar frame, it
seemed better on a second look to use the existing `sidebar.iframe`
property that exposes the `<iframe>` element, but document and test that
property.

Add comments to clarify various aspects of the way the host/guest frames
are set up and interact.

The logic used by guest/host and sidebar frames to find each other in
`Discovery#startDiscovery` relied on traversing the frame tree starting
from `window.top` using `window.frames`. Since `window.frames` doesn't
include frames in shadow roots, this did not work if _both_ the guest and
sidebar are contained within a shadow root. The sidebar is always
contained in a shadow root created by the `<hypothesis-sidebar>`
element, so this simplifies to only working if the guest/host is not
contained in a shadow root.

For current use cases it is possible for guest frames to get a direct
reference to the sidebar frame they should be communicating with and for
the sidebar to get direct a reference to the host frame (its parent).
This avoids the need for `window.frames` traversal.

This commit leverages that by changing `startDiscovery` to take an
explicit array of frames to ping. Guest frames invoke `startDiscovery`
passing a reference to the sidebar frame and sidebar frames invoke
`startDiscovery` passing a reference to the parent (host) frame.

This fixes the following scenarios:

 - Hypothesis not completing loading if host frame is contained within a
   shadow root. eg. In the VitalSource book reader.

 - Same-origin guest frames loading Hypothesis after the sidebar has
   already loaded. See http://localhost:3000/document/parent-frame test
   case in client dev server.

 - Multiple sidebars attempting to connect to the same guest frame, if
   Hypothesis is loaded multiple times in different parts of the frame
   tree. See http://localhost:3000/document/multi-frames test case in
   client dev server.

This approach has some limitations:

 - Child guest frames which are not same-origin with the parent host frame
   are not supported.
 - Child guest frames which attempt to connect to the sidebar before it
   has loaded will fail to connect. This could be remedied by making the
   guest wait for confirmation of the sidebar having loaded before
   calling `connectToSidebar`. This doesn't affect the host frame since
   the sidebar pings that frame directly.

These limitations are acceptable in the short term but will be remedied
by a larger overhaul of inter-frame communication that is currently
being worked on.

Add a test case that reproduces the scenario encountered in the new
VitalSource book reader [1] where Hypothesis is loaded into an iframe
whose `<iframe>` element is contained within a shadow root and is thus
not accessible via `window.frames`. This scenario currently prevents the
Hypothesis sidebar from discovering and connecting to the frame.

Split the test HTML and PDF documents into two groups: those that test
general usage of Hypothesis with a particular document type using the
default configuration and those that test specific scenarios, edge cases
or non-standard configuration.

The link descriptions for the scenario tests have been changed to focus
on the scenario, since that is what is important, rather than the
document title.

Check that multi-valued parameters are handled as expected when making
API requests. The test uses the example of a `search` API call with
multiple URIs, as that's the most important example.

Add a test case that would have caught the regression introduced by
https://github.com/hypothesis/client/pull/3582.

This argument was not used by any callers of `Bridge#onConnect` and
removing it eliminates a difference between creating a channel that uses
`Window.postMessage` vs one that uses `MessagePort`.

The need for this "testing only" code can be removed by improving the way
that we simulate the `connect` message being handled in tests.

Initially, I tried to if/else portions of the code to accommodate for
`MessagePort`, aiming to avoid duplication of the code (like I did for
`shared/frame-rpc.js` #3565). However, I found that, unlike
`shared/frame-rpc.js`, this resulted into a spaghetti-type of code, not
very understandable.

Then, I decided to create two internal methods to support both the
current communication using `Window` and the new `MessagePort`. This in
my opinion leads to a clearer results, although some code is duplicated
in both methods.

This PR will result on a reduction in code coverage, which will be fix
by #3590.

Bumps [karma-browserify](https://github.com/nikku/karma-browserify) from 8.0.0 to 8.1.0.
- [Release notes](https://github.com/nikku/karma-browserify/releases)
- [Commits](https://github.com/nikku/karma-browserify/compare/v8.0.0...v8.1.0)

---
updated-dependencies:
- dependency-name: karma-browserify
  dependency-type: direct:development
  update-type: version-update:semver-minor
...
Signed-off-by: dependabot[bot] <support@github.com>

Bumps [@hypothesis/frontend-shared](https://github.com/hypothesis/frontend-shared) from 3.4.0 to 3.5.0.
- [Release notes](https://github.com/hypothesis/frontend-shared/releases)
- [Changelog](https://github.com/hypothesis/frontend-shared/blob/v3.5.0/CHANGELOG.md)
- [Commits](https://github.com/hypothesis/frontend-shared/compare/v3.4.0...v3.5.0)

---
updated-dependencies:
- dependency-name: "@hypothesis/frontend-shared"
  dependency-type: direct:development
  update-type: version-update:semver-minor
...
Signed-off-by: dependabot[bot] <support@github.com>

In addition, I simplified the execution of the callback.

Bumps [aws-sdk](https://github.com/aws/aws-sdk-js) from 2.943.0 to 2.948.0.
- [Release notes](https://github.com/aws/aws-sdk-js/releases)
- [Changelog](https://github.com/aws/aws-sdk-js/blob/master/CHANGELOG.md)
- [Commits](https://github.com/aws/aws-sdk-js/compare/v2.943.0...v2.948.0)

---
updated-dependencies:
- dependency-name: aws-sdk
  dependency-type: direct:development
  update-type: version-update:semver-minor
...
Signed-off-by: dependabot[bot] <support@github.com>

Bumps [axe-core](https://github.com/dequelabs/axe-core) from 4.2.3 to 4.3.1.
- [Release notes](https://github.com/dequelabs/axe-core/releases)
- [Changelog](https://github.com/dequelabs/axe-core/blob/develop/CHANGELOG.md)
- [Commits](https://github.com/dequelabs/axe-core/compare/v4.2.3...v4.3.1)

---
updated-dependencies:
- dependency-name: axe-core
  dependency-type: direct:development
  update-type: version-update:semver-minor
...
Signed-off-by: dependabot[bot] <support@github.com>

Bumps [autoprefixer](https://github.com/postcss/autoprefixer) from 10.3.0 to 10.3.1.
- [Release notes](https://github.com/postcss/autoprefixer/releases)
- [Changelog](https://github.com/postcss/autoprefixer/blob/main/CHANGELOG.md)
- [Commits](https://github.com/postcss/autoprefixer/compare/10.3.0...10.3.1)

---
updated-dependencies:
- dependency-name: autoprefixer
  dependency-type: direct:development
  update-type: version-update:semver-patch
...
Signed-off-by: dependabot[bot] <support@github.com>

Bumps [eslint](https://github.com/eslint/eslint) from 7.30.0 to 7.31.0.
- [Release notes](https://github.com/eslint/eslint/releases)
- [Changelog](https://github.com/eslint/eslint/blob/master/CHANGELOG.md)
- [Commits](https://github.com/eslint/eslint/compare/v7.30.0...v7.31.0)

---
updated-dependencies:
- dependency-name: eslint
  dependency-type: direct:development
  update-type: version-update:semver-minor
...
Signed-off-by: dependabot[bot] <support@github.com>

The word `listener` matches better the internal property names of
`this.channelListeners` and `this.onConnectListeners`. In addition, it
helps to differentiate from the `callback` function which is the last
(optional) argument of the `listener`. The `callback` is used to send
back a `postMessage` response to the other frame/s.

The RPC class design requires all the handlers to be provided up-front.
Currently, adding a new handler after a channel is created has no
effect. To make more obvious this misuse, the method now throws an
error.

`this.link` was defined as `Array<{channel: RPC, window: Window}>`
however, the `window` property was never used. I am guessing that the
original idea was to avoid creating additional channels for the same
frame, however, that was never implemented.

I take the decision of removing the `window` property and converting the
`this.link` to a type of `RPC[]`.

As far as I know, the `return` statement don't have any effect.

As pointed by @robertknight `Array.from` was probably a leftover from
the tool that was used to convert CoffeeScript to JavaScript.

I also include a minor change to improve the readability extracting the
callback from the `args`.

This reverts commit e466e836.

This reverts commit ede3280f.

The tag filter's regex was not capturing words at the start of a line which had non-word ASCII or unicode characters. Additionally it was not escaping special chars for the regex query.

This fix first splits the tag based on words, escapes the query, searches for any match, and then additionally checks the entire tag against the query

The tag filter's regex was not capturing words at the start of a line which had non-word ASCII or unicode characters. Additionally it was not escaping special chars for the regex query.

This fix first splits the tag based on words, escapes the query, searches for any match, and then additionally checks the entire tag against the query

The regex-ex was not capturing words at the start of a line which had ASCII characters.

This fix first splits the string based on words and searches for any match and then additionally checks the entire string against the query

This method is available after including the `dom.iterable` typings.
Also the use of `entries()` is unnecessary because the result is the
same as directly iterating over the `URLSearchParams` instance.

Also add an example for `stringify`.

For the client's very simple query string generating and parsing needs
we can avoid this dependency by using a very simple wrapper around
`URLSearchParams`. This also improves type checking since this
dependency didn't provide types and we weren't using the
@types/query-string package.

The `stringify` function sorts parameters in the returned string for
consistency with query-string's behavior.

This method was not used anywhere. In addition for this method to have
the intended effect, it needed to be called before `createChannel`,
because at that point the methods are registered with the `RPC` class
and there is no way to remove the listeners.

The `Bridge` code was written before we had good mocking tools in the
client. As a result the `Bridge` class mocks `RPC` in an unconventional
way where it constructs the real class, but then stubs out specific
methods. Also tests varied in the degree to which they tested only
`Bridge` vs Bridge + RPC together.

This commit mocks `RPC` in bridge-test.js using our standard mocking
tools and makes all tests in the file unit tests. This involved some
significant changes to the `onConnect` tests.

* change `@deprecated` for a comment
* added a test to cover some missing lines in `_isValidSender` function.
* `_isValidMessage` renamed to `_parseMessage`
* created helper function `waitForMessageDelivery`
* parametrise test

RPC:
* added `@deprecated` statements and additional comments
* removed `this._destroyed` for the listener checks, because the
  listener is removed when called `destroy()`.
* added `this._port.close()` in addition to removing the listner.

`bridge-test`:
* refactor all the `function () {}` to arrow functions

`frame-rpc-test.js`:
* added these tests to check the `MessageChannel` functionality.

Created a couple of utility methods to avoid duplication of code and
enable to decouple RPC for `Window` or for `MessagePort`.

It simplifies the code.