Bug sur sélecteur en bas de page

Will_71 · Août 29, 2026, 11:00

Petit bug où on ne peut pas sélectionner le capteur dans un sélecteur en bas de page dans le Widget Appareil.

cursor-bot · Septembre 4, 2026, 8:27

Salut tout le monde !

Ce sujet est désormais en cours de développement.

Une PR a été ouverte pour garder les menus des sélecteurs du dashboard accessibles en bas de l’écran :

github.com/GladysAssistant/Gladys

fix(dashboard): keep the widget editor's select menus reachable at the bottom of the screen (#3073)

master ← claude/bug-selecteur-bas-page-m998p7

ouvert 08:26AM - 04 Sep 26 UTC

Pierre-Gilles

+118 -79

### Description Community report: in the **Devices** widget editor, the "Add a …device" select at the bottom of the panel opens a menu whose bottom is cut off by the edge of the screen, and the options down there cannot be selected. **Root cause.** The 8 dashboard widget editors (devices, device-in-room, chart, gauge, energy consumption, music, scene, user presence) plus `SelectDeviceFeature`, `RoomSelector` and `MigrateDeviceModal` imported `react-select` directly, so they never got the `menuPosition: 'fixed'` that #3037 added to the shared `components/form/Select` wrapper. Their portaled menus were still placed against the *document* rather than the viewport, and react-select scrolled the page to make room, which `closeMenuOnScroll` turned into an immediate close. On top of that, react-select 4 computes the placement exactly **once**, when the menu mounts, so the menu ends up out of reach whenever the situation changes afterwards: - the soft keyboard slides up right after the tap that opened the menu (phone/tablet) and the viewport shrinks under it; - the option list grows while the menu is open (the user erases part of the filter): a menu that fit when short grows past the bottom of the viewport — this is the exact symptom of the screenshot; - and a pre-existing quirk: under preact/compat, emotion inserts a first-seen style in a layout effect, *after* refs are attached, so the very first menu opened on a page was measured unstyled (an in-flow `div` at the end of `<body>` with every option visible) and placed on garbage, usually flipped above its control whether or not there was room there. **Fix.** - Every portaled select now goes through the shared wrapper (fixed positioning, no page scroll, one place to maintain); the now-redundant `menuPlacement` / `menuPortalTarget` / `closeMenuOnScroll` props are dropped from the callers. - The wrapper installs a `Menu` component that re-runs react-select's own placement when the viewport resizes (`resize` + `visualViewport` `resize`) or when the menu grew since the last render, so the menu is constrained or flipped above its control against the real available space. Only a menu currently below its control is re-placed: react-select 4's portal ignores a return to the initial placement, so a menu that flipped to `top` must not be flipped back (and it is never under the keyboard anyway). - The initial placement is deferred to a microtask, i.e. after the commit and its effects, before paint, so the first menu of a page is measured styled. **Verified** with Playwright against the demo dashboard editor (desktop side panel, 1280px wide), before → after: | Scenario | Before | After | |---|---|---| | First menu of the page, control high in the panel | flipped above the control (accidental, cut off when there is no room above) | placed below | | Control at the bottom of the panel, 600px viewport | flips above | flips above (unchanged) | | Opened with room below, then viewport shrinks (soft keyboard) | menu stays where it was | menu re-placed above the control | | Opened with a short filtered list, filter erased | menu grows to 220px and overflows the viewport bottom (bottom 835px for a 720px viewport) — the reported bug | menu flips above the control | `npm run eslint` and `npm run prettier-check` pass on the changed files; `vite build` succeeds. ## Forum Forum: https://community.gladysassistant.com/t/bug-sur-selecteur-en-bas-de-page/10749 ### Checklist - [x] Tests pass: front-only change, no server code touched; Cypress not run in this environment (it needs a running server) — the change was verified with Playwright scenarios described above - [x] Linter and prettier pass on both front and server (`npm run eslint`, `npm run prettier`) - [x] No undocumented breaking change 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01Bg7EqaUKQH4zonmn4bcmdg --- _Generated by [Claude Code](https://claude.ai/code/session_01Bg7EqaUKQH4zonmn4bcmdg)_

N’hésitez pas à suivre la PR, à tester (optionnel, surtout pour les petites demandes) et à faire vos retours ici si besoin.

Sujet		Réponses	Vues
Bug Nouveau thème Développement bug , scene	1	44	Août 25, 2026
Anomalie affichage (ouverture/température) Configuration v5	2	84	Septembre 4, 2026
Problème d’affichage responsive avec débordement horizontal Demandes livrées in-progress	1	54	Septembre 4, 2026
Barre des dashboards : augmenter l'opacité du menu drop-down en desktop Configuration v5	1	48	Septembre 4, 2026
Mettre la barre latérale gauche en mode tiroir Demande de fonctionnalités in-progress	1	43	Août 28, 2026

Bug sur sélecteur en bas de page

Sujets connexes