day-piece-webview

Embed web content in a Day app. The piece uses native browser components or the host browser's iframe. One Rust API provides navigation, shared browser profiles, private browsing, JavaScript evaluation, bundled websites, and application-provided resources.

Install

[dependencies]
day-piece-webview = "0.4"

day build selects the backend feature and stages native code and browser assets automatically. You do not need a feature entry for each toolkit in the app's dependency declaration. This checkout requires Rust 1.89+ and Day 0.5. Keep the CLI, framework, and piece compatible; use the same Day Git source throughout the dependency graph. See Cargo.toml.

The pending Servo and generated-host changes require the matching Day CLI/framework changes; an older CLI with the same 0.5 compatibility label is not sufficient. Land Day first, then validate this checkout against that Git revision and distribute a CLI containing the changes before migrating downstream applications. See the rollout requirements.

Experimental Servo

The separate day-piece-webview-servo package adds an experimental renderer on macOS (AppKit, GTK, Qt), Linux (GTK, Qt), Windows (XAML, WinUI), and Android; the OpenHarmony host is paused. Its servo Cargo feature is disabled by default. Native-only consumers do not resolve Servo dependencies; applications that opt into the adapter do. A Servo-enabled app can show Servo and toolkit-native WebView pages at the same time. The demo enables it with day launch -t macos-appkit --flavor servo, offers a default-renderer preference, and has a per-tab renderer toggle. See setup, requirements, and current limits.

The demo's servo Cargo feature is disabled by default. Build with --flavor servo to include both renderers, or omit the flavor for a native-only app. See build commands and size comparisons. CI exercises both engines on macOS AppKit and publishes matched captures side-by-side in the website gallery. Native walkthroughs continue across all primary targets. See comparison coverage and publication.

Choose a content source

For a bundled site at resource/assets/site/index.html:

use day::prelude::*;
use day_piece_webview::web_view_inline;

// `res` is generated by day::resources!() in the application.
fn help_page() -> impl Piece {
    web_view_inline(res::assets::site).id("help-webview")
}

The view fills the available space. HTML can reference its own stylesheets, scripts, images, and other pages with ordinary relative URLs. Use generated resource constants to open bundled content; paths inside a web document remain document-relative.

A resource provider receives each requested path and returns its MIME type and binary body. The engine resolves relative references; the app need not rewrite every link, extract an archive, run a local HTTP server, or send the whole document collection through JavaScript. The provider is synchronous and buffers each requested resource. On web-dom, its callback runs on the app's browser thread.

Guides

• Profiles and privacy: shared logins, custom storage roots, private browsing, and data deletion.
• Integration: layout, navigation controls, bundled sites, link handling, transparency, and retained sessions.
• Resource providers: reports, on-demand archive loading, bundled shells, response rules, ownership, and deployment.
• JavaScript: reading page state, passing structured data and localized text, readiness, and error handling.
• Platforms: renderers, resource channels, installation, and limitations.
• Testing and CI: assertions, target coverage, known gaps, and the latest audit.

Renderers

The component links below lead to upstream API documentation. Notes describe the current Day adapter as well as engine requirements; support for an engine feature does not imply that the piece exposes it on every host.

Integration notes

• Apple: the OS manages profile storage locations; a requested directory changes the profile identity but does not relocate its files. On macOS GTK, the adapter forwards wheel and trackpad events to WKWebView and synchronizes the Cocoa child's position with GTK layout.
• Qt WebEngine: custom resource replies cannot reproduce arbitrary HTTP status codes. Response headers and Fetch API support for the provider scheme require Qt 6.6+. See resource loading and the upstream request-job API.
• WebKitGTK AppImage: the launcher defaults WEBKIT_DISABLE_SANDBOX_THIS_IS_DANGEROUS=1 to work around bundled helpers lacking an AppArmor profile on Ubuntu. This reduces browser-process isolation; it does not apply to Flatpak or distro builds. See packaging.
• WebView2: the SDK/loader and installed browser Runtime are separate dependencies. Engine startup and newer profile/resource APIs can fail on a missing or incompatible Runtime. WinUI's control, the XAML composition host, and Wry's child HWND are different integrations.
• ArkWeb: a successful HAP build or JavaScript result does not prove that the web surface paints. Emulator engine installation and GPU setup need separate verification; see Harmony diagnostics.
• Browser iframe: resource providers require service workers, HTTPS or localhost, and a live owning app tab. The frame has no sandbox attribute by default, so same-origin content is not isolated from the app. See browser deployment.

support(), inline_support(), and eval_support() describe the compiled backend, not runtime engine availability or page readiness. In particular, Qt can report support even when its build uses the URL-label fallback. Check the separate profile capabilities before exposing private browsing or data-clearing controls. The test coverage guide distinguishes implementation support from platforms exercised in CI; macOS GTK/Qt and Windows GTK/Qt are not part of the demo matrix.

Run the demo

cd demo
day launch -t macos-appkit --script dayscript/webview.yaml

Choose another target with -t, for example ios-uikit, android-material, or web-dom. The demo browser has an editable URL bar, Back/Forward, Reload/Stop, Home, an external-browser button, and private browsing settings. The Code button opens a testing drawer with a JavaScript console, support information and a resource-provider demo. Native history availability, titles and loading state come from JsHandle::navigation_state(); url_binding attaches an address signal to inline and provider views. Iframe hosts cannot inspect cross-origin navigation, so unavailable history and Stop controls remain disabled.

Demo website · Browser app · Platform screenshots

CI builds and runs the demo on eight primary platform/toolkit pairs. These are execution tests, not just compile checks. The CI audit records a Linux GTK resource-loading failure in the first provider run; the other primary targets passed. Configured coverage should not be mistaken for an entirely passing matrix.

For local framework development, run day patch --local ../day from this repository, or day patch --local ../../day from demo/. The demo depends on this piece by path. Run cargo test and node --test tests/*.mjs at the repository root for host-side tests.