`TuiSheetDialogService` theme-color behavior — intended? #14124

loxy · 2026-05-16T23:19:43Z

loxy
May 16, 2026

Hi! Before opening an issue I wanted to check whether the following is working as designed.

Versions: @taiga-ui/addon-mobile@5.6.0, @taiga-ui/core@5.6.0.

When a sheet opens, TuiSheetDialogService writes theme-color = '#404040' via TuiThemeColorService and reverts on close to a value captured once in the service constructor. The setter also writes --tui-theme-color as an inline style on <html>, which beats any :root declaration the app has set for that variable.

In an app that manages <meta name="theme-color"> itself (e.g. for dark mode) and themes --tui-theme-color at :root for the nav header/aside, this leads to:

The iOS URL bar tints to #404040 on sheet open regardless of the sheet's actual background.
The nav chrome briefly flashes #404040 because the inline <html> style beats :root.
The "revert on close" can go back to a stale value if the app's theme-color changed after the service was constructed.

A couple of specific questions:

Is the hardcoded #404040 intentional, or would deriving it from --tui-background-elevation-1 (the sheet's actual bg) be in scope for a change?
Is the inline write to --tui-theme-color intentional — is something inside Taiga relying on the inline-style specificity, or could it move to a less invasive mechanism?
Capturing this.initial at constructor time vs. at each add() — is there a reason for the constructor-time capture?

For now we've worked around it by DI-swapping TuiThemeColorService for a no-op so neither the meta tag nor --tui-theme-color is touched — our own app-level dark-mode effect manages the meta correctly.

Happy to file an issue with a reproducer + draft a PR if any of this is considered a bug. Just wanted to ask first in case it's intentional and I'm missing context.

Thanks!

Answered by waterplea

May 17, 2026

There's a bug for status bar changing color:
#13690

The #404040 is derived from regular gray background overlay behind sheet dialog, not from sheet's background, so that the status bar on iOS above does not stick white like a sore thumb. The issues you highlight are legit and should be addressed/made configurable.

View full answer

waterplea · 2026-05-17T07:36:14Z

waterplea
May 17, 2026
Maintainer

There's a bug for status bar changing color:
#13690

The #404040 is derived from regular gray background overlay behind sheet dialog, not from sheet's background, so that the status bar on iOS above does not stick white like a sore thumb. The issues you highlight are legit and should be addressed/made configurable.

5 replies

loxy May 17, 2026
Author

Thanks for the clarification — the #404040 = backdrop-overlay (not sheet) framing makes much more architectural sense and explains why a fixed value was chosen in the first place.

A few clarifications + offers:

Is #13690 the same as what we raised? From the title it sounds like it covers the revert-on-close bug specifically (this.initial captured at constructor time becoming stale). That's one of the three things we noticed; the other two — the hardcoded value being non-configurable, and the setter writing --tui-theme-color as an inline <html> style — feel separate. Is the plan to handle them all in #13690, or would you prefer separate issues for the other two?

Why we noop given the backdrop-match intent. We chose the no-op despite agreeing with the design intent. Reasons:

The revert bug (🐞 - Status bar coloring during NotificationMiddle opening #13690) leaves the URL bar stuck at #404040 after close, which is the most visible symptom.
The inline --tui-theme-color write hijacks our nav-chrome variable for one frame, causing a flicker.
The hardcoded #404040 doesn't match our backdrop color anyway (we customize it). So even if the revert worked, the URL bar wouldn't match our backdrop.

Once any one of those is configurable / fixed upstream, we'd happily revisit the workaround.

Direction for a PR — what would you want from us?
We're glad to take a swing at the fix, but we'd want a steer first because the three items have different shapes:

Revert bug (🐞 - Status bar coloring during NotificationMiddle opening #13690) — smallest. Re-read this.initial at the start of add() instead of in the constructor. ~3 lines, no API surface change. Easy PR if you're open to it.
Make the color configurable — medium. A new TUI_SHEET_THEME_COLOR injection token, or a field on TUI_SHEET_DIALOG_OPTIONS (themeColor: string | null where null means "don't touch the meta tag"). Bigger API decision — would value your direction before writing.
Split the dual-write — separating <meta name="theme-color"> from --tui-theme-color. Cleanest as separate properties on TuiThemeColorService, but it's a breaking change.

Are these one effort or three? Happy to start with (1) standalone if the others need more discussion, or bundle them if there's a coherent direction you have in mind. Just point us at the right approach.

loxy May 17, 2026
Author

Small correction / clarification on something I said above:

I claimed the hardcoded #404040 "doesn't match our backdrop anyway" with a hand-wave. Looking at it more carefully:

The Taiga modal backdrop isn't a flat color, it's backdrop-filter: brightness(.25) on the page behind. So the resulting visual color depends on what's underneath:

Light mode (page bg ≈ L 95%) → brightness(.25) ≈ L 24% → close to #404040 (≈ L 26%). The match works.
Dark mode (page bg ≈ L 20%) → brightness(.25) ≈ L 5% → much darker than #404040. The URL bar reads as a lighter grey sitting above a near-black backdrop.

So the design intent holds in light mode but breaks for any app with dark mode — which is a fairly common case. That's an extra argument for either (a) deriving the value from the actual computed backdrop or (b) making it configurable via the options token. Doesn't change my offer to help with a PR; just wanted to share the dark-mode failure mode in case it's useful when scoping the fix.

waterplea May 17, 2026
Maintainer

You can add your comments (ideally with videos of reproduction so it's clear what the issue is) to that issue and we can rename it to more general problems with address bar color.

The problem inside that issue is also that this is triggered when a totally different modal, not sheet dialog is open, so there's some faulty logic in code in that regard.

Regarding your questions:

If we have nested sheet dialogs we might get locked out of initial color if the first one closes first – then when the second one closes it reverts the theme color the #404040
That's what I was thinking of, sounds good.
Yes, that's a proper way to handle this inside SheetDialog, because since it was introduced the theme color is now used in navigation background color and we do not want to to change when SheetDialog is open.

I think it makes sense to bundle all those into one PR.

loxy May 17, 2026
Author

Two quick things before I dive in:

Just to be sure — are you inviting a PR from us, or were you confirming the approach for your own roadmap? Happy to take a swing at it if you'd accept it; equally happy to stay on the sidelines if you'd rather have the team own the design.
Version scope — 🐞 - Status bar coloring during NotificationMiddle opening #13690 looks like it's filed against v4.75. We've been looking at v5.6 code (addon-mobile@5.6.0). Should the fix target v5.x, both lines, or are you treating the v4 issue as the canonical tracking item and the v5 code paths just inherit the same problems?

If both answers are "yes, please PR against v5.x," I'll come back with the API-direction questions (configurable color shape, splitting the writes, nested-sheet revert logic). Don't want to invent decisions if you'd rather do it yourselves.

In any case, I will update #13690 with our concerns...

waterplea May 17, 2026
Maintainer

We're happy to accept PRs, there's a lot of work for us to do :) Let's focus on v5, as for v4 – we can try to backport it later.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Taiga UI family

`TuiSheetDialogService` theme-color behavior — intended? #14124

Uh oh!

{{title}}

Uh oh!

Replies: 1 comment 5 replies

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

Taiga UI family

TuiSheetDialogService theme-color behavior — intended? #14124

Uh oh!

loxy May 16, 2026

Replies: 1 comment · 5 replies

Uh oh!

waterplea May 17, 2026 Maintainer

Uh oh!

loxy May 17, 2026 Author

Uh oh!

loxy May 17, 2026 Author

Uh oh!

waterplea May 17, 2026 Maintainer

Uh oh!

loxy May 17, 2026 Author

Uh oh!

waterplea May 17, 2026 Maintainer

`TuiSheetDialogService` theme-color behavior — intended? #14124

loxy
May 16, 2026

Replies: 1 comment 5 replies

waterplea
May 17, 2026
Maintainer

loxy May 17, 2026
Author

loxy May 17, 2026
Author

waterplea May 17, 2026
Maintainer

loxy May 17, 2026
Author

waterplea May 17, 2026
Maintainer