There is a race between "close" event coming from the server and
"close" command issued from the client.
This is similar to calling close after disconnect, so added tests.
We used to animate for 5 seconds, and also timeout after 5 seconds.
Presumably, this made the click work sometimes due to different timeout
schedulers in node vs browser.
As of today, we create `PageTarget` instances whenever we get a
sync IPC from the content process. This, however, breaks an invariant
that `browserContext.pages` always has all pages (and *browsing contexts* - not to be confused with *browser contexts*), associated with browser context. This invariant will be especially important when we move
user agent emulation to browser-side.
This patch makes `PageTarget` lifecycle symmetrical:
- `PageTarget` instance is created when tab is opened
- `PageTarget` is destroyed when tab is crashed or closed
This should also fix a bunch of race conditions with persistent mode, since sometimes we arrive to the window after its
initialization.
Drive-by: straighten viewport management and put a nice descriptive comment.
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
The r1174 starts using cross-process frameIds. This
simplifies Juggler a lot, but regresses a rare usecase:
network requests from workers from subframes are attributed
to main frame.
This adds a test to annotate this regression. Note that this
doesn't also work in Chromium.
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 saves some CPU cycles while waiting for the page to
change the state, e.g. for animations to complete.
Note that retrying logic is only applicable in rare
circumstances like unexpected scroll in the middle of an
action, or some overlay blocking the click. Usually,
action times out in this cases while retrying.
We currently spawn a process per page when recording
video in Chromium. This triggers "too many listeners" on the
process object once you have enough pages open.
A few details on locking registry to prohibit concurrent access:
- locking is done by creating a `__dirlock` directory in the top-level
of our registry.
- since `__dirlock` directory does not match any of browser
directories, old versions of the installer will ignore it
- in case of concurrent access, installation will wait for a lock to be
released for 10 minutes, periodically trying to grab the lock. If it
fails to do so in 10 minutes, the installation will fail.
Fixes#3912
The r1003 build includes png encoder, image2 muxer, webm demuxer
and decoder. These will be used to split webm videos
into frame sequences.
This increases Playwright package size from 6.7MB to 7.1MB
