This PR removes the deprecated `puppeteer.devices` in favor of a new
exported object `KnownDevices`. `devices` can also be exported, but has
been deprecated.
This PR separates the installations tests from normal tests and changes
the matrices as follows:
- Installations tests on all platforms and the latest 3 node versions.
- Chrome tests are done on all platforms on the latest node version.
- Firefox tests are done only on linux on the latest node version.
This PR moves the puppeteer source code into separate mono-repo packages:
- `puppeteer` and `puppeteer-core` are now separated into their own
packages.
- `puppeteer-core` has a new exports called `puppeteer-core/internal`
for internal usage.
Tests and various tools have been updated to accommodate the migration.
This PR starts the monorepo migrations as per
https://github.com/puppeteer/puppeteer/issues/8922. To scope migrations,
we are only moving the `testserver` into a separate package. Further
migrations will come later.
This PR adds a basic support for WebDriver BiDi that currently includes only the ability to establish a connection and shutdown the browser. Therefore, the implementation is marked as internal and won't show up in the changelog as it's barely useful at the moment.
The API classes are kept as classes instead of interfaces so that clients relying on instanceof checks still work.
Instead of checking skipped tests in mocha-utils this PR
implements a custom mocha interface for better flexibility
when skipping tests. That should allow skipping tests without
running before and after hooks.
* chore: implement a test runner on top of mocha
This PR implements a test runner on top of mocha
that performs multiple mocha runs as defined in
TestSuites.json and compares the outcome of the runs
against TestExpectations.json. This allows us to
remove most of helpers from mocha-utils and be more
flexible when defining the test configurations.
Two main sources of flakiness addressed:
1) we should dispose the lifecycle watcher after we waited for the navigation response (bad API? we need to refactor but I think it'd be valuable to stabilize tests first without too many changes).
2) we should wait for the navigation request's response if there is a navigation request in the watcher.
Closes#8644
Previously, if timeout is falsy, the targets would only
be checked if a browser-level event fires which lead to
a race: if the events arrived before waiting for a target,
the promise would never resolve.
Fixes#8763
