b2d9af5e15
browser(firefox): properly initialize debugging pipe on windows Firefox on Windows has 2 launch modes: - default: a special "launcher process" is used to start browser as a sub-process - non-default: browser process starts right away Firefox has a logic to detect how successful was the use of the launcher process to do self-recovery when things go wrong. Namely: - when attempting to use launcher process, firefox records a timestamp of the attempt beginning - once the launcher process successfully launches browser sub-process, firefox records another timestamp of the completion On a new launch, firefox checks what timestamps are present. If there's a timestamp that signifies start of launcher process, but no successful timestamp, it decides that last "launcher process" use was not successful and falls back to launching browser right away. When launching 2 firefox processes right away, the first process uses attempts to use launcher process and records the first timestamp. At the same time, the second instance sees the first timestamp and doesn't see the second timestamp, and falls back to launching browser right away. Our debugging pipe code, however, does not support non-launcher-process code path. This patch adds support for remote debugging pipe in case of non-launcher-process startup. Drive-by: - disable crashreporter altogether - remove stray dcheck that breaks firefox debug compilation - disable compilation of firefox update agent - do not use WIN32_DISTRIB flag unless doing full builds since it kills incremental compilation References #4660 |
||
|---|---|---|
| .. | ||
| buildbots | ||
| chromium | ||
| ffmpeg | ||
| firefox | ||
| tools | ||
| webkit | ||
| winldd | ||
| checkout_build_archive_upload.sh | ||
| export.sh | ||
| prepare_checkout.sh | ||
| README.md | ||
| sanitize_and_compress_log.js | ||
| upload.sh | ||
Contributing Browser Patches
Firefox and WebKit have additional patches atop to expose necessary capabilities.
Ideally, all these changes should be upstreamed. For the time being, it is possible to setup a browser checkout and develop from there.
1. Setting up local browser checkout
From the playwright repo, run the following command:
$ ./browser_patches/prepare_checkout.sh firefox <path to checkout>
(you can optionally pass "webkit" for a webkit checkout)
If you don't have a checkout, don't pass a path and one will be created for you in ./browser_patches/firefox/checkout
NOTE: this command downloads GBs of data.
This command will:
- create a
browser_upstreamremote in the checkout - create a
playwright-buildbranch and apply all playwright-required patches to it.
2. Developing a new change
You want to create a new branch off the playwright-build branch.
Assuming that you're under ./browser_patches/firefox/checkout:
$ git checkout -b my-new-feature playwright-build
$ # develop my feature on the my-new-feature branch ....
3. Exporting your change to playwright repo
Once you're happy with the work you did in the browser-land, you want to export it to the playwright repo.
Assuming that you're in the root of the playwright repo and that your browser checkout has your feature branch checked out:
$ ./browser_patches/export.sh firefox <path to checkout>
This script will:
- create a new patch and put it to the
./browser_patches/firefox/patches/ - update the
./browser_patches/firefox/UPSTREAM_CONFIG.shif necessary - bump the
./browser_patches/firefox/BUILD_NUMBERnumber.
If you omit the path to your checkout, the script will assume one is located at ./browser_patches/firefox/checkout
Send a PR to the Playwright repo to be reviewed.
4. Rolling Playwright to the new browser build
Once the patch has been committed, the build bots will kick in, compile and upload a new browser version to all the platforms. Then you can roll the browser:
$ node utils/roll_browser.js chromium 123456