Embedded platforms (Android and OHOS) are only expected to have a single window, but there is no reason that more windows cannot be added.

Could you clarify the implications (of "expected") here? For ohos we definitly want / need multiple windows, and I would assume android would have similar use-cases for multiple windows.

Could you clarify the implications (of "expected") here? For ohos we definitly want / need multiple windows, and I would assume android would have similar use-cases for multiple windows.

Ah, interesting. There is no reason that the embedded platforms cannot have more than one window in servoshell. We just did not plan to add interface elements to allow that -- and aren't certain what it means in fullscreen servoshell. From the perspective of Servo itself, creating multiple RenderingContexts (one per window) and running Servo in them should work just fine on any platform.

and aren't certain what it means in fullscreen servoshell

ohos / android don't necessiraly imply full screen. There are many device types, from normal smartphone, over foldables to tablets or even PCs. For the larger device-types (IMHO starting from foldable), having multi-window support makes sense, to support side-by-side viewing of different websites. (Split screen also works on my normal android phone as a top/bottom split, but imho it doesn't make too much sense without a foldable, since half the screen space is quite small)

From the perspective of Servo itself, creating multiple RenderingContexts (one per window) and running Servo in them should work just fine on any platform.

Thanks for clarifying! Another question - I've not been following the previous PRs, but is the servo backend using one webrender instance per rendering-context now, or just a single webrender instance?

Edit: To maybe clarify a bit more on the ohos use-case. As you know we primarily care about the webview use-case (where multi-window is obviously important), but being able to run servoshell with multiple windows would allow us to easily test multi-window functionality in servoshell upstream.

I've not been following the previous PRs, but is the servo backend using one webrender instance per rendering-context now, or just a single webrender instance?

Servo is using one WR instance per rendering-context. Using multiple documents (one per webview) in a single WebRender instance has issues. We've let Mozilla GFX team know about those and they are discussing internally if that is something that they can/want to support and how this fits into WR's roadmap.

ohos / android don't necessiraly imply full screen. There are many device types, from normal smartphone, over foldables to tablets or even PCs. For the larger device-types (IMHO starting from foldable), having multi-window support makes sense, to support side-by-side viewing of different websites. (Split screen also works on my normal android phone as a top/bottom split, but imho it doesn't make too much sense without a foldable, since half the screen space is quite small)

Oh, for sure. We would need a bit more work to add multi-windows support for Android / OHOS servoshell as the interface elements aren't really there. Multi-window support will definitely be available on these platforms, but maybe not in the short-term for servoshell itself.

🔨 Triggering try run (#19708809664) for Linux (WPT), Android, OpenHarmony

Test results for linux-wpt from try job (#19708809664):

Bencher Report

⚠️ WARNING: No Threshold found!

Without a Threshold, no Alerts will ever be generated.

• Memory (Bytes)
• Data (Measure (units))
• score (Measure (units))
• Latency (nanoseconds (ns))

Click here to create a new Threshold
For more information, see the Threshold documentation.
To only post results if a Threshold exists, set the --ci-only-thresholds flag.

🔨 Triggering try run (#19713821795) for OpenHarmony

✨ Try run (#19713821795) succeeded.

FYI, the one failing ohos test is also failing on main (most of the time), so the panic seems to have been fixed.

I've tested this on NixOS+KDE+Wayland and found an issue. When the window is closed, the app seems to "hang" and I get the following backtrace in the console:

✦ ❯ ./mach run -r
NOTE: Entering nix-shell ./shell.nix
mozilla::detail::MutexImpl::~MutexImpl: pthread_mutex_destroy failed: Device or resource busy
Caught signal 11 in thread "main"
   0: servoshell::backtrace::print
   1: servoshell::crash_handler::install::handler
   2: <unknown>
   3: _ZN7mozilla6detail9MutexImplD1Ev
   4: __run_exit_handlers
   5: exit
   6: __libc_start_call_main
   7: __libc_start_main_alias_1
   8: _start

I think this happens when servo instance is shutdown before the JS runtime gets destroyed. I'll try to dig deeper.

I've tested this on NixOS+KDE+Wayland and found an issue. When the window is closed, the app seems to "hang" and I get the following backtrace in the console:

I think I've tracked this down to the order we were letting things go when a window was removed. I've modified the code to schedule a window close instead of doing it immediately. I think this allows things to be released in the right order and I no longer see this issue on my Linux system.

Wanted to confirm that it works currently on ohos. The only thing that doesn't work is the make new tab feature. I think it is fine to disable it for now and fix it later.

Wanted to confirm that it works currently on ohos. The only thing that doesn't work is the make new tab feature. I think it is fine to disable it for now and fix it later.

Do you have any more details on errors that are emitted when using the new tab feature? Maybe we can fix it before landing this?

I suspect that that if the new tab feature is broken by the ordering of WebViews in the collection, that it will be fixed by a followup change. I'll go ahead and land this.