This roll:
- NetworkObserver now uses the `remote's` ChannelEventSink layer to
subscribe to redirects.
- Wheel events now must be dispatched from browser process.
- There's a new API for console messages
- The old methods to wait for search service and addon manager no longer
work; speculatively remove them since neither `remote` nor
`marionette` have anything like this.
Native manual merge: 9e6fcfd868
In this case, there's no protocol version that we can extract for
nsIHttpChannel.
The code that does the redirect is here: 7f3d9fce41/docshell/base/nsDocShell.cpp (L6079-L6095)
To trigger this codepath, we'd need to run test inside a special
docker container that has https server running on the 443 port. We lack
infrastructure for this kind of tests (but it'll be cool to have it).
References #11118
When Firefox decides to perform an http->https redirect based on HSTS
information, it issues an "internal" redirect and cancels the http request.
Since there is no response for the http request, we forge 307 redirect
in this case, following Chromium lead.
The relevant code is in nsHttpChannel::StartRedirectChannelToHttps.
- to read post data of requests, we have to read stream
- to restore the stream later on, we have to rewind it back
- however, if the stream is large enough, it cannot be rewound back
This patch starts cloning post data streams if possible to avoid
back-rewinding them later on.
References #4704
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
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?
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.
