Juggler code had a bug where we subscribed to window and tab
events, but did not iterate collections of current windows and tabs.
As a result, we were sometimes failing to set viewport size for the
initial window, and implemented an artificial promise to workaround
the problem.
This patch:
- starts calling `onOpenWindow` and `onOpenTabListener` callbacks
for *all* windows and tabs - current and future, eliminating the
race condition.
This worked too well and we started overriding window sizes that
were set by users with `window.open(url, 'width=300;height=400')` (we
have a test for this). To fix this, we now plumb `CHROME_WITH_SIZE`
flag from appWindow and override viewport iff this flag is not set.
After this patch, we will use the `onTabOpened` event to move user
agent emulation to the browser-side.
References #3995
BrowsingContextIDs are consistent across the processes, so we can use
them to target frames in both browser and content processes. This will
aid browser-side navigation.
As a nice side-effect, we can drop a round-trip to the content process
for every `requestWillBeSent` event since we *almost* always can
attribute all network events to the proper parent frames.
I say "almost", because we in fact **fail** to correctly attribute requests
from workers that are instantiated by subframes. This, however, is
not working in Chromium ATM, so I consider this to be a minor regression
that is worth the simplification.
This patch:
- moves PrintDepsWindows folder to `//browser_patches/winldd`
- adds `build.sh`, `archive.sh`, `clean.sh` and `BUILD_NUMBER` to
power builds on buildbots
- starts building `winldd-win64` on windows buildbot
This patch:
- removes `--enable-gpl` and `--enable-version3` flags. This defaults
builds to LGPL2 license
- includes `--disable-autodetect` to ensure determenism
- includes extra version suffix to link from binary files back to these
build scripts
This patch moves FFMPEG building to buildbots:
- `ffmpeg-mac.zip` is built on Mac 10.14 machine
- `ffmpeg-win32.zip` and `ffmpeg-win64.zip` are cross-compiled on
Ubuntu 20.04 machine
All builds across the platforms share the same config:
- the same versions of `ffmpeg` and `libvpx`
- the same build configuration for both `ffmpeg` and `libvpx`
The config could be found in the `//browser_patches/ffmpeg/CONFIG.sh`.
The builds will be then copied manually and committed to the git
repository.
browser(firefox): fix automatic http->https redirect
Sometimes, Firefox does an automatic http->https redirect without hitting
the network (e.g. for http://wikipedia.org). In this case, the http request
is very strange:
- it does not actually hit the network;
- it is never intercepted;
- we cannot access its response because there was no actual response.
So, we had a bug where:
- redirects inherited the original request's listener;
- that listener was throwing an error.
This lead to the error in the listeners onDataAvailable call chain,
and original listener that renders the response was never called,
resulting in an empty page.
This change:
- ignores the original request that did not hit the network;
- does not inherit the listener;
- adds try/catch around problematic calls.
If there's no platform specified for the chromium build, we should
detect the host platform.
This will make it pleasant to verify Chromium rolls locally.
Assuming there's a `CR` env variable pointing to the local chromium,
rolling would look like this:
- bump a revision in `//browser_patches/chromium/BUILD_NUMBER`
- run `//browser_patches/chromium/build.sh`
- run tests with pulled chromium: `CRPATH=$CR npm run ctest`
This is an alternative approach to #3698 that was setting up a custom
mapping between chromium revisions and our mirrored builds. For example, we were
taking chromium `792639` and re-packaging it to our CDN as Chromium 1000.
One big downside of this opaque mapping was inability to quickly
understand which Chromium is mirrored to CDN.
To solve this, this patch starts treating browser revision as a fractional number,
with and integer part being a chromium revision, and fractional
part being our build number. For example, we can generate builds `792639`, `792639.1`,
`792639.2` etc, all of which will pick Chromium `792639` and re-package it to our CDN.
In the Playwright code itself, there are a handful of places that treat
browser revision as integer, exclusively to compare revision with some particular
revision numbers. This code would still work as-is, but I changed these places
to use `parseFloat` instead of `parseInt` for correctness.
Currently, we mirror Chromium revisions from gbuckets to our cdn and
name them same way as Chromium revision.
However, with the upcoming bundling of FFMPEG, we'd like to revision
Chromium packages separately, since our Chromium package will depend from
a number of factors:
- chromium upstream revision
- ffmpeg version
- extra files to add to the package or remove from the package
We should be able to produce a new Chromium build once any of these changes.
With this patch, to roll Chromium browser:
- update chromium revision number in the
`//browser_patches/chromium/UPSTREAM_CONFIG.sh`
- bump the build number in the `//browser_patches/chromium/BUILD_NUMBER`
Reference #3680
Firefox will sometimes send multiple requests with the same http channel id. When a frame is loaded, the favicon is requested in the parent frame, but with the same channel id. This can cause the document request to report the wrong frame, causing the test 'should capture iframe navigation request' to fail. It fails consistently on my computer.
This patch adds the content policy type into the http channelId to better distinguish requests. Maybe there is something better we can do? It looks like we use channelId has request ids, so there might be more bugs with these favicon requests in playwright?
* This changes the archive.sh script to use the webkit generate-bundle
tool to generate the MiniBrowser bundles instead of using our custom
logic.
* pw_run.sh is simplified because the new bundles include a wrapper
script that sets the needed LD_LIBRARY_PATH environment variables.
pw_run.sh now calls this wrapper script (for GTK or WPE) instead of
calling the MiniBrowser binary directly when running from a bundle.
Co-authored-by: Andrey Lushnikov <aslushnikov@gmail.com>
Otherwise if required version is not installed the build fails with a cryptic message like
`error: toolchain '1.45.0-x86_64-unknown-linux-gnu' does not support components`
Relates #3258
After a chat with @aslushnikov we add this in two iterations. The first one (this PR) is about scheduled runs for testing the latest tip-of-tree version of the browsers daily and the next PR is about opening an automated PRs once its passing (not sure if its worth to add for failing too) or sending Telegram/Slack notifications.
Current status is that Firefox (around 2 hours) and WebKit (around 3-4 hours) works.
Known issues which I fix before we merge:
- ~~Changes in `test/base.fixture.ts` will get extracted in #3453~~
Feel free to review, current blockers are before we can merge:
- ~~#3453~~
- potential git clone optimisation by aslushnikov
`MediaFeatureValuesChanged` is what their devtools code uses to update the styles. I tried using their code directly, but it doesn't play nicely with navigations so I decided to stick with ours.
Firefox buildchain does not fixate `rust` and `cbindgen` versions,
so we want to fixate them on our end.
A table with matching rust version for every firefox version can
be found at [Rust Update Policy for Firefox](https://wiki.mozilla.org/Rust_Update_Policy_for_Firefox).
Additionally, there are checks in `mozbuild` for the minimum
rust version and minimum `cbindgen` version.
This establishes a single naming for all our blobs with browser
builds that we upload to CDN: `<browser-name>-<os-version>`
- `<browser-name>` is either `firefox` or `webkit`.
- `os-version` is the OS that was used to produce the build.
References #2745
Originally there was no way to build both webkit-gtk and webkit-wpe
in the same checkout. As a result, we were:
- building webkit-gtk & uploading it to CDN
- building webkit-wpe & uploading it to CDN
- downloading webkit-gtk & webkit-wpe from CDN and compiling a single
webkit-gtk-wpe folder that we uploaded to CDN
As of today, however, we can build WPE and GTK ports together. This
patch starts using this to drastically simplify build process:
- build webkit-gtk and webkit-wpe
- use `archive.sh` script that compiles a single folder with both ports
- upload archive to the cloud
This should also fix currently failing webkit build that fails to
assemble the `webkit-gtk-wpe` folder (I missed these codepaths while preparing
for Ubuntu-20.04 bot).
References #2745
This patch:
- specializes "linux" scripts into "Ubuntu 18.04" scripts
- renames all future linux blobs on CDN:
* `firefox-linux.zip => firefox-ubuntu-18.04.zip`
* `minibrowser-gtk.zip => minibrowser-gtk-ubuntu-18.04.zip`
* `minibrowser-wpe.zip => minibrowser-wpe-ubuntu-18.04.zip`
* `minibrowser-gtk-wpe.zip => minibrowser-gtk-wpe-ubuntu-18.04.zip`
- updates downloader to deal with the new names
References #2745
This patch changes the build system to use the JHBuild minimal dependency
system introduced in WebKit r264092 <https://trac.webkit.org/r264092>
The build has been tested with Ubuntu-18.04
The binary size of the zip bundles is now: 37M (WPE) and 40M (GTK).
Previously it was 54M and 59M (respectively)
Currently, it might happen that two different patches clash for the
same build number for the browsers. In this case, authors might
not even know that they need to rebaseline.
This patch starts adding a second line to `BUILD_NUMBER` files - the
signature and date of the `BUILD_NUMBER` change. These are guaranteed
to clash, so it should not be possible to land patches without
re-baselining them.
Review URL: 42f86e9d77
Currently, if web page has an open context menu, then it won't close.
This prevents browser from quitting.
In stock safari, this behavior can also be observed in a way that
context menu will stay opened even if related page got closed.
While investigating this behavior on Mac, a crucial observation was
that `[NSMenu popUpContextMenu]` is spawning a nested event loop,
keeping reference to `WebContextMenuProxyMac` instance, which in turn
keeps references on associated `NSView` with `WKWebView`.
To exit the loop, we need to explicitly cancel context menu. For this,
this patch adds a method `hide` on `WebContextMenuProxy` that uses
port-specific code to cancel context menu.
Windows part of this patch is somewhat speculative: I didn't check
it, but given the same symptomps, I applied the same solution.
Fixes#2700
We now commit protocol.ts files during the roll.
New utils/roll_browser.js helps with that.
This makes our installation very shallow:
- build installer;
- download browsers.
When innerWindow is restored from the history state, we do not receive
content-document-global-created notification, but would still like to know
that window is now using a different inner window to reset the state.
This introduces a new notification juggler-dom-window-reused.
At the same time, goBack()/goForward() sometimes do not initiate
navigation synchronously, so our check for pendingNaivgationId() does
not work. Instead, we rely on canGoBack, and assume that client will
not need the navigationId synchronously.
This change introduces NetworkRequest object that encapsulates
internal redirects as they happen in netwerk/ stack.
NetworkRequest now serves as both ResponseBodyListener and NotificationCallbacks.
When httpChannel is intercepted by Service Worker:
- it gets an internal redirect to another channel with the same id;
- once serivce worker responds, the channel gets the data, but
does not get any onResponse notifications.
So, we update our ResponseBodyListener (the nsIRequestObserver implementation)
to the new request and force onResponse from there once data is available or
request finishes.
* Revert "browser(webkit): exclude gstreamer, its plugins and libdrm from webkit distribution (#2476)"
This reverts commit fc2432a23a.
* Update build num
Review URL: 77a29015e3
This uses `initiatorIdentifier` to mark resource request as
originating from event source.
This is alternative to #2396.
References #2189
