Fire Mode: WebView profile management

[0nko]

Task/Issue URL: https://app.asana.com/1/137249556945/project/1207418217763355/task/1214780084779090?focus=true

Description

Isolates WebView state between Regular and Fire browser modes via AndroidX webkit's MULTI_PROFILE API. Each newly-created WebView is bound to its mode-specific androidx.webkit.Profile so cookies, LocalStorage, IndexedDB, and other origin-keyed storage are partitioned per mode. No-op on devices without MultiProfile support.

Pieces introduced:

• WebViewModeInitializer (browser-mode-api) — binds a freshly-created WebView to the profile for a given BrowserMode. BrowserTabFragment injects it and calls bind(it, browserMode) inside configureWebView() immediately after inflating the DuckDuckGoWebView, before any settings or clients are applied.
• WebStorageProvider (BrowserModeDataProvider<WebStorage>) — resolves the per-mode WebStorage via ProfileStore, falling back to the shared default WebStorage when MultiProfile is unavailable.
• BrowserMode.profileName extension — stable mapping from mode to profile name (REGULAR → default profile, FIRE → "Fire").
• FireModeAvailability is now synchronous (fun isAvailable()), uses WebViewFeature.MULTI_PROFILE directly instead of WebViewCapabilityChecker, warms its cache on main-process onCreate via MainProcessLifecycleObserver, and freezes the first computed value so later flag flips don't change the answer mid-session.

API proposal: WebViewModeInitializer interface

Steps to test this PR

• Smoke test the app and make sure data-clearing works as before. There should be no change to any user-visible functionality

---

Note

Medium Risk
Changes WebView creation and session storage partitioning at tab open; Fire tabs can be closed if profile binding fails, but Regular mode and devices without MultiProfile should behave as before when binding is skipped or falls back.

Overview
Introduces WebView multi-profile wiring so Regular and Fire tabs use separate AndroidX WebView profiles (cookies, LocalStorage, IndexedDB, etc.), with no binding when MULTI_PROFILE is unsupported.

WebViewModeInitializer binds each new WebView to the profile for the tab’s BrowserMode (via BrowserMode.profileName) before any other WebView setup. BrowserTabFragment calls it right after inflation; if binding fails in a non-Regular mode, it logs, closes the tab, and tears down the WebView.

WebStorageProvider implements BrowserModeDataProvider<WebStorage>, returning profile-scoped storage when Fire/multi-profile is available, otherwise the shared default.

FireModeAvailability is now synchronous, checks WebViewFeature.MULTI_PROFILE directly (replacing WebViewCapabilityChecker), warms availability on main-process onCreate, and freezes the first computed result for the session.

^{Reviewed by Cursor Bugbot for commit 513ec83. Bugbot is set up for automated code reviews on this repo. Configure here.}

[0nko]

• Fire Mode: Toggle switch #8606
• Fire Mode: Tab data isolation #8591
• Fire Mode: WebView profile management #8575 👈 (View in Graphite)
• Fire Mode: Rename fire-mode module to browser-mode #8574
• Fire Mode: Add BrowserMode with plumbing #8478
• develop

This stack of pull requests is managed by Graphite. Learn more about stacking.

[CDRussell]

Smoke tested and it looked ok to me. Reluctant to approve the PR if the public API changes are not covered in a proposal, though. which I didn't think they were (maybe I misremember); are they covered? Because if not, probably will result in changes to these again before merging.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit ae0a70d. Configure here.}