Closed thecoorum closed 4 weeks ago
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)
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?
Yeah, makes sense. Closing this one
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.
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';
}
Closing due to the problem is not on the SDK side, unfortunately. You can use the solution, provided by Vladimir above
Platform
Select one of the following:
Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior:
SDKProvider
withinitOptions
to be{ cssVars: true }
to have access to variablesdiv
with background set to either--tg-bg-color
or tobackgroundColor
received fromuseThemeParams
hookExpected behavior
Color of the
div
should be the same as the header colorMedia iOS
macOS
WebK