Implement embedded browser support on HarmonyOS and fix webview issues - #189
Merged
Conversation
The OHOS branches of browser_webview_create/eval/navigate/reload/set_bounds were stubs returning Err, and Webview.getByLabel returns null on OHOS, so the built-in BrowserScene could not load any URL. Implement the full embedded path using the ArkUI Web component. - Vendor @ohos-rs/ability@0.4.0-beta.0 into src/apps/ohos/oh-rs-ability/ and switch oh-package.json5 to a file: dependency. Extend WebBuilder with width/height support and onPageBegin/onPageFinish callbacks; expose the private RustWebviewNodeController via AppStorage from DefaultXComponent.aboutToAppear; add removeWebview for clean teardown. - Add BrowserWebviewService.ets singleton owning a Map<label, entry> and implementing create/eval/navigate/reload/setBounds/show/hide/close/ setFocus. Page-load callbacks forward to the web-ui via the new #[napi] emit_browser_page_load (mirrors notify_system_color_mode). - Rewrite the #[cfg(target_env = ohos)] branches of the five existing browser_webview_* commands in browser_api.rs to call ArkTS functions via JS_THREADSAFE_FUNCTION (same pattern as ohos_speech_call). Add four new OHOS-only commands (browser_webview_show/hide/close/set_focus) and register them in lib.rs generate_handler. - Frontend useEmbeddedBrowserWebview.ts falls back to a command-based BrowserWebviewHandle when Webview.getByLabel returns null, so the existing close/hide/show/setFocus handle pattern works on OHOS without changing the desktop path. - Flip SHOW_BROWSER_ENTRY to true in PersistentFooterActions.tsx so the Globe entry button appears in the nav footer. Verified: arkts_check passes on all 4 modified .ets files; hvigor build_project entry@default BUILD SUCCESSFUL; tsc --noEmit 0 errors. Rust cargo check could not run locally (no MSVC linker / OHOS toolchain) but follows existing ohos_speech_call / open_browser patterns exactly. # Conflicts: # src/apps/ohos/entry/src/main/ets/entryability/EntryAbility.ets # Conflicts: # src/crates/assembly/core/src/util/register_arkts_function.rs
Reintroduce BasicsEnvVarsSection (Key/Value table with .env import) dropped during the BasicsConfig refactor. Reads/writes terminal.env_vars; backend, types, i18n (en-US/zh-CN/zh-TW) and scss were already present. Placed after BasicsTerminalSection.
…ed handle
The previous commit's fallback (try getByLabel, fall back to command-based
handle on null) still imported @tauri-apps/api/webview and called
Webview.getByLabel(), which invokes plugin:webview|get_all_webviews. On
OHOS that call throws ("Webview API not available on mobile") because
ArkUI Web components created by RustWebviewNodeController.addWebview are
invisible to Tauri's webview registry. Even on desktop the import is
unnecessary now that all handle ops route through Tauri commands.
- useEmbeddedBrowserWebview.ts: remove import('@tauri-apps/api/webview')
and Webview.getByLabel() from both createBrowserWebview and createWebview.
The handle is ALWAYS command-based (createCommandBasedBrowserWebviewHandle).
Stale-handle cleanup in the retry loop now calls
invoke('browser_webview_close') instead of Webview.getByLabel().close().
- browser_api.rs: add desktop implementations of
browser_webview_show/hide/close/set_focus (previously OHOS-only stubs
returning Err). Desktop uses find_browser_webview(app, label) then
.show()/.hide()/.close()/.set_focus() — same Tauri child-webview API the
old Webview.getByLabel handle used internally. OHOS branches unchanged.
Verified: tsc --noEmit 0 errors; arkts_check passes; hvigor build SUCCESSFUL.
…ronment
The browser hook checked `'__TAURI__' in window` (Tauri's global API
namespace, only set when app.withGlobalTauri is true AND the webview was
created via Tauri's WebviewWindowBuilder). On OHOS the ArkUI Web component
is created by @ohos-rs/ability's RustWebviewNodeController, not Tauri's
builder, so __TAURI__ may be absent even though __TAURI_INTERNALS__ (and
thus `invoke`) is available. This caused isTauri to be false on OHOS,
making loadUrl return early ("nothing happens" when entering a URL) and
BrowserScene to render an <iframe> (which OHOS Web doesn't support for
external URLs).
Fix: check __TAURI_INTERNALS__.invoke (what `invoke` actually needs)
instead, mirroring the pattern in src/infrastructure/runtime/environment.ts
isTauriRuntime.
Note: the Rust .so (libbitfun_desktop_lib.so) still needs to be rebuilt
with the browser_api.rs OHOS branch changes for the browser to actually
load pages. This fix only ensures the frontend takes the native webview
path instead of the iframe path, and surfaces the Rust error instead of
silently doing nothing.
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Summary
Fixes #
Type and Areas
Type:
Areas:
Motivation / Impact
Verification
Reviewer Notes
Checklist