Qué raro… ¿estás conectado? Además, ¿has probado a deslizar hacia los lados para ver si aparece la barra de desplazamiento horizontal?
Si es así, me pregunto si es algo que solo ocurre con las cuentas de administrador.
1 me gusta
pmusaraj
28 Abril, 2026 18:51
44
No estoy conectado. Intenté deslizar hacia la izquierda y hacia la derecha.
Es posible que sea un problema que ocurre con los administradores. No veo cómo reproducirlo con un usuario normal en una ventana de emulador móvil de Chrome.
En realidad: puedo reproducirlo como administrador en nuestro propio blog.
2 Me gusta
pmusaraj
28 Abril, 2026 19:04
45
El problema de la barra de desplazamiento horizontal debería solucionarse una vez que esto se implemente: UX: Ensure hidden upload field does not break layout - Pull Request #39619 - discourse/discourse - GitHub
4 Me gusta
¡Genial, gracias! @pmusaraj
4 Me gusta
Thiago_Mobilon:
El flujo actual es un auténtico matón de conversiones: el usuario hace clic en «Iniciar sesión» → se abre una nueva pestaña → se realiza el inicio de sesión → el usuario queda en la página principal de la comunidad. De vuelta en la entrada del blog, el iframe sigue mostrando que no has iniciado sesión hasta que el usuario actualiza manualmente toda la página. Es un bucle confuso que hace que la gente se rinda y se vaya antes de comentar.
Solo una pequeña aclaración: aunque este flujo se ha corregido para Google One Tap, sigue comportándose de esta manera cuando se utiliza el inicio de sesión nativo de Discourse.
1 me gusta
Falco
6 Mayo, 2026 15:08
48
Estamos trabajando para mejorar ese flujo
main ← embed-full-app-signin-flow
merged 04:07PM - 15 May 26 UTC
Previously, full app embeds loaded on a third-party domain could not see the for… um's session cookie, leaving users effectively logged out, and `showLogin` only opened a dead-end `/login` tab the iframe never reacted to.
This adds an `embed_full_app_signin_flow` site setting (on by default, gated to full app embed mode) that intercepts logged-out actions inside the iframe with a guided flow: bridge storage access if the iframe's cookie jar is partitioned, then either reload (if the user is already signed in elsewhere) or open a top-level sign-in tab and watch the session via polling.
## Flow
1. User clicks an auth-gated action (Reply CTA, Like, etc.). `showLogin` / `showCreateAccount` and the embed-topic-footer reply CTA route into the new `embed-auth-flow` service.
2. **If `document.hasStorageAccess()` is `false`** — Safari ITP, Firefox Total Cookie Protection, Chrome's 3p cookie phaseout — an in-iframe modal asks the user to share their session. Confirming calls `requestStorageAccess()` (synchronously inside the click handler so user activation is preserved).
3. Once we have access, the service probes `/session/current.json`. If the user is already signed in elsewhere (common Firefox ETP scenario), the iframe reloads to pick up the session — no popup.
4. Otherwise, a sign-in modal opens a top-level `/login?embed_signin_callback=1` (or `/signup`) tab and shows a waiting state with a spinner. The iframe polls `/session/current.json` every 3s for up to 5 min.
5. When polling sees a logged-in response, the iframe reloads. The popup self-closes once it has a session, driven by the `embed_signin_callback` query param + sessionStorage flag.
## Why polling instead of `postMessage`
The popup-side callback originally posted a success message back to the opener. Discourse's default `Cross-Origin-Opener-Policy` (`same-origin-allow-popups`) typically mismatches an embedding host's (`unsafe-none`), which severs `window.opener` on the popup's very first load — and any OAuth provider redirect amplifies this. Polling sidesteps the whole opener relationship and works regardless of COOP, OAuth, or the user opening the link in a new tab.
## Setting
- `embed_full_app_signin_flow` (boolean, default `true`, in the `embedding` area).
- The flow assumes the iframe can receive its cookies after popup sign-in — true when the embed is **same-site to the host page** (any SameSite setting) or when `same_site_cookies = "None"` is configured for cross-site embeds. We trust the admin to enable this only on a compatible deployment.
## Implementation notes
- **Browser-agnostic storage access.** `hasStorageAccess()` is the single signal — `true` on same-site/same-origin embeds (no prompt needed), `false` whenever the iframe's cookie jar is partitioned. No browser sniffing.
- **User activation preserved.** The modal uses native `<button {{on "click" handler}}>` rather than `service:dialog`, so `requestStorageAccess()` and `window.open()` see a live activation token in the click handler.
- **No reload after storage access.** `requestStorageAccess()` grants access for the current document; we chain directly into the next step in the same execution. Reloading would put the iframe back in partitioned mode in most browsers.
- **Popup self-close is param-driven, not opener-driven.** The callback initializer keys off `?embed_signin_callback=1` alone — `window.opener` is unreliable thanks to COOP.
- **API-unsupported fallback.** Without `document.requestStorageAccess`, the service opens a plain top-level login tab (no callback param) instead of trapping the user in a popup that cannot bridge cookies.
- **Storage access denial is a dead-end on purpose.** The catch handler does not chain to a sign-in popup, since a sign-in tab cannot help an iframe that lacks storage access. The user retries the action to be re-prompted.
- **Waiting modal.** While polling, the iframe shows a spinner and "Waiting for sign-in" message. Cancel stops the poll and closes the popup; the modal auto-dismisses on timeout.
## Tests
`tests/unit/services/embed-auth-flow-test.js` covers gating, the partitioned vs. non-partitioned split, the storage-access → sign-in chain, the already-signed-in → reload path, denial behaviour, popup URL routing, and the API-unsupported fallback.
Es un cambio complejo, pero esperamos poder ofrecer una mejor UX.
6 Me gusta
He encontrado otro error de interfaz de usuario:
Cuando hago clic para editar mi publicación, aparece un espacio en blanco en la parte inferior del iframe sin contenido. El formulario “estándar” permanece abierto, pero mi comentario no está dentro de él para editarlo. Además, el elemento que muestra el número de publicaciones del hilo se desplaza hacia la izquierda.
1 me gusta
Falco
7 Mayo, 2026 20:27
50
Suena similar a un error en el compositor de IA Bot, ¿verdad @keegan ?
1 me gusta
keegan
8 Mayo, 2026 20:29
52
Thiago_Mobilon:
Cuando hago clic para editar mi publicación, aparece un espacio en blanco en la parte inferior del iframe sin contenido. El formulario “estándar” permanece abierto, pero mi comentario no está dentro de él para editarlo. Además, el elemento que muestra la cantidad de publicaciones del tema se desplaza hacia la izquierda.
Esto debería estar ahora resuelto con:
committed 06:11PM - 08 May 26 UTC
**Previously**, clicking "edit" on a post in embed mode or an AI bot PM
would op… en the standard floating composer.
**This change** adds inline edit support to both the embed-mode and AI
bot docked composers, intercepting the edit action via app events and
handling the PUT request directly, so users never leave the docked
composer flow.
----
Embed Mode:
<img width="670" height="401" alt="embed-mode"
src="https://github.com/user-attachments/assets/bd11afc6-b7f0-456d-b0be-ddb48fdd964e"
/>
AI Bot:
<img width="786" height="230" alt="ai-bot"
src="https://github.com/user-attachments/assets/7c63fa08-cb03-4a5a-9405-b0f204264d02"
/>
5 Me gusta
Acabo de revisar las estadísticas y me pregunto si todo funciona como se espera. Veo menos de 400 visitas diarias en «Vistas integradas».
Para ponerlo en contexto, toda la Comunidad solía tener unas 8.000 visitas al día antes de cambiar a la integración de la aplicación completa, y desde que lanzamos el cambio esa cifra se ha multiplicado por más de cinco.
¿No debería reflejarse esa diferencia en la sección de «Vistas integradas»?
1 me gusta
Falco
15 Mayo, 2026 17:09
55
Thiago_Mobilon:
5. Fricción en el inicio de sesión El flujo actual es un poco un matón de conversiones: el usuario hace clic en «Iniciar sesión» → Se abre una nueva pestaña → El inicio de sesión se realiza → El usuario queda en la página principal de la comunidad. De vuelta en la entrada del blog, el iframe sigue pareciendo que no ha iniciado sesión hasta que el usuario actualiza manualmente toda la página. Es un bucle confuso que hace que la gente se rinda y se vaya antes de comentar.
Desde que activamos el nuevo embed, nuestros registros diarios se han más que duplicado , lo cual es genial. Sin embargo, nuestras métricas de participación no han movido un dedo. De hecho, nuestra DAU/MAU ha disminuido – tenemos más usuarios conectados, pero no están interactuando. Métricas como «Usuarios activos diarios», «Nuevos contribuyentes» y «Publicaciones» no han visto ningún aumento.
Esto demuestra que la gente quiere unirse a la conversación, pero se pierden en el bucle de inicio de sesión y abandonan la entrada antes de poder comentar realmente.
Esto ya está solucionado, por favor actualiza para obtener el nuevo flujo de inicio de sesión.
main ← embed-full-app-signin-flow
merged 04:07PM - 15 May 26 UTC
Previously, full app embeds loaded on a third-party domain could not see the for… um's session cookie, leaving users effectively logged out, and `showLogin` only opened a dead-end `/login` tab the iframe never reacted to.
This adds an `embed_full_app_signin_flow` site setting (on by default, gated to full app embed mode) that intercepts logged-out actions inside the iframe with a guided flow: bridge storage access if the iframe's cookie jar is partitioned, then either reload (if the user is already signed in elsewhere) or open a top-level sign-in tab and watch the session via polling.
## Flow
1. User clicks an auth-gated action (Reply CTA, Like, etc.). `showLogin` / `showCreateAccount` and the embed-topic-footer reply CTA route into the new `embed-auth-flow` service.
2. **If `document.hasStorageAccess()` is `false`** — Safari ITP, Firefox Total Cookie Protection, Chrome's 3p cookie phaseout — an in-iframe modal asks the user to share their session. Confirming calls `requestStorageAccess()` (synchronously inside the click handler so user activation is preserved).
3. Once we have access, the service probes `/session/current.json`. If the user is already signed in elsewhere (common Firefox ETP scenario), the iframe reloads to pick up the session — no popup.
4. Otherwise, a sign-in modal opens a top-level `/login?embed_signin_callback=1` (or `/signup`) tab and shows a waiting state with a spinner. The iframe polls `/session/current.json` every 3s for up to 5 min.
5. When polling sees a logged-in response, the iframe reloads. The popup self-closes once it has a session, driven by the `embed_signin_callback` query param + sessionStorage flag.
## Why polling instead of `postMessage`
The popup-side callback originally posted a success message back to the opener. Discourse's default `Cross-Origin-Opener-Policy` (`same-origin-allow-popups`) typically mismatches an embedding host's (`unsafe-none`), which severs `window.opener` on the popup's very first load — and any OAuth provider redirect amplifies this. Polling sidesteps the whole opener relationship and works regardless of COOP, OAuth, or the user opening the link in a new tab.
## Setting
- `embed_full_app_signin_flow` (boolean, default `true`, in the `embedding` area).
- The flow assumes the iframe can receive its cookies after popup sign-in — true when the embed is **same-site to the host page** (any SameSite setting) or when `same_site_cookies = "None"` is configured for cross-site embeds. We trust the admin to enable this only on a compatible deployment.
## Implementation notes
- **Browser-agnostic storage access.** `hasStorageAccess()` is the single signal — `true` on same-site/same-origin embeds (no prompt needed), `false` whenever the iframe's cookie jar is partitioned. No browser sniffing.
- **User activation preserved.** The modal uses native `<button {{on "click" handler}}>` rather than `service:dialog`, so `requestStorageAccess()` and `window.open()` see a live activation token in the click handler.
- **No reload after storage access.** `requestStorageAccess()` grants access for the current document; we chain directly into the next step in the same execution. Reloading would put the iframe back in partitioned mode in most browsers.
- **Popup self-close is param-driven, not opener-driven.** The callback initializer keys off `?embed_signin_callback=1` alone — `window.opener` is unreliable thanks to COOP.
- **API-unsupported fallback.** Without `document.requestStorageAccess`, the service opens a plain top-level login tab (no callback param) instead of trapping the user in a popup that cannot bridge cookies.
- **Storage access denial is a dead-end on purpose.** The catch handler does not chain to a sign-in popup, since a sign-in tab cannot help an iframe that lacks storage access. The user retries the action to be re-prompted.
- **Waiting modal.** While polling, the iframe shows a spinner and "Waiting for sign-in" message. Cancel stops the poll and closes the popup; the modal auto-dismisses on timeout.
## Tests
`tests/unit/services/embed-auth-flow-test.js` covers gating, the partitioned vs. non-partitioned split, the storage-access → sign-in chain, the already-signed-in → reload path, denial behaviour, popup URL routing, and the API-unsupported fallback.
4 Me gusta
Creo que la nueva función de respuestas anidadas podría no ser compatible con el Modo Embed.
Activé las respuestas anidadas en un tema para probarlo, y en lugar de cargar la sección de comentarios, el iframe terminó cargando la publicación dentro de la publicación.
1 me gusta
El plugin de anuncios también está insertando anuncios en la versión incrustada, lo que rompe el diseño.
Creo que podríamos mantener la opción de «parte inferior de la entrada» (los anuncios que aparecen entre entradas), ya que su formato encajaría bien en la versión incrustada (generalmente un rectángulo mediano: 300x250).
Sin embargo, los demás espacios no tienen sentido en la versión incrustada, así que sería genial eliminarlos.
1 me gusta
Configuré el espacio “parte inferior de la publicación” para ver cómo se vería en el embed, y generó una barra de desplazamiento horizontal en la vista de escritorio, a pesar de que solo habilité tamaños que son mucho más pequeños que el ancho del embed.
Mientras estaba en ello, también noté que en el móvil, el margen derecho de las publicaciones es más ancho que el margen izquierdo (no creo que esté relacionado con los anuncios).
