È strano… sei connesso? Inoltre, hai provato a scorrere lateralmente per vedere se appare la barra di scorrimento orizzontale?
Se è così, mi chiedo se sia qualcosa che accade solo con gli account di amministratore.
1 Mi Piace
pmusaraj
28 Aprile 2026, 6:51pm
44
Non sono effettuato l’accesso, ho provato a scorrere da sinistra a destra.
È possibile che si tratti di un problema che si verifica solo con gli amministratori. Non riesco a riprodurlo con un utente normale in una finestra di emulazione mobile di Chrome.
In realtà: riesco a riprodurlo come amministratore sul nostro blog.
2 Mi Piace
pmusaraj
28 Aprile 2026, 7:04pm
45
Il problema della barra di scorrimento orizzontale dovrebbe essere risolto non appena questa modifica verrà integrata: UX: Ensure hidden upload field does not break layout - Pull Request #39619 - discourse/discourse - GitHub
4 Mi Piace
Ottimo, grazie! @pmusaraj
4 Mi Piace
Thiago_Mobilon:
Il flusso attuale è un po’ un killer di conversioni: l’utente clicca su “Accedi” → si apre una nuova scheda → avviene l’accesso → l’utente rimane sulla homepage della community. Tornando all’articolo del blog, l’iframe sembra ancora disconnesso finché l’utente non aggiorna manualmente l’intera pagina. È un ciclo confuso che fa desistere le persone e le fa andare via prima di commentare.
Solo un rapido avviso: sebbene questo flusso sia stato corretto per Google One Tap, si comporta ancora così quando si utilizza l’accesso nativo di Discourse.
1 Mi Piace
Falco
6 Maggio 2026, 3:08pm
48
Stiamo lavorando per migliorare questo flusso
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.
È una modifica complessa, ma speriamo di poter offrire una migliore esperienza utente.
6 Mi Piace
Ho trovato un altro bug dell’interfaccia utente:
Quando faccio clic per modificare il mio post, appare uno spazio vuoto in fondo all’iframe senza alcun contenuto. Il modulo “standard” rimane aperto, ma il mio commento non si trova al suo interno per la modifica. Inoltre, l’elemento che mostra il numero di post del thread si sposta verso sinistra.
1 Mi Piace
Falco
7 Maggio 2026, 8:27pm
50
Sembra simile a un bug del compositore AI Bot, giusto @keegan ?
1 Mi Piace
keegan
8 Maggio 2026, 8:29pm
52
Thiago_Mobilon:
Quando clicco per modificare il mio post, appare uno spazio vuoto in fondo all’iframe senza alcun contenuto. Il modulo “standard” rimane aperto, ma il mio commento non è all’interno per la modifica. Inoltre, l’elemento che mostra il numero di post della discussione si sposta verso sinistra.
Questo dovrebbe essere ora risolto 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 Mi Piace
Stavo dando un’occhiata alle statistiche e mi chiedo se tutto funzioni come previsto. Vedo meno di 400 visualizzazioni giornaliere nella sezione “Visualizzazioni incorporate”.
Per dare un contesto, l’intera Community aveva circa 8.000 visualizzazioni al giorno prima di passare all’incorporamento dell’app completa—e quel numero è aumentato di oltre 5 volte da quando siamo andati online.
Non dovrebbe questa differenza essere riflessa nella sezione “Visualizzazioni incorporate”?
1 Mi Piace
Falco
15 Maggio 2026, 5:09pm
55
Thiago_Mobilon:
5. Attrito durante l’accesso Il flusso attuale è un po’ un killer di conversioni: l’utente clicca su accesso → si apre una nuova scheda → avviene l’accesso → l’utente si ritrova sulla homepage della community. Tornando sul post del blog, l’iframe appare ancora come non autenticato finché l’utente non aggiorna manualmente l’intera pagina. È un ciclo confuso che fa desistere le persone e le porta ad abbandonare il post prima di poter commentare.
Dall’attivazione del nuovo embed, i nostri registri giornalieri sono più che raddoppiati , il che è fantastico. Tuttavia, le nostre metriche di engagement non sono cambiate affatto. In realtà, il nostro DAU/MAU è diminuito – abbiamo più utenti autenticati, ma non interagiscono. Metriche come “Utenti attivi giornalieri”, “Nuovi contributori” e “Pubblicazioni” non hanno visto alcun aumento.
Questo dimostra che le persone vogliono partecipare alla conversazione, ma si perdono nel ciclo di accesso e abbandonano il post prima di poter effettivamente commentare.
Questo è ora risolto, si prega di aggiornare per ottenere il nuovo flusso di accesso.
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 Mi Piace
Credo che la nuova funzione delle risposte annidate possa non essere compatibile con la modalità Embed.
Ho attivato le risposte annidate su un argomento per provarle, e invece di caricare la sezione dei commenti, l’iframe ha caricato il post all’interno del post.
1 Mi Piace
Il plugin degli annunci inserisce anche pubblicità nella versione embed, il che rompe il layout.
Penso che potremmo mantenere l’opzione “in fondo al post” (gli annunci che appaiono tra i post), poiché il loro formato si adatterebbe bene all’embed (solitamente un rettangolo medio: 300x250).
Tuttavia, gli altri slot non hanno senso nella versione embed, quindi sarebbe fantastico rimuoverli.
1 Mi Piace
Ho configurato lo slot “post bottom” per vedere come appariva nell’embed, e ha generato una barra di scorrimento orizzontale nella vista desktop — anche se ho abilitato solo dimensioni molto più piccole della larghezza dell’embed.
Mentre ci sono, ho anche notato che su mobile, il margine destro dei post è più ampio di quello sinistro (non credo sia correlato alle pubblicità).
