Isso é estranho… você está logado? Também, você tentou deslizar para os lados para ver se a barra de rolagem horizontal aparece?
Se sim, me pergunto se é algo que só acontece com contas de administrador.
1 curtida
pmusaraj
(Penar Musaraj)
Abril 28, 2026, 6:51pm
44
Não estou logado. Tentei deslizar para a esquerda e para a direita.
Pode ser algo que ocorre com administradores. Não consigo reproduzir o problema com um usuário comum na janela de emulação móvel do Chrome.
Na verdade: consigo reproduzir como administrador no nosso próprio blog.
2 curtidas
pmusaraj
(Penar Musaraj)
Abril 28, 2026, 7:04pm
45
4 curtidas
Ótimo, obrigado! @pmusaraj
4 curtidas
Thiago_Mobilon:
O fluxo atual é um pouco um assassino de conversão: o usuário clica em entrar → abre uma nova aba → o login ocorre → o usuário fica na página inicial da comunidade. De volta à postagem do blog, o iframe ainda parece deslogado até que o usuário atualize manualmente toda a página. É um loop confuso que faz as pessoas desistirem e saírem antes de comentar.
Apenas um aviso rápido: embora esse fluxo tenha sido corrigido para o Google One Tap, ele ainda se comporta dessa forma ao usar o login nativo do Discourse.
1 curtida
Falco
(Falco)
Maio 6, 2026, 3:08pm
48
Estamos trabalhando para melhorar esse fluxo
main ← embed-full-app-signin-flow
drafted 04:08PM - 05 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 change adds an opt-in `embed_full_app_signin_flow` site setting that intercepts logged-out actions inside the iframe with a guided flow: an in-iframe modal opens a top-level sign-in tab that auto-closes via `postMessage` on success, and the iframe reloads to pick up the session cookie. On Safari, the flow first calls `requestStorageAccess()` to bypass ITP before opening the popup.
## Flow
1. User clicks an auth-gated action (Like, Reply CTA, etc.). `showLogin` / `showCreateAccount` (and the embed-topic-footer reply CTA) route into the new `embed-auth-flow` service.
2. **Safari only**: if `hasStorageAccess()` is false, an in-iframe modal asks the user to share their session. Confirming calls `requestStorageAccess()` (synchronously inside the click handler so user activation is preserved), persists the original intent, and reloads the iframe.
3. A sign-in modal opens a top-level `/login?embed_signin_callback=1` (or `/signup`) tab. A new `embed-signin-popup-callback` initializer detects a successful sign-in in that tab, posts a message to the opener, and closes the tab.
4. The iframe reloads on the explicit `postMessage` success signal so the user picks up their session. Plain popup close (user dismissed) tears down silently — no false "signed in" state.
## Setting
- `embed_full_app_signin_flow` (boolean, default `false`, in the `embedding` area). Off by default; the existing Safari-only on-load storage access prompt and the legacy `window.open("/login")` paths continue to run when the flag is off.
- Activating this requires the embed to be **same-site** to the host page (e.g. `forum.discourse.org` ↔ `meta.discourse.org`) **or** `same_site_cookies = "None"` for cross-site embeds. The browser's SameSite policy still applies to cookies after `requestStorageAccess()`, so cross-site Lax/Strict cookies cannot be delivered to the iframe.
## Implementation notes
- **User activation preserved.** The modal is rendered via `service:modal` with native `<button {{on "click" handler}}>` elements rather than `service:dialog` (which wraps actions in `next()` and breaks user activation), so `requestStorageAccess()` and `window.open()` see a live activation token.
- **Intent persisted across reload.** Sign-up vs. sign-in intent survives the storage-access reload via `sessionStorage`.
- **API-unsupported fallback.** On Safari without `document.requestStorageAccess`, the service opens a plain top-level login tab (no callback) 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.
## Tests
`tests/unit/services/embed-auth-flow-test.js` covers the state machine: gating, the Safari/non-Safari split for Storage Access, post-reload handling (including signup-intent preservation), denial behaviour, popup URL routing, and the API-unsupported fallback.
É uma mudança complexa, mas temos esperança de conseguir uma melhor experiência de usuário.
6 curtidas
Encontrei outro bug na interface:
Ao clicar para editar minha postagem, aparece um espaço em branco na parte inferior do iframe sem nenhum conteúdo. O formulário ‘padrão’ permanece aberto, mas meu comentário não está dentro dele para edição. Além disso, o elemento que mostra a contagem de postagens da thread se desloca para a esquerda.
1 curtida
Falco
(Falco)
Maio 7, 2026, 8:27pm
50
Soa como um bug no compositor do Bot de IA, certo, @keegan ?
1 curtida
keegan
(Keegan George)
Maio 8, 2026, 8:29pm
52
Thiago_Mobilon:
Quando clico para editar minha postagem, aparece um espaço em branco na parte inferior do iframe sem conteúdo. O formulário ‘padrão’ permanece aberto, mas meu comentário não está dentro dele para edição. Além disso, o elemento que mostra a contagem de postagens da thread se desloca para a esquerda.
Isso deve estar resolvido agora com:
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 curtidas
Estava apenas analisando as estatísticas e estou me perguntando se tudo está funcionando conforme o esperado. Estou vendo menos de 400 visualizações diárias de página em “Visualizações Incorporadas”.
Para contextualizar, toda a Comunidade costumava ter cerca de 8 mil visualizações de página por dia antes de mudarmos para a incorporação completa do aplicativo — e esse número saltou mais de 5 vezes desde que colocamos no ar.
Esse diferencial não deveria ser refletido na seção “Visualizações Incorporadas”?
1 curtida
Falco
(Falco)
Maio 15, 2026, 5:09pm
55
Thiago_Mobilon:
5. Atrito no Login
O fluxo atual é um grande obstáculo para conversão: o usuário clica em login → abre-se uma nova aba → o login é realizado → o usuário fica na página inicial da comunidade. De volta à postagem do blog, o iframe ainda parece deslogado até que o usuário atualize manualmente toda a página. É um ciclo confuso que faz as pessoas desistirem e saírem antes de comentar.
Desde que ativamos o novo embed, nossos cadastros diários mais que dobraram , o que é ótimo. No entanto, nossas métricas de engajamento não mudaram nada. Na verdade, nossa taxa DAU/MAU caiu – temos mais usuários logados, mas eles não estão interagindo. Métricas como “Usuários Engajados Diariamente”, “Novos Contribuidores” e “Publicações” não apresentaram nenhum aumento.
Isso prova que as pessoas querem participar da conversa, mas ficam perdidas no ciclo de login e abandonam a postagem antes de conseguir comentar de verdade.
Isso já foi corrigido. Atualize para obter o novo fluxo de login.
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 curtidas
Acho que o novo recurso de respostas aninhadas pode não ser compatível com o Modo de Incorporação.
Ativei as respostas aninhadas em um tópico para testar e, em vez de carregar a seção de comentários, o iframe acabou carregando a postagem dentro da postagem.
1 curtida