Draft: fix(addon-mobile): correct sheet dialog theme-color handling

[loxy]

Three independent failure modes in TuiSheetDialogService / TuiThemeColorService around <meta name="theme-color"> handling:

• Capture the theme color at the moment the first sheet opens instead of once at construction, so a theme change made after the service was created (e.g. an app-level dark-mode effect) is no longer lost on revert, and nested sheets no longer revert onto the sheet color.
• Make the sheet color configurable via themeColor on TUI_SHEET_DIALOG_OPTIONS (defaults to #404040, null opts out) instead of a hardcoded constant that only matched the backdrop in light mode.
• Split TuiThemeColorService: color now writes only the <meta name="theme-color"> tag, while the new navColor setter writes the --tui-theme-color CSS variable used by navigation chrome. Dimming the address bar no longer flickers the nav.

Adds a jest spec (revert / nesting / opt-out matrix), a Cypress test for the real-browser open/close behavior, and a themeColor docs example.

Fixes #13690

[bundlemon]

BundleMon

Unchanged files (2)

Status	Path	Size	Limits
✅	demo/browser/styles-(hash).css	20.65KB	+10%
✅	demo/browser/main-(hash).js	1014B	+10%

Total files change +2B +0.01%

Groups updated (1)

Status	Path	Size	Limits
✅	demo/browser/*.js	3.21MB (+2.1KB +0.06%)	-

Final result: ✅

View report in BundleMon website ➡️

---

Current branch size history | Target branch size history

[github-actions]

Tests completed successfully ✅

Good job 🔥

[gemini-code-assist]

Warning

Gemini encountered an error creating the review. You can try again by commenting /gemini review.

[loxy]

Hi @waterplea — this is the v5 PR bundling the three theme-color fixes you greenlit in discussion #14124. Refs #13690.

Marked draft on purpose: the fixes are done and covered (jest + a Cypress test), but three API-shape calls are yours to make before I finalize:

1. Configurable color — I implemented themeColor on TUI_SHEET_DIALOG_OPTIONS as a provider/global default (null opts out). Do you also want a per-open() / directive override, or is the provider default enough?
2. Split naming & compat — color now writes only <meta name="theme-color">, and a new navColor writes the --tui-theme-color CSS var. OK with that split and a clean v5 break, or would you prefer a back-compat shim on the existing setter?
3. Revert model — I capture the initial color at the first open (0 → 1) rather than in the constructor. Happy to switch to an initial-color stack if you had a different mechanism in mind for the nested case.

One heads-up from on-device testing: the address-bar (theme-color) effect no longer renders on iOS 26 Safari (ignores the meta, derives the toolbar from CSS edge backgrounds) or Chrome dark mode (overrides it). It still works on Chrome light / iOS ≤ X?, so the fixes are valid — but the --tui-theme-color (nav) path is the more durable one now. A CSS-based toolbar approach for iOS 26 might be worth a separate discussion down the line.

[waterplea]

This looks good, thank you very much! I think I only have couple of concerns:

1. Maybe let's not change the TuiThemeColorService and handle metadata directly in TuiSheetDialogService using Meta?
2. We can probably not introduce null and just use empty string as falsy value for opt-out? If you prefer more expressive null we can still use !themeColor in checks since empty string also makes no sense as color
3. What's the purpose of const {themeColor} = this.options;? Seems like an extra line, can we just use this.options.themeColor?

[loxy]

Thank you for the feedback. I'm on vacation currently. Don't know how much time I will have next days. But I will try to address your suggestions and remarks.