This PR **removes** `ScriptToConstellationMessage::ForwardToEmbedder`,
and replaces it with an explicit `ScriptToEmbedderChannel`. This new
channel is based on `GenericCallback` and in single-process mode will
directly send the message the to the embedder and wake it. In
multi-process mode, the message is routed via the ROUTER, since waking
is only possible from the same process currently. This means in
multi-process mode there are likely no direct perf benefits, since we
still need to hop the message over the ROUTER (instead of over the
constellation).
In single-process mode we can directly send the message to the embedder,
which should provide a noticable latency improvement in all cases where
script is blocked waiting on the embedder to reply.
This does not change the way the embedder receives messages - the
receiving end is unchanged.
## How was sending messages to the embedder working before?
1. Script wraps it's message to the embedder in
`ScriptToConstellationMessage::ForwardToEmbedder` and sends it to
constellation.
2. The [constellation event loop] receives the message in
[handle_request]
3. If deserialization fails, [an error is logged and the message is
ignored]
4. Since our message came from script, it is handle in
[handle_request_from_script]
5. The message is logged with trace log level
6. If the pipeline is closed, [a warning is logged and the message
ignored]
7. The wrapped `EmbedderMsg` [is forwarded to the embedder]. Sending the
message also invokes `wake()` on the embedder eventloop waker.
[constellation event loop]:
2e1b2e7260/components/constellation/constellation.rs (L755)
[handle request]:
2e1b2e7260/components/constellation/constellation.rs (L1182)
[an error is logged and the message is ignored]:
2e1b2e7260/components/constellation/constellation.rs (L1252)
[handle_request_from_script]:
https://github.com/servo/servo/blob/main/components/constellation/constellation.rs#L1590
[a warning is logged and the message ignored]:
2e1b2e7260/components/constellation/constellation.rs (L1599)
[is forwarded to the embedder]:
2e1b2e7260/components/constellation/constellation.rs (L1701)
Testing: Communication between Script and Embedder is extensive, so this
should be covered by existing tests.
Signed-off-by: Jonathan Schwender <schwenderjonathan@gmail.com>
These changes allow using MallocSizeOf/`#[conditional_malloc_size_of]`
on WebIDL callback values, and then fix a grab bag of places in the
script crate that previously ignored those values. There are also some
commits removing ignored fields that involved Arc/Rc that are not WebIDL
callbacks, since they are now easier to support with the
`#[conditional_malloc_size_of]` attribute.
Testing: Manual testing on about:memory for servo.org.
---------
Signed-off-by: Josh Matthews <josh@joshmatthews.net>
This is the last big change necessary to create the
`constellation_traits` crate. This moves the data structure for messages
that originate from the `ScriptThread` and are sent to the
`Contellation` to `constellation_traits`, effectively splitting
`script_traits` in half. Before, `script_traits` was responsible for
exposing the API of both the `ScriptThread` and the `Constellation` to
the rest of Servo.
- Data structures that are used by `ScriptToConstellationMsg` are moved
to `constellation_traits`. The dependency graph looks a bit like this:
`script_layout_interface` depends on `script_traits` depends on
`constellation_traits` depends on `embedder_traits`.
- Data structures that are used in the embedding layer
(`UntrustedNodeAddress`, `CompositorHitTestResult`, `TouchEventResult`
and `AnimationState`) are moved to embedder_traits, to avoid a
dependency cycle between `webrender_traits` and
`constellation_traits`.
- Types dealing with MessagePorts and serialization are moved to
`constellation_traits::message_port`.
Testing: This is covered by existing tests as it just moves types
around.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
Messages that are sent to the `Constellation` have pretty ambiguous
names.
This change does two renames:
- `ConstellationMsg` → `EmbedderToConstellationMessage`
- `ScriptMsg` → `ScriptToConstellationMessage`
This naming reflects that the `Constellation` stands in between the
embedding layer and the script layer and can receive messages from both.
Soon both of these message types will live in `constellation_traits`,
reflecting the idea that the `_traits` variant for a crate is
responsible for exposing the API for that crate.
Testing: No new tests are necessary here as this just renames two enums.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
Add a `ClipboardDelegate` to the `WebView` API and a default
implementation in libservo for this delegate that works on Mac, Windows,
and Linux. Support for Android will be added in the future. This means
that embedders do not need to do anything special to get clipboard
support, but can choose to override it or implement it for other
platforms.
In addition, this adds support for handling fetches of clipboard contents
and renames things to reflect that eventually other types of clipboard
content will be supported. Part of this is removing the string
argument from the `ClipboardEventType::Paste` enum because script will
need to get other types of content from the clipboard than just a
string. It now talks to the embedder to get this information directly.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
`EmbedderMsg` was previously paired with an implicit
`Option<WebViewId>`, even though almost all variants were either always
`Some` or always `None`, depending on whether there was a `WebView
involved.
This patch adds the `WebViewId` to as many `EmbedderMsg` variants as
possible, so we can call their associated `WebView` delegate methods
without needing to check and unwrap the `Option`. In many cases, this
required more changes to plumb through the `WebViewId`.
Notably, all `Request`s now explicitly need a `WebView` or not, in order
to ensure that it is passed when appropriate.
Signed-off-by: Delan Azabani <dazabani@igalia.com>
Co-authored-by: Martin Robinson <mrobinson@igalia.com>
It's a pointless abstraction that propagates the obsolete chan terminology,
swaps the order in which the sender and receiver are returned, and hides a
source of panics.
