The cause_type in NetworkEventActor was derived from a hard-coded
pattern match on the request URL file extension.
This patch replaces the hard-coded pattern matching with the Destination
field of Request, to provide a better alignment with the Fetch
specification.
Testing: Updated unit tests.
Fixes: #38151
---------
Signed-off-by: Kingsley Yung <kingsley@kkoyung.dev>
Client messages, which are always requests, are dispatched to Actor
instances one at a time via Actor::handle_message. Each request must be
paired with exactly one reply from the same actor the request was sent
to, where a reply is a message with no type (if a message from the
server has a type, it’s a notification, not a reply).
Failing to reply to a request will almost always permanently break that
actor, because either the client gets stuck waiting for a reply, or the
client receives the reply for a subsequent request as if it was the
reply for the current request. If an actor fails to reply to a request,
we want the dispatcher (ActorRegistry::handle_message) to send an error
of type `unrecognizedPacketType`, to keep the conversation for that
actor in sync. Since replies come in all shapes and sizes, we want to
allow Actor types to send replies without having to return them to the
dispatcher.
This patch adds a wrapper type around a client stream that guarantees
request/reply invariants. It allows the dispatcher to check if a valid
reply was sent, and guarantees that if the actor tries to send a reply,
it’s actually a valid reply (see ClientRequest::is_valid_reply). It does
not currently guarantee anything about messages sent via the TcpStream
released via ClientRequest::try_clone_stream or the return value of
ClientRequest::reply. We also send `unrecognizedPacketType`,
`missingParameter`, `badParameterType`, and `noSuchActor` messages per
the
[protocol](https://firefox-source-docs.mozilla.org/devtools/backend/protocol.html#error-packets)
[docs](https://firefox-source-docs.mozilla.org/devtools/backend/protocol.html#packets).
Testing: automated tests all pass, and manual testing looks ok
Fixes: #37683 and at least six bugs, plus one with a different root
cause, plus three with zero impact
---------
Signed-off-by: atbrakhi <atbrakhi@igalia.com>
Signed-off-by: Delan Azabani <dazabani@igalia.com>
Co-authored-by: delan azabani <dazabani@igalia.com>
Co-authored-by: Simon Wülker <simon.wuelker@arcor.de>
Co-authored-by: the6p4c <me@doggirl.gay>
The will-navigate message tells the devtools client to expect a
navigation for a browsing context. This makes the network monitor clear
any previous entries and show the requests for the new page that is
loaded. In order to support this correctly, we need to send the
navigation notification from the constellation instead of the script
thread, otherwise we silently ignore navigations triggered by the
browser URL bar.
Testing: Ran servo in devtools mode , now the requests appear for new
loaded page
Fixes: https://github.com/servo/servo/issues/37334
---------
Signed-off-by: Uthman Yahaya Baba <uthmanyahayababa@gmail.com>
- Add a `resource_id` field to `EventActor` and `NetworkEventActor`
- Store a `next_resource_id` field in DevtoolsInstance
- Add `resource_id` parameter to `NetworkEventActor::new`
- Increment `next_resource_id` when
`DevtoolsInstance::find_network_event_actor` is called so each network
event has a unique id
Testing: Ran servo in devtools mode and can see the data showing in
`status`,`type`, `transferred` ,`size` and `timeline` columns of each
request, also logged the devtools instance and can see unique
`resourceId` for each request.
Fixes: https://github.com/servo/servo/issues/37661
Signed-off-by: Uthman Yahaya Baba <uthmanyahayababa@gmail.com>
- Remove request/response fields in `NetworkEventActor` which now stores
minimal request metadata needed : `URL`, `method`, `timestamps`, `raw
headers`, `body`.
- Refactor add_request and add_response: `add_request` takes the
incoming DevtoolsHttpRequest and populates
`request_url`, `request_method`, `request_started`,
`request_time_stamp`, `request_body`, `request_headers_raw`
`request_cookies`, `request_headers`,`total_time` and `event_timing`
(via a new helper that computes Timings)
While `add_response` takes the incoming DevtoolsHttpResponse and
populates `response_headers_raw`, `response_body` ,`response_cookies`,
`response_headers`, `response_start`, `response_content`
- Add a call to `resources_updated` to push initial request info in
`handle_network_event`
Testing: Run and logged servo in devtools mode and now, the request
header info isavailable as soon as the request gets initiated
Fixes: https://github.com/servo/servo/issues/37566
---------
Signed-off-by: Uthman Yahaya Baba <uthmanyahayababa@gmail.com>
- Add `ResourceArrayType` with `Available` and `Updated` variants
- Rename `resources-available` and `resource-available` to
`resources-array` ,`resource-array`
- Add `ResourceArrayType` as an argument to decide the type of resources
- Add `Option<ResponseContentMsg>`,`Option<ResponseStartMsg>`,
`Option<ResponseCookiesMsg>`,
`Option<ResponseHeadersMsg>`,`Option<RequestCookiesMsg>`,
`Option<RequestHeadersMsg>`, `total_time`, `security_state` to
`NetworkEventActor` struct , and serialize the data in each to
`resource_updates` , flattening the nested arrays into a single JSON
- Refactor the following methods `request_headers`,`response_start` ,
`response_content`,`response_cookies`,`response_headers`,
`request_cookies`,`total_time` to associated functions passing
`HttpRequest` and `HttpResponse` as parameters .
Testing: Ran servo with devtools flag to see the logs corresponding to
the changes
Fixes: https://github.com/servo/servo/issues/37479
This PR Builds on https://github.com/servo/servo/pull/37517 and was
opened due to merge conflicts and branch issues
---------
Signed-off-by: Uthman Yahaya Baba <uthmanyahayababa@gmail.com>
- Add browsing_context_actor_name parameter to handle_network_event
- Replace NetworkEventMsg in HttpRequest case with
BrowsingContextActor::resource_available
- Update DevTools caller in lib.rs to pass browsing_context_actor_name
Testing:
Fixes:
https://github.com/servo/servo/issues/33556#issuecomment-2756544430
---------
Signed-off-by: Uthman Yahaya Baba <uthmanyahayababa@gmail.com>
* Use 2024 style edition
Signed-off-by: Simon Wülker <simon.wuelker@arcor.de>
* Reformat all code
Signed-off-by: Simon Wülker <simon.wuelker@arcor.de>
---------
Signed-off-by: Simon Wülker <simon.wuelker@arcor.de>
Up until now, Servo was using a very old version of time to get a
cross-process monotonic timestamp (using `time::precise_time_ns()`).
This change replaces the usage of old time with a new serializable
monotonic time called `CrossProcessInstant` and uses it where `u64`
timestamps were stored before. The standard library doesn't provide this
functionality because it isn't something you can do reliably on all
platforms. The idea is that we do our best and then fall back
gracefully.
This is a big change, because Servo was using `u64` timestamps all over
the place some as raw values taken from `time::precise_time_ns()` and
some as relative offsets from the "navigation start," which is a concept
similar to DOM's `timeOrigin` (but not exactly the same). It's very
difficult to fix this situation without fixing it everywhere as the
`Instant` concept is supposed to be opaque. The good thing is that this
change clears up all ambiguity when passing times as a `time::Duration`
is unit agnostic and a `CrossProcessInstant` represents an absolute
moment in time.
The `time` version of `Duration` is used because it can both be negative
and is also serializable.
Good things:
- No need too pass around `time` and `time_precise` any longer.
`CrossProcessInstant` is also precise and monotonic.
- The distinction between a time that is unset or at `0` (at some kind
of timer epoch) is now gone.
There still a lot of work to do to clean up timing, but this is the
first step. In general, I've tried to preserve existing behavior, even
when not spec compliant, as much as possible. I plan to submit followup
PRs fixing some of the issues I've noticed.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
0) Advertise support for the network monitor in the initial protocol communication.
1) Only notify the developer tools server about the final request in an HTTP transaction.
2) Add timing information for connecting to the HTTP server and sending the HTTP request.
3) Reduce duplication between various networkEventUpdate structures by creating a helper function
that merges two JSON structures together. This also corrects the JSON structure so the devtools
client interprets the output correctly.
4) Calculate various header size fields correctly.
5) Remove unnecessary usize->u32 casts by making the appropriate fields usize.
6) Add header values to request and response header messages.
7) Support triggering page reloads via the devtools client.
