Inconsistency in colors from `useThemeParams` and CSS variables

[thecoorum]

Platform

Select one of the following:

• [ ] Telegram for Android
• [x] Telegram for iOS
• [ ] Telegram for macOS
• [ ] Telegram Desktop
• [ ] Telegram Web A
• [ ] Telegram Web K

Describe the bug

A clear and concise description of what the bug is.

To Reproduce

Steps to reproduce the behavior:

1. Configure SDKProvider with initOptions to be { cssVars: true } to have access to variables
2. Create a div with background set to either --tg-bg-color or to backgroundColor received from useThemeParams hook
3. Open the Mini App in iOS app and macOS/WebK and see different colors for the same theme (iOS background color differs from the header color)

Expected behavior

Color of the div should be the same as the header color

Media iOS

macOS

WebK

[thecoorum]

Also, from the screen you might notice that the WebK doesn't render the Main Button, despite that the same screen was captured. Probably need to open a separate issue for that one (the Main Button was also unresponsive on iOS for some reason)

[heyqbnk]

I am not sure this problem is related to the packages themselves. None of the packages responsible for what Telegram application sends to the Mini App. You could see these differences not only due to incorrect packages behavior, but also differences between Telegram platforms.

So we should only call it a bug in case the result is incorrect according to what was expected in the specific platform. So, if Telegram for iOS application sent us bg_color #000000 and Telegram for Android sent #010101, this is not a bug, it is just a different behavior.

Is this the case?

[thecoorum]

Yeah, makes sense. Closing this one

[wishyoudie]

Reopening because this seems like SDK bug after all. Here are three screenshots of the 'same' app. I've opened ThemeParams page to demonstrate how secondary_bg_color is different across them.

Screenshot 1 (tma-dl) is @telegram-apps/sdk opened via Direct Link (more precisely, the new Open App button in bot's profile, but the behaviour remains consistent with Direct Links).

Screenshot 2 (tma-mb) is @telegram-apps/sdk opened via Menu Button.

Screenshot 3 (tg-dl) and Screenshot 4 (tg-mb) are using Telegram's sdk (bootstrapped with create-mini-app).

As you can see from these images, three out of four combinations have secondary_bg_color set to #1c1c1d, meanwhile in Direct Link + ta/sdk it is #000000, which is not correct.

I only encountered this issue with Telegram for iOS. Desktop and macOS versions seem to not have this bug, can't say anything about Android though.

[wishyoudie]

I was able to fix this issue by manually requesting themeParams. For React.js template you can add another effect to App component:

import { postEvent } from "@telegram-apps/sdk-react";

// ...

useEffect(() => {
    postEvent("web_app_request_theme");
  }, []);

Since logging is disabled during SDK initialization even with debug={true} prop, I wasn't able to track whether or not SDK calls this event implicitly, contrary to tsdk which has completely opposite behaviour in this regard (not quite good either way). The same React app works perfectly on iOS when scaffolded with tsdk and gives the following console output on start:

[Telegram.WebView] > postEvent web_app_set_header_color {color_key: 'bg_color'} [Telegram.WebView] > postEvent web_app_set_background_color {color: '#ffffff'} [Telegram.WebView] > postEvent web_app_request_theme [Telegram.WebView] > postEvent web_app_request_viewport [Telegram.WebView] < receiveEvent theme_changed {theme_params: {…}} [Telegram.WebView] > postEvent web_app_setup_main_button {is_visible: false}

My guess would be that either SDK does not handle request_theme response correctly or that the following funny lines in telegram-web-apps.js kick in (L383 - L387):

// temp iOS fix
        if (theme_params.bg_color == '#1c1c1d' &&
            theme_params.bg_color == theme_params.secondary_bg_color) {
            theme_params.secondary_bg_color = '#2c2c2e';
        }

[heyqbnk]

Closing due to the problem is not on the SDK side, unfortunately. You can use the solution, provided by Vladimir above