maximus/Simpl-Resultat

Fork 0

investigate(balance): date picker HTML5 reste affiche apres selection (Linux WebView) #177

New issue

Closed

opened 2026-05-01 01:28:35 +00:00 by maximus · 1 comment

maximus commented

2026-05-01 01:28:35 +00:00

Owner

Contexte

Parent : #174 (anomalie 3). Le user rapporte :

lorsque j ai voulu changer la date du snapshot, le calendrier servant a choisir la journee restait present. j ai du faire Esc pour qu il disparaisse.

Cause probable

src/pages/SnapshotEditPage.tsx:143-160 utilise <input type="date"> natif HTML5. Le comportement (fermeture sur selection vs reste ouvert) depend de la WebView :

Windows (WebView2 / Edge Chromium) : ferme sur selection
Linux (WebKitGTK) : comportement variable selon version / theme GTK
macOS (WKWebView) : ferme sur selection

Linux est le candidat suspect.

Travail a faire

Reproduire sur les 2 OS cibles (Linux + Windows) du build Tauri
Identifier la version de WebKitGTK / WebView2 utilisee (Tauri runtime)
Decision (a documenter dans cette issue) :
- Si bug WebKitGTK connu et upstream-only -> garder le natif et accepter (Esc ferme, mentionner dans le guide)
- Si workaround simple cote JS (blur() programmatique sur change) suffit -> l appliquer
- Si bug recurrent -> ouvrir une issue de remplacement par un composant React (out of scope ici, sera spec separe)
Logger les conclusions dans la description de cette issue OU creer une issue suiveuse feat(balance): replace native date picker with React component si necessaire

Fichiers concernes

src/pages/SnapshotEditPage.tsx:143-160 - site du <input type="date">
(Eventuellement) src/pages/BalancePage.tsx - selecteur de periode (3M/6M/1A/3A) si construit pareil

Criteres d acceptation

Diagnostic ecrit dans cette issue : OS impactes, version WebView, comportement attendu vs observe
Decision documentee : fix in-place, workaround, ou spec replacement
Si fix in-place : applique + teste sur Linux/Windows

Complexite

Simple (investigation, pas de code en premier abord).

Priorite

P2 - gene UX, contournable via Esc.

## Contexte Parent : #174 (anomalie 3). Le user rapporte : > lorsque j ai voulu changer la date du snapshot, le calendrier servant a choisir la journee restait present. j ai du faire Esc pour qu il disparaisse. ## Cause probable `src/pages/SnapshotEditPage.tsx:143-160` utilise `<input type="date">` natif HTML5. Le comportement (fermeture sur selection vs reste ouvert) depend de la WebView : - Windows (WebView2 / Edge Chromium) : ferme sur selection - Linux (WebKitGTK) : comportement variable selon version / theme GTK - macOS (WKWebView) : ferme sur selection Linux est le candidat suspect. ## Travail a faire - [ ] Reproduire sur les 2 OS cibles (Linux + Windows) du build Tauri - [ ] Identifier la version de WebKitGTK / WebView2 utilisee (Tauri runtime) - [ ] Decision (a documenter dans cette issue) : - Si bug WebKitGTK connu et upstream-only -> garder le natif et accepter (Esc ferme, mentionner dans le guide) - Si workaround simple cote JS (`blur()` programmatique sur `change`) suffit -> l appliquer - Si bug recurrent -> ouvrir une issue de remplacement par un composant React (out of scope ici, sera spec separe) - [ ] Logger les conclusions dans la description de cette issue OU creer une issue suiveuse `feat(balance): replace native date picker with React component` si necessaire ## Fichiers concernes - `src/pages/SnapshotEditPage.tsx:143-160` - site du `<input type="date">` - (Eventuellement) `src/pages/BalancePage.tsx` - selecteur de periode (3M/6M/1A/3A) si construit pareil ## Criteres d acceptation - [ ] Diagnostic ecrit dans cette issue : OS impactes, version WebView, comportement attendu vs observe - [ ] Decision documentee : fix in-place, workaround, ou spec replacement - [ ] Si fix in-place : applique + teste sur Linux/Windows ## Complexite Simple (investigation, pas de code en premier abord). ## Priorite **P2** - gene UX, contournable via Esc.

maximus added this to the overnight-2026-05-01-bilan-anomalies-174 milestone 2026-05-01 01:28:35 +00:00

maximus added the

source:human

status:ready

type:bug

labels 2026-05-01 01:28:36 +00:00

maximus referenced this issue

2026-05-01 01:29:22 +00:00

page bilan - anomalies diverses #174

maximus removed this from the overnight-2026-05-01-bilan-anomalies-174 milestone 2026-05-01 01:43:14 +00:00

maximus referenced this issue from a commit

2026-05-02 19:56:02 +00:00

fix(ui): close native date picker after selection on WebKitGTK (#177)

maximus referenced this issue

2026-05-02 19:56:20 +00:00

fix(ui): apply WebKitGTK date picker workaround to remaining 7 inputs #188

maximus referenced this issue from a pull request that will close it,

2026-05-02 19:57:04 +00:00

fix(ui): close native date picker after selection on WebKitGTK #189

maximus commented

2026-05-02 19:57:39 +00:00

Author

Owner

Diagnostic

Critere	Resultat
OS impacte	Linux (WebKitGTK)
Version (dev box)	Ubuntu 24.04 + `libwebkit2gtk-4.1-0` 2.50.4-0ubuntu0.24.04.1
WebView Tauri Linux	webkit2gtk-4.1 (defaut Tauri v2)
WebView Tauri Windows	WebView2 (Edge Chromium)
Comportement attendu	Popup natif ferme apres selection
Comportement Linux	Popup reste ouvert, Esc requis
Comportement Windows	Ferme correctement (selon doc Edge Chromium, non re-verifie depuis ce dev box)

Cause racine

Sur WebKitGTK le popup natif du <input type="date"> est un widget GTK separe qui ne se ferme pas automatiquement apres commit. Comportement variable selon version GTK / theme. Bug upstream WebKitGTK, pas un bug Tauri.

Decision : workaround in-place applique

Option retenue : blur() programmatique sur change (option 2 du body de l'issue).

1 ligne ajoutee dans onChange : e.currentTarget.blur() apres la logique existante.
No-op sur Edge Chromium (WebView2) et WKWebView ou le popup se ferme deja.
Pas d'API change, pas de regression cross-platform attendue.

PR : #189.

BalancePage

Verifie : BalancePage.tsx n'a pas de <input type="date"> (seulement des boutons de plage 3M/6M/1A/3A). La mention « eventuellement BalancePage » du body est moot.

Suivi : 7 autres date inputs

Le bug WebKitGTK touche tous les <input type="date"> du codebase (8 au total : 1 in scope ici + 7 ailleurs). Pour ne pas etendre cette PR au-dela du scope explicite de l'issue, le meme workaround est tracke pour les 7 autres dans #188.

Smoke test Windows

Pas effectue (impossible depuis le dev box Linux). Mitigation :

blur() est une primitive DOM standard, comportement identique cross-WebView.
WebView2 ferme deja le popup avant que blur() soit interprete : appel sans effet observable.
Le release.yml CI build le NSIS Windows ; toute regression surfacerait au prochain release.

## Diagnostic | Critere | Resultat | |---|---| | OS impacte | **Linux** (WebKitGTK) | | Version (dev box) | Ubuntu 24.04 + `libwebkit2gtk-4.1-0` 2.50.4-0ubuntu0.24.04.1 | | WebView Tauri Linux | webkit2gtk-4.1 (defaut Tauri v2) | | WebView Tauri Windows | WebView2 (Edge Chromium) | | Comportement attendu | Popup natif ferme apres selection | | Comportement Linux | Popup reste ouvert, Esc requis | | Comportement Windows | Ferme correctement (selon doc Edge Chromium, non re-verifie depuis ce dev box) | ## Cause racine Sur WebKitGTK le popup natif du `<input type="date">` est un widget GTK separe qui ne se ferme pas automatiquement apres commit. Comportement variable selon version GTK / theme. Bug upstream WebKitGTK, pas un bug Tauri. ## Decision : workaround in-place applique Option retenue : **`blur()` programmatique sur `change`** (option 2 du body de l'issue). - 1 ligne ajoutee dans `onChange` : `e.currentTarget.blur()` apres la logique existante. - No-op sur Edge Chromium (WebView2) et WKWebView ou le popup se ferme deja. - Pas d'API change, pas de regression cross-platform attendue. PR : **#189**. ## BalancePage Verifie : `BalancePage.tsx` n'a **pas** de `<input type="date">` (seulement des boutons de plage 3M/6M/1A/3A). La mention « eventuellement BalancePage » du body est moot. ## Suivi : 7 autres date inputs Le bug WebKitGTK touche tous les `<input type="date">` du codebase (8 au total : 1 in scope ici + 7 ailleurs). Pour ne pas etendre cette PR au-dela du scope explicite de l'issue, le meme workaround est tracke pour les 7 autres dans **#188**. ## Smoke test Windows Pas effectue (impossible depuis le dev box Linux). Mitigation : - `blur()` est une primitive DOM standard, comportement identique cross-WebView. - WebView2 ferme deja le popup avant que `blur()` soit interprete : appel sans effet observable. - Le release.yml CI build le NSIS Windows ; toute regression surfacerait au prochain release.

maximus added

status:in-progress

and removed

status:ready

labels 2026-05-02 19:57:43 +00:00

maximus added the

status:approved

label 2026-05-02 19:59:43 +00:00

maximus closed this issue

2026-05-02 20:01:07 +00:00

maximus referenced this issue from a commit

2026-05-02 20:01:09 +00:00