The `WebViewId` name is a lot more descriptive these days to the casual
reader, so I think we can go ahead and finish the rename.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
This is another step in the move to having a per-WebView renderer. In
this step event handling is made per-WebView. Most events sent to Servo
are sent via the WebView API already, so this just moves more event
handling code to the per-WebView render portion of the compositor.
- ServoRenderer is given shared ownership and interior mutability as
it is now shared among all WebView(Renderers).
- Some messages coming from other parts of Servo must now carry a
WebViewId as well so that they can be associated with a particular
WebView.
- There needs to be some reorganization of `ServoRenderer` in order to
avoid issues with double borrow of `RefCells`.
Signed-off-by: Delan Azabani <dazabani@igalia.com>
Co-authored-by: Martin Robinson <mrobinson@igalia.com>
This is one of the first big steps toward making the compositor work
per-WebView. It moves the collection of pipelines into the per-WebView
data structure in the compositor as well as the pending paint metrics.
This means that more messages need to carry information about the
WebView they apply to. Note that there are still a few places that we
need to map from `PipelineId` to `WebViewId`, so this also includes a
shared mapping which tracks this. The mapping can be removed once event
handling is fully per-WebView.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
Co-authored-by: Delan Azabani <dazabani@igalia.com>
This is the first step toward moving the WebDriver implementation to
servoshell. This move will make it possible to start testing the
embedding API with WebDriver. See [this zulip thread][a] for more details.
While WebDriver will be able to use a lot of API commands to do what it
is doing now, there will still need to be some "cheat codes" for more
gnarly access to `ScriptThread` details. That's why we likely won't be
able to remove all WebDriver-specific messages from the API -- but maybe
they will be useful for embedders somehow.
A couple messages have to change as they depended on `script_traits`
types, particularly those that used `WindowSizeData` and `LoadData`. I
think this helps to encapsulate the WebDriver commands a bit more
though.
[a]: https://servo.zulipchat.com/#narrow/channel/437943-embedding/topic/webdriver.20as.20embedding.20api.20playgound
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
This change exposes a single `InputEvent` type and now there is only a
single delegate method for this `WebViewDelegate::notify_input_event`.
- Clipboard events are now handled as `EditingAction` inpute events. In
the future this can include things like "Select All", etc.
In addition, many parts of the dance to pass these events can now be
simplified due to this abstraction.
- All forwarded events are handled the same way in the `Constellation`,
though they may carry an optional hit test (for events that have a
`point`) which affects which `Pipeline` they are sent to.
- In the `ScriptThread` we now accept these `InputEvents` and use them
everywhere. Now all "compositor events" are "input events".
- This allows removing several data structures which are no longer
necessary.
- We no longer inform the embedder when an event was handled by a
WebView as that was only important for a MDI feature that will
no longer be so important the full-featured `WebView` API.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
Co-authored-by: Mukilan Thiyagarajan <mukilan@igalia.com>
Many types used directly in the `libservo` API are in the
`script_traits` crate, which was created to break circular dependencies.
Move all API exposed types to `embedder_traits` which now contains types
exposed via the `libservo` embedding API. Also expose these at the root
of the `libservo` `servo` crate so that the API won't break when they
move around in the future.
The idea with `embedder_traits` in the future is that it contains types
that are available throughout servo because they are used in the
embedding API and thus should have minimal dependencies on other Servo
crates (a bit like `base`).
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
