* implement Touchevent prevent default behavior
* The status change logic of the `TouchHandler` is changed.
> The `WaitingForScript` state is canceled. TouchAction can be identified
based on the current touch type and numbers if touch points.
* Sends current event to script thread along with recognized `TouchAction`.
> After dispatch event, script thread sends a `TouchEventProcess(EventResult)`
message to main thread. If the event is set to `DefaultAllowed`, the
corresponding `TouchAction` information is added.
* After receiving `DefaultAllowed(TouchAction)` message, main thread executes corresponding action.
> `DefaultPrevented(TouchEventType)` is received. Use `prevent_click` to mark
that the default `Click` is blocked, and `prevent_move` to mark that the
default `Scroll` and `Zoom` are blocked. In this way, all TouchActions
implement preventDefault.
Signed-off-by: Bi Fuguo <1782765876@qq.com>
* fix some suggestions
* support preventDefault fling
* move `TouchAction` to share touch directory
* check preventDefault everytime when touch
* fix zoom ineffective
Signed-off-by: Bi Fuguo <1782765876@qq.com>
* fix some suggestions
rename on_event_processed to on_touch_event_processed
clear unused features
Signed-off-by: Bi Fuguo <1782765876@qq.com>
* Optimizes pan performance by continuously sliding without waiting for the eventhandler.
Signed-off-by: kongbai1996 <1782765876@qq.com>
* resolve conflict
Signed-off-by: kongbai1996 <1782765876@qq.com>
---------
Signed-off-by: Bi Fuguo <1782765876@qq.com>
Signed-off-by: kongbai1996 <1782765876@qq.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>
This allows reusing the asynchrnous fetch mechanism that we use for page
resources and is likely a step toward removing the `FetchThread`.
Benefits:
- Reduces IPC traffic during navigation. Now instead of bouncing
between the constellation and the `ScriptThread` responses are sent
directly to the `ScriptThread`.
- Allows cancelling loads after redirects, which was not possible
before.
There is the question of what to do when a redirect is cross-origin
(#23037). This currently isn't handled properly as the `Constellation`
sends data to the same `Pipeline` that initiated the load. This change
doesn't fix this issue, but does make it more possible for the
`ScriptThread` to shut down the pipeline and ask the `Constellation` to
replace it with a new one.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
Manage `<iframe>` size updates in `Window`. In addition to removing
duplicated code, this will allow setting `<iframe>` sizes synchronously
on child `Pipeline`s of the same origin in the script process in a
followup change. The goal is remove flakiness from `<iframe>` sizing.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
Instead of exposing many different kinds of messages to the compositor
that are routed through the constellation, expose a single message type
which can be sent across IPC channels. In addition, this IPC channel and
the route to the crossbeam channel with the compositor is created along
with the `CompositorProxy`, simplifying what needs to be passed around
during pipeline initialization.
Previously, some image updates (from video) were sent over IPC with a
special serialization routine and some were sent via crossbeam channels
(canvas). Now all updates go over the IPC channel `IpcSharedMemory` is
used to avoid serialization penalties. This should improve performance
and reduce copies for video, but add a memory copy overhead for canvas.
This will improve in the future when canvas renders directly into a
texture.
All-in-all this is a simplification which opens the path toward having a
standard compositor API and reduces the number of duplicate messages and
proxying that had to happen in libservo.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
Instead of exposing many different kinds of messages to the compositor
that are routed through the constellation, expose a single message type
which can be sent across IPC channels. In addition, this IPC channel and
the route to the crossbeam channel with the compositor is created along
with the `CompositorProxy`, simplifying what needs to be passed around
during pipeline initialization.
Previously, some image updates (from video) were sent over IPC with a
special serialization routine and some were sent via crossbeam channels
(canvas). Now all updates go over the IPC channel `IpcSharedMemory` is
used to avoid serialization penalties. This should improve performance
and reduce copies for video, but add a memory copy overhead for canvas.
This will improve in the future when canvas renders directly into a
texture.
All-in-all this is a simplification which opens the path toward having a
standard compositor API and reduces the number of duplicate messages and
proxying that had to happen in libservo.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
For a long time, `gfx_traits` has held a lot of things unrelated to graphics
and also unrelated to the `gfx` crate (which is mostly about fonts).
This is a cleanup which does a few things:
1. Move non `gfx` crate things out of `gfx_traits`. This is important in
order to prevent dependency cycles with a different integration between
layout, script, and fonts.
2. Rename the `msg` crate to `base`. It didn't really contain anything
to do with messages and instead mostly holds ids, which are used
across many different crates in Servo. This new crate will hold the
*rare* data types that are widely used.
Details:
- All BackgroundHangMonitor-related things from base to a new
`background_hang_monitor_api` crate.
- Moved `TraversalDirection` to `script_traits`
- Moved `Epoch`-related things from `gfx_traits` to `base`.
- Moved `PrintTree` to base. This should be widely useful in Servo.
- Moved `WebrenderApi` from `base` to `webrender_traits` and renamed it
to `WebRenderFontApi`.
* script: Do not run layout in a thread
Instead of spawning a thread for layout that almost always runs
synchronously with script, simply run layout in the script thread.
This is a resurrection of #28708, taking just the bits that remove the
layout thread. It's a complex change and thus is just a first step
toward cleaning up the interface between script and layout. Messages are
still passed from script to layout via a `process()` method and script
proxies some messages to layout from other threads as well.
Big changes:
1. Layout is created in the script thread on Document load, thus every
live document is guaranteed to have a layout. This isn't completely
hidden in the interface, but we can safely `unwrap()` on a Document's
layout.
2. Layout configuration is abstracted away into a LayoutConfig struct
and the LayoutFactory is a struct passed around by the Constellation.
This is to avoid having to monomorphize the entire script thread
for each layout.
3. Instead of having the Constellation block on the layout thread to
figure out the current epoch and whether there are pending web fonts
loading, updates are sent synchronously to the Constellation when
rendering to a screenshot. This practically only used by the WPT.
A couple tests start to fail, which is probably inevitable since removing
the layout thread has introduced timing changes in "exit after load" and
screenshot behavior.
Co-authored-by: Josh Matthews <josh@joshmatthews.net>
* Update test expectations
* Fix some issues found during review
* Clarify some comments
* Address review comments
---------
Co-authored-by: Josh Matthews <josh@joshmatthews.net>
This is the start of the organization of types that are in their own
crates in order to break dependency cycles between other crates. The
idea here is that putting these packages into their own directory is the
first step toward cleaning them up. They have grown organically and it
is difficult to explain to new folks where to put new shared types. Many
of these crates contain more than traits or don't contain traits at all.
Notably, `script_traits` isn't touched because it is vendored from
Gecko. Eventually this will move to `third_party`.
2023-11-03 15:38:18 +00:00
Renamed from components/script_traits/script_msg.rs (Browse further)
