As discussed offline, our testing scenarios assume running trusted
web content - so this warning is just a noise for this usecases.
When it comes to dealing with untrusted web content though, automation
authors need to make sure to not launch browsers under root in the first
place.
This is a large rework of selectors:
- Each BrowserContext now has a separate Selectors instance that has its own registrations.
Most of them share a single sharedSelectors instance, but contexts created for a connected
browser have their own instance.
- Connected browser now gets a RemoteBrowser object that encapsulates Selectors and Browser.
This Selectors object is registered with the api selectors.
- Public selectors.register api iterates over all registered Selectors channels
and registers in each of them.
- createSelector testing method migrated to ElementHandle._createSelectorForTest.
As discussed offline other big images like Node.js or Nginx use root as the default user and the users in the end can base-off from our image to add their security features.
Not sure if follow up docs changes are required for that.
Fix#3703Fix#3681
It turns out that the new `docker push --all-tags` is not yet available
in the latest docker distribution on Ubuntu 20.04.
This provides a helper script to tag and publish the docker image.
Sometimes I see "cannot call emit on the undefined" error on the bots.
This change adds some more logging, so we could potentially identify where
the issue comes from.
We rely on `docker push --all-tags` flag that exists only in the
new version of docker.
The PR to docker with the flag: https://github.com/docker/cli/pull/2220
It turns out Github Actions have docker pre-installed.
This patch unifies the codepaths that we use to build docker image
locally and to publish it from CI.
As a result, there's no extra `--prepare-context` argument in
`//docs/docker/build.sh` that was used solely on CI.
References #2926
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?
Today we have a bunch of types used by the d.ts file that are not exported. We don't want to export them because it would greatly increase our semver API surface area, so this patch inlines them. Now users will not see names of types they can't import.
