From fc8f38afde838495f4a51e401303d2c02dbc6888 Mon Sep 17 00:00:00 2001 From: Nicolas Date: Thu, 20 Aug 2026 23:19:21 +0200 Subject: [PATCH] =?UTF-8?q?fix(planning):=20corrige=20le=20d=C3=A9bordemen?= =?UTF-8?q?t=20du=20dialogue=20de=20s=C3=A9lection=20pour=20les=20sources?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Le dialogue de sélection de recette (RecipePickerDialog) affichait bien les données renvoyées par le serveur, mais rien ne s'affichait dans la fenêtre tant que le nombre d'items dépassait sa hauteur — reproduit en direct via le compte de test : la tab TheMealDB (25 items, contrairement aux quelques recettes perso habituelles) rend le bug visible alors qu'il touchait déjà le tableau simple des autres onglets, juste sans jamais assez de lignes pour le déclencher. Cause : .recipes-page__catalog et .recipe-table-wrap se dimensionnent via flex: 1; min-height: 0, ce qui ne fonctionne que si leur parent est display: flex — vrai sur /recettes (.recipes-page l'établit), faux dans ce dialogue où le contenu est monté directement dans .dialog-panel__body (Dialog.tsx), un simple conteneur en flux bloc. Sans ce contexte, la zone catalogue grossissait à la taille de son contenu (1499px mesuré en direct contre 605px de hauteur réellement disponible) au lieu d'être bornée et scrollable dans ses propres limites. Correctif scoping .dialog-panel__body en display: flex; flex-direction: column uniquement sous .recipe-picker-dialog (tous les autres appelants de Dialog gardent le flux bloc par défaut), plus flex: 1; min-height: 0 sur .recipe-table-wrap pour qu'il profite du même contexte. Vérifié en direct (navigateur, compte de test, tab TheMealDB) : la zone catalogue passe de 1499px à 450px (borné), les lignes redeviennent visibles/cliquables sans affecter les autres onglets ni l'étape de confirmation des portions (rendue par un Dialog séparé, sans la classe recipe-picker-dialog). Tenu aussi en viewport réduit (1024x640). pnpm exec tsc -b --force (web) — propre. pnpm --filter web build — propre. Co-Authored-By: Claude Sonnet 5 --- .../planning/recipe-picker-dialog.scss | 26 +++++++++++++++++++ 1 file changed, 26 insertions(+) diff --git a/apps/web/src/features/planning/recipe-picker-dialog.scss b/apps/web/src/features/planning/recipe-picker-dialog.scss index 7eb5d19..9ef18f7 100644 --- a/apps/web/src/features/planning/recipe-picker-dialog.scss +++ b/apps/web/src/features/planning/recipe-picker-dialog.scss @@ -6,6 +6,32 @@ .recipe-picker-dialog { max-width: 56rem; + + // `.dialog-panel__body` (dialog.scss) is a plain block-flow scroll + // container by default — fine for every other dialog's small form, but + // this one's browsing step embeds the same components `/recettes` uses + // (`RecipeTable`'s `.recipe-table-wrap`, `RecipeSourcesPanel`'s + // `.recipes-page__catalog`), both of which size themselves with + // `flex: 1; min-height: 0` and need a `display: flex` ancestor for that + // to mean anything — on the real page that ancestor is `.recipes-page` + // itself (see its own doc comment for the identical fix that page + // needed once); this dialog never renders that wrapper, so without this + // the catalog/table just grew to its full content height instead of + // being clipped and independently scrollable within the dialog's own + // bounds — harmless for the handful of rows a personal recipe tab + // usually has, but a source tab's ~25-item browse list made it obvious: + // everything past the dialog's fixed height rendered, technically, just + // never inside the visible/scrollable area. Scoped to this dialog only + // — every other `Dialog` caller keeps the plain block layout. + .dialog-panel__body { + display: flex; + flex-direction: column; + } + + .recipe-table-wrap { + flex: 1; + min-height: 0; + } } .recipe-picker__filters {