Compare commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
b6b2f15c12 |
@@ -425,27 +425,49 @@ Resultados reales, uno por uno (código de cada prueba en
|
|||||||
un dispositivo real.
|
un dispositivo real.
|
||||||
21b. **Accesibilidad del checkout completo** por teclado (no solo el
|
21b. **Accesibilidad del checkout completo** por teclado (no solo el
|
||||||
buscador) — tab order y foco visible en los 3 pasos.
|
buscador) — tab order y foco visible en los 3 pasos.
|
||||||
22. **Importación manual de imágenes no se refleja en el storefront**
|
22. **Importación manual de imágenes no se reflejaba en el storefront**
|
||||||
(reportado por el usuario 2026-09-20): subir/editar imágenes de un
|
(reportado por el usuario 2026-09-20) — **causa raíz encontrada y
|
||||||
producto a mano (vs. importación por CSV, que sí funciona) no
|
arreglada en código (2026-09-20), pendiente confirmar con una
|
||||||
aparece del lado del storefront. Falta reproducir contra el flujo
|
edición real.** `medusaFetch()` en `lib/headless/providers/medusa.ts`
|
||||||
real de importación manual del admin de Medusa (ver
|
usaba `next:{revalidate:60,tags:["medusa-products"]}`, caché en
|
||||||
`temp-admin`/`ari-shopping-tienda` en memoria) y confirmar si es
|
memoria por-pod que sobrevivía a `force-dynamic`. Con
|
||||||
caché (ISR de Next, `force-dynamic` ya está en la página de
|
`frontend-deploy` en 2 réplicas sin cacheHandler compartido, el POST
|
||||||
producto — ver más arriba), staleness de Meilisearch (ver memoria
|
de `/api/revalidate` del subscriber de Medusa solo llegaba a uno de
|
||||||
`search-inventory-staleness`, mismo síntoma de "el catálogo directo
|
los dos pods — el otro seguía sirviendo datos viejos hasta que el
|
||||||
sí, la búsqueda no") o algo específico del pipeline de importación
|
TTL expirara solo. Una edición puntual + revisar al toque tenía
|
||||||
en `commerce-backend`.
|
~50% de chance de pegarle al pod stale; una importación CSV (mucho
|
||||||
23. **En mobile, la visualización de imágenes de producto se corta y
|
más lenta) le daba tiempo de sobra al TTL para expirar en ambos.
|
||||||
obliga a scrollear** (reportado por el usuario 2026-09-20, con
|
**Fix:** se sacó el `next.revalidate`/`tags` del fetch — ya en
|
||||||
captura real de `shop.cruzcloud.net` en un producto con múltiples
|
producción. Falta la prueba con una edición manual real (vía
|
||||||
fotos). Toda la clase de bug de overflow por falta de `min-w-0` ya
|
`temp-admin`/`ari-shopping-tienda` en memoria) para confirmar que
|
||||||
se revisó en vivo en esta sesión y sigue presente en
|
el síntoma original desapareció, no solo que la causa técnica tiene
|
||||||
`product-gallery.tsx` y `app/product/[slug]/page.tsx` — sospecha
|
sentido.
|
||||||
sin confirmar: el modal "Zoom interactivo"
|
23. **En mobile (viewport real de 320px), la página se cortaba y
|
||||||
(`ProductGallery`/`DialogContent`, `min-h-[70vh]` +
|
obligaba a scrollear horizontalmente — RESUELTO 2026-09-20.**
|
||||||
`overflow-hidden`) en viewport móvil real, donde la barra de
|
Reportado por el usuario con captura real de `shop.cruzcloud.net`.
|
||||||
direcciones de Chrome/Safari hace que `100vh` mida más que el área
|
**No era la galería de imágenes** (esa clase de bug con `min-w-0`
|
||||||
visible real. Pendiente reproducir con un dispositivo real o
|
ya estaba corregida desde la sesión anterior, confirmado en vivo
|
||||||
emulación de `visualViewport` (Playwright con viewport móvil no
|
que seguía sana). Dos causas reales encontradas por separado,
|
||||||
replica el comportamiento dinámico de la barra de direcciones).
|
reproducidas con Playwright contra un viewport de 320×480 real:
|
||||||
|
- **Footer, bloque "Newsletter"** (`components/layout/footer.tsx`):
|
||||||
|
el párrafo de texto, sin `min-w-0`, le pedía al grid item su
|
||||||
|
ancho de una sola línea sin wrappear (~335px, medido en vivo)
|
||||||
|
en vez de dejarse achicar — forzaba la única columna del grid
|
||||||
|
(`sm:grid-cols-2 lg:grid-cols-4`, sin `grid-cols-1` propio pero
|
||||||
|
con auto-stacking correcto por debajo de `sm`) a 335px de ancho,
|
||||||
|
arrastrando la página entera. Mismo bug de fondo que el ya
|
||||||
|
documentado en la galería, en un grid en vez de un
|
||||||
|
`overflow-x-auto`.
|
||||||
|
- **Navbar, fila de "Departamentos"/"Todo"** (`components/layout/navbar.tsx`):
|
||||||
|
los 3 items de esa fila (botón de menú, "Departamentos", "Todo")
|
||||||
|
tenían los tres `shrink-0` — ninguno podía achicarse, así que si
|
||||||
|
los tres no entraban en 320px, desbordaban sí o sí (`min-w-0` no
|
||||||
|
aplica cuando el ítem no está pensado para achicarse). Fix:
|
||||||
|
ocultar el texto "Departamentos" en mobile (queda ícono + flecha,
|
||||||
|
con `aria-label` agregado para no perder accesibilidad), libera
|
||||||
|
espacio suficiente para que quepan los tres.
|
||||||
|
Verificado en vivo con Playwright (viewport 320×480 real, no
|
||||||
|
emulación de dispositivo con DPR) contra staging y producción
|
||||||
|
después del deploy: `document.documentElement.scrollWidth ===
|
||||||
|
clientWidth` en home y en página de producto, en ambos ambientes —
|
||||||
|
sin overflow.
|
||||||
Reference in new issue
Block a user