Startup weather box have a grey padding

[tomacat]

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

[tomacat]

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.

[Suty]

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

[tomacat]

@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)

[Suty]

@tomacat Hello, we are investigating this issue. Thank you for reporting.

[tomacat]

@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.)

[tomacat]

@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]

@tomacat Thank you for sharing all these details, now we know that this CSS issue is related only to Chinese localization under Firefox.

We can start to look for a solution, but for now it has a low priority to be completely honest.