OMG, the whole china mainland's data is missing, my Heavy Rain Live Alert won't work :((

I don't know the source which the windy.com use. But I see Rainviewer work properly: https://www.rainviewer.com/weather-radar-map-live.html?loc=38,100,3

NMC also provide radar images properly: https://www.nmc.cn/publish/radar/chinaall.html

@david-polášek Wrong Translation. "Yagi" should called "摩羯/摩羯/摩羯".

Reference:
https://www.typhoon2000.ph/multi/?name=YAGI
https://zh.wikipedia.org/wiki/颱風摩羯_(2024年)

When I enable "Live alert", It throw a error: "StormTracker Error: No device token available for notifications."

@Wettergucker said in Unable to enable "Live alert": No device token available for notifications.:

Bei mir half die Neuinstallation der App. Und das mit Standort Deutschland. Vorher die selbe Fehlermeldung.

After reinstall the app, I can received the storm alert now (Although I don't see any storm on the radar). My device is Oneplus 8T, OS is Android 14. @Jari-Sochorová

@tomacat said in Unable to enable "Live alert": No device token available for notifications.:

Live Alert mostly push notifications when my mobile network changes. For example, when my mobile Wi-Fi switches to data traffic, it suddenly reminds me of a storm or precipitation, and the notification is too late.

happened again, the alert notification only push when WiFi network change.:(

Click the "Change my picture" and "Change password" button will refresh the whole page instead of redirect to community.windy.com. It works before but not today, so I suspect it is the bug of new version.

Target: index.html
Version: 23.0.0
Built: 2020-01-13, 10:18
Your browser: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0
WebGL particles: running

I see visibility parameter from station API. But I didn't see the information about visibility. If is available for update API? And what's its unit, kilometers or miles?

He means windy doesn't show the color of coastline. I capture the screenshot of FY-4A satellite: http://rsapp.nsmc.org.cn/geofy/

Fix now.

The new progress bar UI is terrible. I hope to bring back the old progress bar. The new progress bar shows the day of the week on one half and not on the other half. The information density is very low, but it takes up a lot of space. And the large gray area looks very abrupt.

@Suty I think the issue is that the tropical cyclone's position stopped updating after landfall, whereas the model forecasts continued to update.

I noticed that the last update for Tropical Storm Dolphin was a day ago (runtime 20260809 12 UTC)[1], whereas the ECMWF is still updating (runtime 20260810 00 UTC)[2].

[1]:

https://www.windy.com/-Hurricane-tracker/hurricanes/dolphin

[2]:

https://charts.ecmwf.int/products/cyclone?base_time=202608100000&product=tc_strike_probability&unique_id=15W_DOLPHIN_2026 (runtime 20260810 00 UTC)

@Suty

I had my OpenClaw agent look into this issue, and here are his conclusions:

---

Windy.com Search Dimming Background Bug — Analysis

I've been investigating a layout bug on windy.com where the search-dimming-background element appears disproportionately large on the Chinese (zh) version of the site compared to the English (en) version. Here's what I found.

Key Finding

Comparing the rendered HTML of the two versions, the root cause is the CSS custom property --search-input-width set on the `` element:

English version:

Chinese version:

That's a 94px difference (382 vs 476). This variable is almost certainly used to set the width of the search container and/or the search-dimming-background, which is why it visually "bulges out" noticeably.

Why This Happens

--search-input-width is not hardcoded in CSS — it's dynamically computed by Windy's Svelte/JavaScript and injected as an inline style on the `` element. The JS is likely doing something like viewportWidth - rightPane - margins to calculate available space for the search area. Under certain conditions, this computation yields a wider value on the Chinese locale.

Reproducibility: Firefox-Specific and Intermittent

• Firefox only — Chromium-based browsers never reproduce the issue
• Chinese system locale only — English locale is fine
• Intermittent — Reproducible on my laptop (Firefox, Chinese locale) and on a UOS (统信) machine with Firefox, but NOT reproducible on an Ubuntu machine with Firefox (Chinese locale, via Alibaba Wuying Cloud)

This pattern points to three likely factors:

1. System CJK font differences — On Chinese-locale systems, Firefox falls back to system-installed CJK fonts (e.g., Noto Sans CJK, WenQuanYi, Source Han Sans) for rendering. Different Linux distros ship different CJK fonts with different character metrics (glyph width, line height, etc.), which affects DOM measurement APIs. The Ubuntu cloud instance likely has a different font set than my laptop and the UOS machine.

2. DOM measurement inconsistency in Gecko — The JS code computing --search-input-width likely relies on APIs like offsetWidth or getBoundingClientRect. Firefox's Gecko engine handles subpixel layout and CJK text measurement differently from Chromium's Blink. Chinese UI text in the right-hand pane (menu labels, tooltips, etc.) may measure wider on certain font configurations, feeding a larger value into the width calculation.

3. Race condition with font loading — If the initial width calculation runs before web fonts or system fonts are fully resolved, the measurement could be off. The intermittent nature suggests a timing/loading dependency — network speed, cache state, and font loading order could all influence whether the bug triggers.

Verification

In Firefox DevTools Console on the Chinese version:

// Check the current computed search-input-width
getComputedStyle(document.documentElement).getPropertyValue('--search-input-width')

// Check actual rendered width
document.querySelector('#search-dimming-background')?.getBoundingClientRect().width

Comparing these values between English and Chinese locales should consistently show the discrepancy on affected systems.

Conclusion

It's not the font-size: 18px directly causing the issue. The bug is in Windy's JavaScript width calculation logic — it computes a wider --search-input-width under Firefox + certain Chinese system font configurations. This appears to be a Gecko-specific layout measurement issue interacting with the app's dynamic width calculation, triggered by the zh locale.

Would appreciate the dev team taking a look at how --search-input-width is computed in the Svelte search component, particularly around font-dependent measurements in Gecko browsers.

@Suty I recorded a video; the issue remains unresolved, and I suspect it is related to the font-size: 18px; CSS property. (Edited: I might be wrong, too.)

I noticed that the link for the "Saffir-Simpson Hurricane Wind Scale (SSHWS)" in the Simplified Chinese(简体) version is broken; it points to https://www.windy.com/%22https://www.nhc.noaa.gov/aboutsshws.php/%22, whereas a quick check shows that the English, German, and Spanish versions do not have this issue.

Left: March 25, 2026
Right: May 17, 2026

The translation is incorrect again. @suty

@Suty said in Startup weather box have a grey padding:

@tomacat Hello, may I ask which browser and OS do you use on your device?

OS: GNU/Linux Debian Trixie
Browser: Firefox 140.8.0esr

---

OS: Linux UOS
Browser: Firefox 146.0

OS: Linux UOS
Browser: Chromium (Can't reproduce)

OS: Linux Ubuntu
Browser: Firefox 149.0 (Can't reproduce)

There is a large grey padding on the startup box. The problem may related to UI language (Chinese). but I had reproduce on the another machine every time.

(I didn't found the upload picture button on here. I will try it on the reply.)