4.7 KiB
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
(you can optionally pass "webkit" for a webkit checkout)
This will create a firefox checkout at $HOME/firefox
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 $HOME/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
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.
The script will assume Firefox checkout is located at $HOME/firefox
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
Cheatsheet
See browser stdout/stderr
Set the DEBUG=pw:browser environment variable to see it.
Firefox
Debug build
When compiling set the FF_DEBUG_BUILD=1 environment variable.
Stack trace
In //mozglue/misc/StackWalk.cpp add
#define MOZ_DEMANGLE_SYMBOLS 1
In native code use
#include "mozilla/StackWalk.h"
// ...
MozWalkTheStack(stderr);
If the stack trace is still mangled cat it to tools/rb/fix_linux_stack.py
Logging
Upstream documentation: https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Gecko_Logging
MOZ_LOG=nsHttp:5
Module name is a string passed to the mozilla::LazyLogModule of the corresponding component, e.g.:
LazyLogModule gHttpLog("nsHttp");
Inside Juggler, you can use dump('foo\n').
WebKit
Logging
Inside Objective-C you can use NSLog.
NSLog(@"Foobar value: %@", value);
Debugging windows
In Source\WTF\wtf\win\DbgHelperWin.cpp replace
#if !defined(NDEBUG) with #if 1
Then regular WTFReportBacktrace() works.
Debugging linux
WTFReportBacktrace() has been broken since r283707, see this comment. Revert that change locally to make backtraces work again. Otherwise addr2line -f can still be used to map addresses to function names.
Enable core dumps on Linux
mkdir -p /tmp/coredumps
sudo bash -c 'echo "/tmp/coredumps/core-pid_%p.dump" > /proc/sys/kernel/core_pattern'
ulimit -c unlimited
Then to read stack traces run the following command:
# To find out crashing process name
file core-pid_29652.dump
# Point gdb to the local binary of the crashed process and the core file
gdb $HOME/.cache/ms-playwright/webkit-1292/minibrowser-gtk/WebKitWebProcess core-pid_29652
# Inside gdb update .so library search path to the local one
set solib-search-path /home/yurys/.cache/ms-playwright/webkit-1292/minibrowser-gtk
# Finally print backtrace
bt