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>
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>
- Run `cargo fmt` on `webxr` and `webxr-api`
- Fix clippy warnings in the existing `webxr` code
- Integrate the new crates into the workspace
- Expose `webxr` via the libservo API rather than requiring embedders to
depend on it explicitly.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
This removes all uses of `EmbedderEvent` in the desktop servoshell to
use the new `WebView` API -- filling it out when necessary.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
Co-authored-by: Delan Azabani <dazabani@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>
Flatten and simplify Servo's preferences code. In addition, have both
preferences and options passed in as arguments to `Servo::new()` and
make sure not to use the globally set preferences in `servoshell` (as
much as possible now).
Instead of a complex procedural macro to generate preferences, just
expose a very simple derive macro that adds string based getters and
setters.
- All command-line parsing is moved to servoshell.
- There is no longer the concept of a missing preference.
- Preferences no longer have to be part of the resources bundle because
they now have reasonable default values.
- servoshell specific preferences are no longer part of the preferences
exposed by the Servo API.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
* Create webxr glwindow with Rc window
Signed-off-by: Wu Yu Wei <yuweiwu@pm.me>
* Remove obselte gurad type
Signed-off-by: Wu Yu Wei <yuweiwu@pm.me>
* Update GlWindow trait method
Signed-off-by: Wu Yuwei <yuweiwu@pm.me>
* Update how webxr discorvery is created
Now glwindow will create a hidden window. It's better to not use it
unless we really want to use this port.
Signed-off-by: Wu Yu Wei <yuweiwu@pm.me>
* Link back to upstream webxr repo
Signed-off-by: Wu Yu Wei <yuweiwu@pm.me>
---------
Signed-off-by: Wu Yu Wei <yuweiwu@pm.me>
Signed-off-by: Wu Yuwei <yuweiwu@pm.me>
* respond to winit platform theme changed event and send it to the layout thread
Signed-off-by: Lloyd Massiah <artmis9@protonmail.com>
* refactoring viewport and theme change handling functions based on feedback
Signed-off-by: Lloyd Massiah <artmis9@protonmail.com>
* fixing issues reported by test-tidy
Signed-off-by: Lloyd Massiah <artmis9@protonmail.com>
* update stylo in order to use color_scheme function on Device
Signed-off-by: Lloyd Massiah <artmis9@protonmail.com>
---------
Signed-off-by: Lloyd Massiah <artmis9@protonmail.com>
Co-authored-by: lazypassion <25536767+lazypassion@users.noreply.github.com>
Servo was previously using the inverse of the correct scale factor
which could cause the scrolling speed to be 4x too slow on a machine
with scale factor of 2.0
Signed-off-by: Nico Burns <nico@nicoburns.com>
There is a command-line argument to override the default window size,
but not one for overriding the default screen resolution. This is
important for testing pages that use screen size to have different
behavior.
In addition to adding the new option this change:
- Renames the `--resolution` command-line argument to `--window-size`
to remove ambiguity with the `--screen-size` argument.
- Passes the screen size as device independent (device pixels scaled by
HiDPI factor) to Servo internals. Not only it make it simpler to pass
the `--window-size` override, it makes more sense. Different screens
can have different HiDPI factors and these can be different from the
scale of the window. This makes the screen HiDPI factor totally
independent of the one that Servo uses for the window.
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>
The current implementation has 3 main issues related to HiDPI:
1. When the window moves from a screen with scale factor of 1.5 to one
with 1 and back to 1.5, the minibrowser toolbar actually ends up
being scaled by a factor of 2.25 instead of 1.5. This is because we
currently use the [set_pixels_per_point] method on egui's Context,
but calling this with a value of `ppp` will modify egui's internal
'zoom factor' to be:
```
zoom_factor = ppp / native_points_per_pixel.
```
where `native_points_per_pixel` is the window system scale factor.
The idea is egui can calculate the final scale factor for translating
its logical points to physical pixels as:
```
points_per_pixel = zoom_factor * native_points_per_pixel
```
where zoom_factor is a factor used for Ctrl+Plus, Ctrl+Minus
behaviour. The problem is when we handle the ScaleFactorChanged winit
event due to window moving between screens, the
`native_points_per_pixel` still has the value of the previous
screen's native scaling factor and not the current screen's factor.
This seems to be the case even if we pass the ScaleFactorChanged
event to egui before we call `set_pixels_per_point`.
2. The egui logic for handing Ctrl+Plus, Ctrl+Minus and Ctrl+0 doesn't
interact well with servoshell's device-pixel-ratio CLI argument which
allows the user to override the HiDPI factor. For example, Ctrl+0
will cause egui to reset the zoom_factor to 1.0 instead of the
override we wanted. Another issue is egui's Ctrl+Plus/Ctrl+Minus
will scale the minibrowser in increments of 0.10 whereas
Servo's own page zoom doesn't (it keeps multiplying by 1.1, so the
actual increments are 0.1, 0.21. 0.33 etc)
3. The inital window size calculation on Linux currently assumes a scale
factor of 1.0. This means the window doesn't have the expected
default logical size of 1024*740 on HiDPI systems. On a screen with
HiDPI factor of 1.5, the logical window size ends up being 682x493.
This change addresses all 3 issues:
For 1, switch to the `set_zoom_factor` method of egui context
to avoid the issue with scaling by incorrect native_points_per_pixel.
To allow for the device-pixel-ratio override to work, we calculate the
actual zoom_factor as `device-pixel-ratio / window's scaling factor`.
For 2, disable egui's handling of Ctrl+Plus, Ctrl+Minus, Ctrl-0
shortcuts. It is unclear whether the current behaviour of scaling
both the toolbar and the web page was intentional, or just an accident.
This behaviour is also different from other browser where page zoom
doesn't scale the GUI, so it doesn't seem like a regression to me.
For 3, use LogicalSize type of winit which lets the physical size
calulation to be handled by winit using the windows's actual HiDPI
factor instead of hardcoded 1.0.
[set_pixels_per_point]: 1603f05818/crates/egui/src/context.rs (L1886)
Signed-off-by: Mukilan Thiyagarajan <mukilan@igalia.com>
This is part of the switch from `winapi` to `windows-sys`. `windows-sys` is
maintained by Microsoft, so is more "official." More and more crates are
switching to it.
* servoshell: Move desktop files
Move files related to winit into a desktop module.
This is a preparation to merge the android and ohos apps into
servoshell.
* servoshell: Format imports
* servoshell: Move panic hook into separate file
* servoshell: Move desktop main
* Consider ohos as not desktop
* servoshell: Adjust dependencies for shared code
* servoshell: Remove native-bluetooth from default features
There currently is no good way to have target specific default features.
* Rename desktop_main.rs to cli.rs
* Remove todo
