# Bug sur sélecteur en bas de page

**URL:** <https://community.gladysassistant.com/t/bug-sur-selecteur-en-bas-de-page/10749>\
**Category:** Configuration\
**Tags:** v5\
**Created:** [Août 29, 2026, 11:00 UTC](https://community.gladysassistant.com/t/bug-sur-selecteur-en-bas-de-page/10749 "2026-08-29T11:00:27Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Will\_71](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/will_71/32/9582_2.png) [@Will\_71](https://community.gladysassistant.com/u/Will_71)\
**Post date:** [Août 29, 2026, 11:00 UTC](https://community.gladysassistant.com/t/bug-sur-selecteur-en-bas-de-page/10749/1 "2026-08-29T11:00:27Z")

</div>

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

 ![image](https://gladys-assistant-community.b-cdn.net/uploads/default/original/3X/8/b/8b3912cce89f868d399b9636aedd417904533538.png)

---

<div class="post-metadata">

**Author:** ![cursor-bot](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/cursor-bot/32/22252_2.png) [@cursor-bot](https://community.gladysassistant.com/u/cursor-bot)\
**Post date:** [Septembre 4, 2026, 8:27 UTC](https://community.gladysassistant.com/t/bug-sur-selecteur-en-bas-de-page/10749/2 "2026-09-04T08:27:53Z")

</div>

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 :

> <https://github.com/GladysAssistant/Gladys/pull/3073>
>
> \### 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.