C’est étrange… êtes-vous connecté ? Avez-vous également essayé de faire défiler horizontalement pour voir si la barre de défilement horizontale apparaît ?
Si c’est le cas, je me demande si c’est quelque chose qui ne se produit qu’avec les comptes administrateur.
1 « J'aime »
pmusaraj
Avril 28, 2026, 6:51
44
Je ne suis pas connecté, j’ai essayé de faire un swipe gauche-droite.
C’est probablement quelque chose qui se produit avec les administrateurs. Je ne vois pas de reproductibilité avec un utilisateur ordinaire dans une fenêtre d’émulateur mobile Chrome.
En fait : je peux reproduire en tant qu’administrateur sur notre propre blog.
2 « J'aime »
pmusaraj
Avril 28, 2026, 7:04
45
4 « J'aime »
Thiago_Mobilon:
Le processus actuel décourage un peu les conversions : l’utilisateur clique sur « Se connecter » → un nouvel onglet s’ouvre → la connexion s’effectue → l’utilisateur se retrouve sur la page d’accueil de la communauté. Sur l’article de blog, l’iframe affiche toujours un état déconnecté jusqu’à ce que l’utilisateur rafraîchisse manuellement toute la page. C’est une boucle confuse qui incite les gens à abandonner et à partir avant de commenter.
Juste pour vous en informer : bien que ce processus ait été corrigé pour Google One Tap, il se comporte toujours ainsi lors de l’utilisation de la connexion native de Discourse.
1 « J'aime »
Falco
Mai 6, 2026, 3:08
48
Nous travaillons à améliorer ce flux.
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.
C’est un changement complexe, mais nous espérons pouvoir offrir une meilleure expérience utilisateur.
6 « J'aime »
J’ai trouvé un autre bug d’interface :
Lorsque je clique pour modifier mon message, un espace vide apparaît en bas de l’iframe sans aucun contenu. Le formulaire « standard » reste ouvert, mais mon commentaire n’y est pas pour être modifié. De plus, l’élément affichant le nombre de messages du fil se décale vers la gauche.
1 « J'aime »
Falco
Mai 7, 2026, 8:27
50
Ça ressemble à un bug dans le compositeur AI Bot, non @keegan ?
1 « J'aime »
keegan
Mai 8, 2026, 8:29
52
Thiago_Mobilon:
Lorsque je clique pour modifier mon message, un espace vide apparaît en bas de l’iframe sans aucun contenu. Le formulaire « standard » reste ouvert, mais mon commentaire n’y est pas pour être modifié. De plus, l’élément affichant le nombre de messages du fil se décale vers la gauche.
Cela devrait désormais être résolu avec :
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 « J'aime »
Je venais de passer en revue les statistiques et je me demande si tout fonctionne comme prévu. Je constate moins de 400 vues par jour dans la section « Vues intégrées ».
Pour vous donner un peu de contexte, la Communauté dans son entier enregistrait environ 8 000 vues par jour avant que nous ne passions à l’intégration de l’application complète — et ce chiffre a augmenté de plus de 5 fois depuis notre mise en ligne.
Cette différence ne devrait-elle pas être reflétée dans la section « Vues intégrées » ?
1 « J'aime »
Falco
Mai 15, 2026, 5:09
55
Thiago_Mobilon:
5. Friction lors de la connexion Le flux actuel est un vrai frein à la conversion : l’utilisateur clique sur « Se connecter » → un nouvel onglet s’ouvre → la connexion a lieu → l’utilisateur se retrouve sur la page d’accueil de la communauté. De retour sur l’article de blog, l’iframe affiche toujours l’état « non connecté » jusqu’à ce que l’utilisateur rafraîchisse manuellement toute la page. C’est une boucle confuse qui pousse les gens à abandonner et à partir avant de commenter.
Depuis l’activation du nouvel embed, nos inscriptions quotidiennes ont plus que doublé , ce qui est excellent. Cependant, nos indicateurs d’engagement n’ont pas bougé d’un millimètre. En fait, notre DAU/MAU a diminué : nous avons plus d’utilisateurs connectés, mais ils n’interagissent pas. Des métriques comme « Utilisateurs engagés par jour », « Nouveaux contributeurs » et « Publications » n’ont enregistré aucune hausse.
Cela prouve que les gens veulent participer à la discussion, mais ils se perdent dans cette boucle de connexion et abandonnent l’article avant de pouvoir réellement commenter.
Ce problème est maintenant résolu, veuillez mettre à jour pour bénéficier du nouveau flux de connexion.
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 « J'aime »
Je pense que la nouvelle fonctionnalité de réponses imbriquées pourrait ne pas être compatible avec le mode Embed.
J’ai activé les réponses imbriquées sur un sujet pour tester, et au lieu de charger la section des commentaires, l’iframe a fini par charger le message à l’intérieur du message.
1 « J'aime »
Le plugin de publicité insère également des annonces dans la version intégrée, ce qui casse la mise en page.
Je pense que nous pourrions conserver l’option « bas de l’article » (les annonces qui apparaissent entre les articles), car leur format conviendrait bien à l’intégration (généralement un rectangle moyen : 300x250).
Cependant, les autres emplacements n’ont pas de sens dans la version intégrée, il serait donc idéal de les supprimer.
1 « J'aime »
J’ai configuré l’emplacement « en bas de l’article » pour voir à quoi il ressemblerait dans l’intégration, et cela a génagé une barre de défilement horizontale dans la vue desktop — même si j’ai uniquement activé des tailles beaucoup plus petites que la largeur de l’intégration.
Tandis que j’y suis, j’ai également remarqué que sur mobile, la marge droite des articles est plus large que la marge gauche (je ne pense pas que cela soit lié aux publicités).
