Fire Mode: Duck.ai and input widget theme overlay

[0nko]

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

Description

Adds Fire mode theme overlays for Duck.ai screens and widgets.

Figma link: https://www.figma.com/design/9S33EK9qIxZdN1FOIFHM5W/%F0%9F%94%A5-Fire-Mode-Tabs--iOS-Android-?node-id=1846-13998&m=dev

Steps to test this PR

• Enable the Fire tabs FF in dev settings
• Make sure Search & Duck.ai option is selected in AI settings
• Make sure the Light mode is set on a test device
• In the Tab switcher, switch to Fire mode
• Go back to the browser
• Verify that the browser is using the light mode but the native input widget is using dark mode colors
• Verify the action buttons are using the Fire mode orange colors
• Switch to dark mode on the device
• Verify the dark mode theme is used everywhere

---

Note

Low Risk
Theming and layout attribute changes across browser and Duck.ai UI with no auth or data logic; regression risk is visual (Fire vs normal themes, light Fire card contrast).

Overview
Introduces daxInputModeCardThemeOverlay so Duck.ai / native input cards can pick up Fire styling independently of the rest of the screen. In light Fire mode, light Fire sets ThemeOverlay.DuckDuckGo.InputModeCard.DarkFire on the card while the activity stays on the light Fire theme—matching the Figma split (light browser chrome, dark input card, orange accents).

Fire accents are centralized on new daxColorFireModeAccent* and daxColorOmnibarAccentContent theme attrs; Fire themes and omnibar overlays now reference those instead of hard-coded mandarin colors. Input cards and send/outline controls switch from blue primary button colors to daxColorOmnibarAccent / daxColorOmnibarAccentContent.

InputScreenActivity applies the Fire theme when BrowserMode.FIRE; bottom-bar InputScreenButtons are inflated with the card’s themed context via new InputModeWidget.cardContext. Omnibar tracker animations and privacy shield rendering force the dark variant in Fire mode; the tab switcher icon uses ?attr/daxIconTabSwitcher.

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

[0nko]

• Fire Mode: Escape hatch #8917
• Fire Mode: Prepare fire dialog #8902
• Fire Mode: Disable chat sync  #8792
• Fire Mode: Separate Duck chat data #8791
• Fire Mode: Empty state pages #8748
• Fire Mode: Launch NTP in different modes #8742
• Fire Mode: Duck.ai and input widget theme overlay #8725 👈 (View in Graphite)
• Fire Mode: Themes and styles #8714
• develop

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

[malmstein]

did not install or smoke-test the APK — static-only. nice follow-up to #8714: pulling the hardcoded mandarin50/40 values into semantic daxColorFireModeAccent* attrs and adding the daxInputModeCardThemeOverlay "dark island" overlay for the Duck.ai and input-widget cards is clean and consistent with the omnibar overlay pattern. the NativeInputOmnibarController switch to resolving daxColorWindow from the card's themed context (instead of the outer ctx) is the right fix to make the overlay actually take. this also addresses the raw-hex-in-the-theming-file nit I raised on #8714.

no blockers. one question worth a reply before merge: the input-mode-switch card's focus stroke stays daxColorAccentBlue under the fire overlay — looks like it'd read blue in fire mode. the tab-button dimension flip and the palette-file split are minor.

since I haven't run it, I'd smoke-test the input widget and Duck.ai card in both light/dark fire mode before approving — especially the stroke colour.

[malmstein]

we moved omnibar_card_fire_light/dark into design-system-colors.xml but the mandarin*_translucent pair landed here in the rebrand file — can we keep them together so the fire palette lives in one place?

[0nko]

the split is following the existing two-file convention rather than being accidental: mandarin40/50_translucent are mandarin-scale colours (the mandarin hue at 20% alpha), so they sit in the Mandarin block next to mandarin40/50 in the rebrand palette file. omnibar_card_fire_light/dark aren't part of any named scale (they're bespoke surface greys), so they live in design-system-colors.xml alongside the other raw one-offs like background_omnibar_shadow. moving either group to join the other would pull it out of its conventional home — but if you'd prefer discoverability over the convention, i can add a <!-- Fire mode --> grouping comment or co-locate them. let me know.

[malmstein]

deleting the :app copy means this browser-ui layout now wins, and it also changes the ImageView from bottomNavIcon (24dp) to toolbarIcon (40dp). scaleType="center" keeps the drawable at its intrinsic size so it's mostly invisible, but is the dimension change intentional or just fallout from dropping the duplicate?

[0nko]

intentional — it's needed for the fire-mode icon rather than fallout from dropping the duplicate. daxIconTabSwitcher resolves to ic_tab_fire_mode_24 in fire mode, which is 24×30dp (taller than the 24×24 ic_tab_24). with scaleType="center" the drawable renders at its intrinsic size, so at bottomNavIcon (24dp) the 30dp-tall fire icon clips ~3dp top and bottom; toolbarIcon (40dp) gives it room. the default and highlighted icons are 24×24, which is why the change looks like a no-op for them. the view is match_parent inside a toolbarIcon-sized button either way, so the tab count doesn't shift.

[malmstein]

the card now gets daxInputModeCardThemeOverlay, but strokeColor is still pinned to daxColorAccentBlue and the DarkFire overlay only remaps daxColorOmnibarAccent, not daxColorAccentBlue — so the outline stays blue in fire mode while the rest of the card goes orange. is that intended, or should the stroke follow the fire accent too?

[0nko]

good catch — fixed. the stroke now uses ?attr/daxColorOmnibarAccent instead of daxColorAccentBlue. in the base themes daxColorOmnibarAccent already resolves to daxColorAccentBlue, so non-fire modes are unchanged, and the InputModeCard.DarkFire overlay remaps daxColorOmnibarAccent to the fire accent — so the outline now follows the card into orange. i applied the same change to the two sibling cards that get the overlay in this PR (fragment_contextual_duck_ai.xml and view_native_input_mode_switch_widget.xml, the latter via its :app host) since they had the identical blue-pinned stroke.

[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 e8ca846. Configure here.}

[malmstein]

The toggle in the Tab Manager doesn’t look right. We discussed this offline and @0nko will fix it in a separate PR

[malmstein]

re-review after the five new commits, approving. built the branch locally and installed on a Pixel 7 — it launches healthy with no crash; the device dropped off adb before I could drive into Fire mode, so I didn't get to eyeball the fire theming on-device (stacked PR, no CI APK, fire surfaces need an internal build with the flag on anyway). both of my substantive comments are addressed: the input-card focus strokes now follow daxColorOmnibarAccent so they go orange in Fire mode, and the fire palette colors moved into their semantically correct files. the new daxColorFireModeAccent* / daxColorOmnibarAccentContent attrs are a clean way to handle the accent and the icon-contrast-in-dark-fire case, and the InputModeCard.DarkFire overlay overriding the content colour back to white is exactly right for the dark-card-in-light-app case.

only leftover is the minor one inlined: the tab-switcher button's 24dp→40dp dimension flip from deleting the :app layout — muted by scaleType="center", just worth confirming it's intentional. nothing blocking.

[malmstein]

still leaving this from last round so it isn't lost: deleting the :app copy of this layout means this browser-ui one wins, and it also changes the ImageView from bottomNavIcon (24dp) to toolbarIcon (40dp). scaleType="center" keeps the drawable at its intrinsic size so it's mostly invisible, but is the dimension change intentional or just fallout from dropping the duplicate?

[0nko]

intentional, not fallout. daxIconTabSwitcher resolves to ic_tab_fire_mode_24 in fire mode, which is 24×30dp — taller than the 24×24 ic_tab_24/ic_tab_24_highlighted. with scaleType="center" the drawable draws at its intrinsic size, so a 24dp (bottomNavIcon) container clips the fire icon ~3dp top and bottom; toolbarIcon (40dp) gives it room. the default/highlighted icons are 24×24, which is why it reads as a no-op for them. (re-posting here since the threaded reply from last round landed on the now-outdated thread.)

[0nko]

The toggle and the animation background color have both been fixed.