browser(firefox): ensure detachedFromTarget is always sent
LinkedBrowser can throw when removing listeners in PageTarget.dispose,
and that prevents BrowserHandler from sending Browser.detachedFromTarget.
Using a try-catch seems good enough.
Currently, browser.version() returns `83.0`, whereas launching firefox
with `--version` flag returns `83.0b3`. This patch alings protocol's
`Browser.version()` with flag output.
Somehow, we get WebProgress state changes when worker is loaded
with a blob url. This messes up frame navigation detection.
Luckily, it's easy to filter out non-document state changes.
As Joel noticed recently, MessageManager in firefox doesn't guarantee
message delivery if the opposite end hasn't been initialized yet. In
this case, message will be silently dropped on the ground.
To fix this, we establish a handshake in SimpleChannel to make sure that
both ends are initialized, end buffer outgoing messages until this
happens.
Drive-by: serialize dialog events to only deliver *after* the
`Page.ready` protocol event. Otherwise, we deliver dialog events to the
unreported page.
We try to avoid closing firefox too early, fearing that this
might terminate clean shutdown sequence.
Usually we assume that `Browser.enable` is called before `Browser.close`
- however, this is not the case in certain tests. So we have to
ensure browser initialization in `Browser.close` as well.
In my local tests, this fixes the Firefox Pipe problem: it looks like
we were closing browser too quickly.
It looks like terminating browser when search service or addon manager is
not fully initialized results in a broken shutdown sequence. As of
today, this results in multiple errors in the browser STDERR. In future,
this might also result in browser stalling instead of terminating.
This starts awaiting search and addon manager termination.
References #3995
Using WebProgressListener events works in all cases. Currently
used `pageshow` event will stop being emitted in future when loading
was stopped with `window.stop()` api.
References #3995
This patch:
- moves `SimpleChannel` to synchronously dispatch buffered commands
instead of a `await Promise.resolve()` hack
- moves dialog & screencast handling from `PageHandler` to
`TargetManager`. This leaves `PageHandler` to be concerned solely about
protocol.
- removes `attach` and `detach` methods for worker channels: since
channels are buffering messages until the namespace registers, there's
no chance to loose any events.
- slightly simplifies `PageNetwork` class: it's lifetime is now
identical to the lifetime of the associated `PageTarget`, so a lot can
be simplified later on.
References #3995
In the current tip-of-tree Firefox, document channel is enabled by
default, so we have to enable it in order to roll further.
This patch:
1. Removes content disposition sniffing from content process since it
crashes renderer with document channel.
2. Merges all page-related handlers in a single `PageHandler` and
serializes network events wrt the `Page.frameAttached` event.
The serialization mentioned in (2) is necessary: frame attachment is
reported from the content process, and network events are reported from
the browsers process. This is an inherent race, that becomes exposed by
the document channel.
On a side note, (2) makes it possible to synchronously report all
buffered events in `SimpleChannel` (cc offline discussion with @dgozman
that highlighted an unsighty approach that we currently employ there: reporting
events in a subsequent microtask.)
References #3995
This patch:
1. Changes `SimpleChannel` to buffer messages to the namespace that
hasn't been registered yet. This allows us to create `SimpleChannel`
per target on the browser side right away.
2. Removes multisession support. Now there's only one `PageAgent` in the
content process, which talks to a single `PageHandler` on the browser
side. Both ends can be created as-soon-as-needed; thanks to
`SimpleChannel` bufferring, no messages will be lost and all messages
will be delivered in proper order. (This is currently the reason why
build 1178 flakes on windows).
3. Straightens up the target reporting. Targets are reported as soon
as they appear on the browser side.
**NOTE:** this doesn't yet remove sessions from protocol.
References #3995
We currently might double-attach to the target in `BrowserHandler` since we iterate over all targets, and then subscribe to the additional event when target is getting initialized.
This patch fixes this race condition and should unblock the roll to r1177.
References #3995
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
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.
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.
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?
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`
`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
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
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.
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.
Review URL: 88261ea669
Key points:
- `Runtime` is now shared between protocol sessions
- `RuntimeAgent` does not exist any more and is merged into `PageAgent` for Page
- `RuntimeAgent` is re-implemented in a worker
This strictly defines Firefox build folder as `obj-build-playwright`.
Currently, Firefox build folder encodes current Mac OS version including
patch versions, and thus we might end up with multiple different build
folders.
Type TypeError that happens while loading document is reported in
the message manager but does not have the error event.
Saw this while reproducing #1307
Review URL: 4753d0121f
This patch:
- Moves Workers to FrameTree
- Introduces WorkerData in PageAgent that proxies runtime agent
in worker to browser process
- Introduces WorkerHandler in PageHandler that handles communicates
with runtime agent in worker and handles Juggler protocol
As part of this patch, SimpleChannel no longer manages lifetime of
any of its handlers.
Review URL: 6364381adc
Refactor inter-process communication inside Firefox. The goal is
to have a single abstraction that works nicely for all our cross-process
communication needs (browser <-> content, content <-> workers, content
<-> file:// process, e.t.c.)
This is step 1 that eliminates content sessions everywhere.
Step 2 will move workers onto `SimpleChannel` as well.
This is a pre-requisite for #720: with a single `browser <-> content`
communication channel it will be easier to await permission change in tabs.
References #720
