libservo: Add an initial WebView data structure to the API #35119
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
🔨 Triggering try run (#12904764334) for Linux (Unit Tests, Build libservo, WPT, Bencher), MacOS (Unit Tests, Build libservo), Windows (Unit Tests, Build libservo), Android, OpenHarmony, Lint |
Bencher Report
|
Test results for linux-wpt-layout-2020 from try job (#12904764334): Flaky unexpected result (17)
Stable unexpected results that are known to be intermittent (19)
Stable unexpected results (1)
|
|
|
wusyong
reviewed
Jan 22, 2025
delan
force-pushed
the
libservo-webview
branch
from
7e3b05d to
0c4913a
Compare
delan
force-pushed
the
minimal-winit-example
branch
from
a0c215f to
c09c207
Compare
delan
force-pushed
the
libservo-webview
branch
3 times, most recently
from
359b229 to
21ee4b7
Compare
5 tasks
|
How do your vision delegate trait will work with WebView type? I initially thought it's just going to be a trait WebView {
type sender;
} |
delan
force-pushed
the
minimal-winit-example
branch
from
2604569 to
4c4493d
Compare
delan
force-pushed
the
libservo-webview
branch
3 times, most recently
from
349beb9 to
ed5a0c3
Compare
It would work a bit like this: struct MyWebViewDelegate {
gui: GuiWhatever,
}
impl WebViewDelegate for MyWebViewDelegate {
fn set_title(title: &str) {
gui.set_title(title);
}
}let webview = servo.create_webview("http://servo.org/".into());
webview.set_delegate(MyWebViewDelegate::new(gui.clone())); |
delan
force-pushed
the
minimal-winit-example
branch
from
fb266f6 to
f31cf1f
Compare
delan
force-pushed
the
libservo-webview
branch
2 times, most recently
from
34f4edd to
d116dd5
Compare
delan
force-pushed
the
minimal-winit-example
branch
from
f31cf1f to
7613992
Compare
delan
force-pushed
the
libservo-webview
branch
2 times, most recently
from
b155626 to
6c06509
Compare
delan
force-pushed
the
ungeneric-servo-and-compositor
branch
from
1d2b36b to
914fc3c
Compare
delan
force-pushed
the
libservo-webview
branch
from
6c06509 to
97d3398
Compare
Should we review until it's merged to another branch? I've some thought on webview's method, but I suppose it's still not finalized yet. |
We’re still experimenting with the API, so we’ll mark it as ready for review once we’re more confident. |
delan
force-pushed
the
libservo-webview
branch
2 times, most recently
from
42bd93d to
8421070
Compare
mrobinson
force-pushed
the
libservo-webview
branch
from
8421070 to
2b54cfd
Compare
mrobinson
changed the title
mrobinson
requested review from
atbrakhi,
mrobinson,
jschwe and
gterzian
as code owners
|
@wusyong I'm curious what your thoughts are on the new API. I think we are ready to merge this as the first step. |
mrobinson
approved these changes
Jan 24, 2025
wusyong
requested changes
Jan 24, 2025
wusyong
reviewed
Jan 24, 2025
This patch introduces a new handle-based webview API to libservo, with two main design goals: 1. The lifetime of the handles controls the lifetime of the webview, giving the embedder full control over exactly when webviews are created and destroyed. This is consistent with how WebKitGTK’s WebView works; the engine can only create webviews via a create request, and can only destroy them via a close request. 2. All methods are infallible; if the constellation dies, the embedder finds out when calling Servo::handle_events. For the moment, the embedder is only responsible for creating the WebView id, and not the internal TopLevelBrowsingContext data structures. This is so that the ScriptThread is able to get a handle on the new WebView's WindowProxy in the case that it's an auxiliary browsing context. In the future, the embedder should also be responsible for creating the TopLevelBrowsingContext and the ScriptThread should have mechanism to associate the two views so that WebView creation is always executed through the same code path in the embedding layer. For now, it's enough that the embedder can get a handle to the new WebView when it's creation is requested. Once we replace EmbedderMsg with a webview delegate trait, we will pass WebView handles to the embedder, rather than webview ids. We’ll also add detailed docs, once the design settles. Signed-off-by: Delan Azabani <[email protected]> Co-authored-by: Martin Robinson <[email protected]>
mrobinson
force-pushed
the
libservo-webview
branch
from
2b54cfd to
d9552ac
Compare
|
@wusyong Please take another look at this one. While I don't think we can address all your feedback in this change, we hope to address it in followup changes which should come pretty quickly to Servo. |
wusyong
approved these changes
Jan 25, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This patch introduces a new handle-based webview API to libservo, with
two main design goals:
giving the embedder full control over exactly when webviews are
created and destroyed. This is consistent with how WebKitGTK’s
WebView1 works; the engine can only create webviews via a create
request2, and can only destroy them via a close request.
finds out when calling Servo::handle_events.
For the moment, the embedder is only responsible for creating the
WebView id, and not the internal TopLevelBrowsingContext data
structures. This is so that the ScriptThread is able to get a handle on
the new WebView's WindowProxy in the case that it's an auxiliary
browsing context. In the future, the embedder should also be responsible
for creating the TopLevelBrowsingContext and the ScriptThread should
have mechanism to associate the two views so that WebView creation is
always executed through the same code path in the embedding layer. For
now, it's enough that the embedder can get a handle to the new WebView
when it's creation is requested.
Once we replace EmbedderMsg with a webview delegate trait, we will pass
WebView handles to the embedder, rather than webview ids. We’ll also add
detailed docs, once the design settles.
Signed-off-by: Delan Azabani [email protected]
Co-authored-by: Martin Robinson [email protected]
./mach build -ddoes not report any errors./mach test-tidydoes not report any errorsFootnotes
https://webkitgtk.org/reference/webkitgtk/stable/class.WebView.html ↩
(https://webkitgtk.org/reference/webkitgtk/stable/vfunc.WebView.create.html ↩