To resolve some security alerts:

```diff
- found 223 vulnerabilities (24 low, 129 moderate, 69 high, 1 critical)
+ found 198 vulnerabilities (24 low, 129 moderate, 44 high, 1 critical)
```

All changelogs reviewed manually for breaking changes and there are none. More updates are coming in the follow-up PRs.

Fixes #3680

## [6.3.4](v6.3.3...v6.3.4) (2021-06-14)

### Bug Fixes

* bump production dependencies within SemVer ranges ([#3682](#3682)) ([36467a8](36467a8)), closes [#3680](#3680)

* chore: migrate to GitHub Actions for CI

- Use headless browsers instead of xfvb where possible.
- Replace commitlint-travis with usage of the base commitlint as there is no official CLI for GitHub Actions.
- Remove CI badges as GitHub displays the CI status natively for each commit.

* chore: use BS plugin's compatible env names

See: https://github.com/karma-runner/karma-browserstack-launcher#:~:text=username%20your%20BS,BROWSERSTACK_ACCESS_KEY%20env%20variable.

* chore: improve GH Actions workflow's job names

This is needed because in GH's configuration, we need to distinguish the required checks for protected branches and giving them unique names results in easiera configs.

* chore: remove client testing from the windows job of test.yml

The purpose of this test is to make sure that client JS works in different browsers and it does not need to be run on different OS/Node versions.

Co-authored-by: Jonathan Ginsburg <jginsburgn@google.com>

This is the [default environment value name provided by GitHub Actions][1].

Also:

* Format the YAML workflow files.

[1]: https://docs.github.com/en/actions/security-guides/automatic-token-authentication#about-the-github_token-secret

In our client tests, for BrowserStack, reduce the `browserDisconnectTimeout`
and the `browserNoActivityTimeout` to a minute, instead of 5. Also, reduce the
concurrency of browsers to 2 instead of 3. This is because BS is being flaky
when handling many browsers concurrently and, when a browser has been
disconnected it will generally not come back, so we do not need to wait a whole
5 minutes; it is better to just use another try from the
`browserDisconnectTolerance` configuration pool. The overall result is a more
efficient CI run.

We have a script, which is run as part of release process to automatically
update the documentation website:
https://github.com/karma-runner/karma-runner.github.com. The DOCS_GITHUB_TOKEN
secret contains a GitHub token with write access to the website repository.

This should've happened in
4b3b072.

## [6.3.5](v6.3.4...v6.3.5) (2021-10-20)

### Bug Fixes

* **client:** prevent socket.io from hanging due to mocked clocks ([#3695](#3695)) ([105da90](105da90))

Closes #3713

## [6.3.6](v6.3.5...v6.3.6) (2021-10-25)

### Bug Fixes

* bump vulnerable ua-parser-js version ([6f2b2ec](6f2b2ec)), closes [#3713](#3713)

Configurations are updated to accommodate for breaking changes.

Previously %X_UA_COMPATIBLE% marker was only replaced if it was located at the start of the line.
The limitation looks pretty arbitrary and caused the marker not to be replaced in the custom
debug.html file used by Angular CLI as the marker was not located at the start of the line
(probably because the file was re-formatted). This commit changes the behavior to replace the
marker anywhere within the file, not just at the start of the line and thus fixes the problem
for Angular CLI and potentially other people using custom files.

Fixes #3711

## [6.3.7](v6.3.6...v6.3.7) (2021-11-01)

### Bug Fixes

* **middleware:** replace %X_UA_COMPATIBLE% marker anywhere in the file ([f1aeaec](f1aeaec)), closes [#3711](#3711)

The commit conventions enforced by commitlint (conventional) were different than the conventions used by the semantic-release (angular). In practice, is was never a problem as they are pretty similar, but it's better to be consistent anyways. Update the commit conventions documentation according to the change and also extend it with the information about which kind of release is triggered by which commit type. Add explicit configuration for release rules for semantic-release to the configuration file - rules are the same as before, but now it is easier to see what they actually are.

Previously, we relied on husky package to set up the Git hooks to automatically lint code and check the commit message conventions. While it is a nice feature it causes extra delays on commit/push for more experienced contributors and we still get many PRs with incorrect commit messages from the first-time contributors. Given the above reasons remove the husky dependency, Git hooks and replace them with a script which can be used locally. Note that CI continues to validate the commit message conventions as before.

For some projects, a preprocessor like TypeScript may run to downlevel
certain features to a lower ECMAScript target. e.g. a project may
consume Angular for example, which ships ES2020.

If TypeScript, ESBuild, Babel etc. is used to do this, they may inject
generated code which does not map to any original source. If any of
these helpers (the generated code) is then part of a stack trace, Karma
will incorrectly report an error for an unresolved source map position.

Generated code is valid within source maps and can be denoted as
mappings with a 1-variable-length mapping. See the source map spec:
https://sourcemaps.info/spec.html.

The warning for generated code is especially bad when the majority of
file paths, and the actually relevant-portions in the stack are
resolved properly. e.g.

Errors initially look like this without the source mapping processing
of Karma:

(See PR description as commit lint does not allow for long stack
traces..)

A helper function shows up in the stacktrace but has no original mapping as it is
purely generated by TypeScript/ESbuild etc. The following warning is
printed and pollutes the test output while the remaining stack trace
paths (as said before), have been remapped properly:

```
SourceMap position not found for trace: http://localhost:9877/base/angular_material/
  src/material/select/testing/unit_tests_bundle_spec.js:26:26
```

The resolved stacktrace looks like this after the transformation:

(see PR description as commit lint does not allow for long stack traces
here..)

More details on the scenario here:
https://gist.github.com/devversion/549d25915c2dc98a8896ba4408a1e27c.

## [6.3.8](v6.3.7...v6.3.8) (2021-11-07)

### Bug Fixes

* **reporter:** warning if stack trace contains generated code invocation ([4f23b14](4f23b14))

Fixes a grammar error in the log message when a browser does not capture in time.

Fixes #3716

The problem was caused by a race condition in the client JS implementation. When the `restartOnFileChange` option is enabled, the server would send [two commands](https://github.com/karma-runner/karma/blob/b153355de7e05559d877a625c9b0c5d23a3548bd/lib/server.js#L377) to the browser: `stop` and `execute`. Both of these commands navigate the context. `stop` navigates to the blank page, while `execute` navigate to the `context.html` thus triggering a test run. The `execute` command would trigger the navigation synchronously, but the `stop` command would trigger it on the next event loop tick. As a result, if both commands arrive almost at the same time, their order is effectively reversed: first schedule new execution and then immediately stop it. The bug is resolved by handling both commands synchronously thus ensuring correct order.

The setTimeout() call in question was introduced in 15d80f4 to solve #27 and was retained over time. It's not completely clear why the timeout was added, but it does not seem to be relevant.

With `clearContext: true`, karma will reset the context and thus cancel any scheduled navigations as soon as the test framework has reported the `complete` event. As navigations are canceled they don't affect karma and thus karma does not care about them. It's true that the user may have a test with race conditions (e.g. missing `done` callback), but it is up to them to investigate and fix it.

With `clearContext: false`, the same logic applies, that karma does not care about navigations after `complete` event as long as they don't break karma itself. Here it gets a bit tricky:

- Navigation within the same origin is undesired, but it doesn't break karma and the next execution can proceed normally.
- Navigation to a different origin however is a problem as after such navigation the iframe becomes cross-origin and karma client will not be able to navigate it to the `context.html` or interact with it at all for that matter until the page reload (see [this SO answer](https://stackoverflow.com/q/25098021/1377864)). This will break the watch mode, but IMO we can let it be given that the case is quite uncommon, the user will see the browser window displaying something unexpected and the error in the CLI output. The changes in this commit don't make this case any worse and it does not seem to be possible to prevent such problematic navigations with the current state of browsers per https://developer.mozilla.org/en-US/docs/Web/API/WindowEventHandlers/onbeforeunload:

> To combat unwanted pop-ups, some browsers don't display prompts created in beforeunload event handlers unless the page has been interacted with. Moreover, some don't display them at all.

Fixes #3724

## [6.3.9](v6.3.8...v6.3.9) (2021-11-16)

### Bug Fixes

* restartOnFileChange option not restarting the test run ([92ffe60](92ffe60)), closes [#27](#27) [#3724](#3724)

Fixes #3734

## [6.3.10](v6.3.9...v6.3.10) (2022-01-08)

### Bug Fixes

* **logger:** create parent folders if they are missing ([0d24bd9](0d24bd9)), closes [#3734](#3734)

\d no longer matches since 6.3.10 because of two-digit number.

## [6.3.11](v6.3.10...v6.3.11) (2022-01-13)

### Bug Fixes

* **deps:** pin colors package to 1.4.0 due to security vulnerability ([a5219c5](a5219c5))

Add security.md file.

## [6.3.12](v6.3.11...v6.3.12) (2022-01-24)

### Bug Fixes

* remove depreciation warning from log4js ([41bed33](41bed33))

Fixes #3751

## [6.3.13](v6.3.12...v6.3.13) (2022-01-31)

### Bug Fixes

* **deps:** bump log4js to resolve security issue ([5bf2df3](5bf2df3)), closes [#3751](#3751)

The `returnUrl` query parameter can be used to execute malicious code. For
example, visiting
`http://localhost:9876/?return_url=javascript:alert(document.domain)` will
display an alert.

Setting `singleRun` and `autoWatch` to `false` will not immediately run
anything. Warn the user about this.

It is incompatible with IE.

## [6.3.14](v6.3.13...v6.3.14) (2022-02-05)

### Bug Fixes

* remove string template from client code ([91d5acd](91d5acd))
* warn when `singleRun` and `autoWatch` are `false` ([69cfc76](69cfc76))
* **security:** remove XSS vulnerability in `returnUrl` query param ([839578c](839578c))