Das ist seltsam… bist du eingeloggt? Hast du auch versucht, seitlich zu wischen, um zu sehen, ob die horizontale Bildlaufleiste erscheint?
Wenn ja, frage ich mich, ob das nur bei Admin-Konten passiert.
1 „Gefällt mir“
pmusaraj
28. April 2026 um 18:51
44
Ich bin nicht angemeldet, ich habe versucht, nach links und rechts zu wischen.
Es ist möglicherweise etwas, das bei Administratoren passiert. Ich sehe keine Reproduktion mit einem normalen Benutzer in einem Chrome Mobile-Emulator-Fenster.
Tatsächlich: Ich kann es als Administrator auf unserem eigenen Blog reproduzieren.
2 „Gefällt mir“
pmusaraj
28. April 2026 um 19:04
45
4 „Gefällt mir“
Thiago_Mobilon:
Der aktuelle Ablauf ist ein ziemlicher Konversions-Killer: Der Benutzer klickt auf „Anmelden“ → Ein neuer Tab wird geöffnet → Die Anmeldung erfolgt → Der Benutzer landet auf der Community-Startseite. Zurück im Blogbeitrag sieht das iframe weiterhin so aus, als sei der Benutzer nicht angemeldet, bis dieser die gesamte Seite manuell aktualisiert. Es ist eine verwirrende Schleife, die dazu führt, dass die Leute aufgeben und gehen, bevor sie einen Kommentar hinterlassen.
Nur eine kurze Info: Während dieser Ablauf für Google One Tap behoben wurde, verhält er sich bei der Verwendung der nativen Discourse-Anmeldung immer noch so.
1 „Gefällt mir“
Falco
6. Mai 2026 um 15:08
48
Wir arbeiten daran, diesen Ablauf zu verbessern
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 ist eine komplexe Änderung, aber wir hoffen, dass wir eine bessere UX erreichen können.
6 „Gefällt mir“
Ich habe einen weiteren UI-Bug gefunden:
Wenn ich klicke, um meinen Beitrag zu bearbeiten, erscheint am unteren Rand des iframes ein leerer Bereich ohne Inhalt. Das „Standard“-Formular bleibt offen, aber mein Kommentar befindet sich nicht darin, um bearbeitet zu werden. Außerdem verschiebt sich das Element, das die Anzahl der Beiträge im Thread anzeigt, nach links.
1 „Gefällt mir“
Falco
7. Mai 2026 um 20:27
50
Klingt das nicht wie ein Fehler im AI Bot Composer, @keegan ?
1 „Gefällt mir“
keegan
8. Mai 2026 um 20:29
52
Thiago_Mobilon:
Wenn ich auf „Beitrag bearbeiten“ klicke, erscheint am unteren Rand des iFrames ein leerer Bereich ohne Inhalt. Das „Standard“-Formular bleibt geöffnet, aber mein Kommentar befindet sich nicht darin, um bearbeitet zu werden. Außerdem verschiebt sich das Element, das die Anzahl der Beiträge im Thread anzeigt, nach links.
Dies sollte jetzt mit folgendem Commit behoben sein:
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 „Gefällt mir“
Ich habe gerade die Statistiken überprüft und frage mich, ob alles wie erwartet funktioniert. Ich sehe weniger als 400 tägliche Seitenaufrufe unter „Embedded Views“.
Zum Kontext: Die gesamte Community hatte früher etwa 8.000 Seitenaufrufe pro Tag, bevor wir auf die vollständige App-Einbettung umgestiegen sind – und diese Zahl ist seit dem Go-Live um mehr als das Fünffache gestiegen.
Sollte dieser Unterschied nicht im Abschnitt „Embedded Views“ widergespiegelt werden?
1 „Gefällt mir“
Falco
15. Mai 2026 um 17:09
55
Thiago_Mobilon:
5. Login-Friction Der aktuelle Ablauf ist ein echter Conversion-Killer: Der Benutzer klickt auf „Anmelden“ → Ein neuer Tab wird geöffnet → Die Anmeldung findet statt → Der Benutzer landet auf der Community-Startseite. Zurück auf dem Blog-Beitrag sieht das iframe weiterhin so aus, als ob der Benutzer nicht angemeldet wäre, bis er die gesamte Seite manuell aktualisiert. Es ist ein verwirrender Kreislauf, der dazu führt, dass die Leute aufgeben und den Beitrag verlassen, bevor sie kommentieren können.
Seit wir das neue Embed aktiviert haben, haben sich unsere täglichen Registrierungen mehr als verdoppelt , was großartig ist. Allerdings haben sich unsere Engagement-Metriken überhaupt nicht verbessert. Tatsächlich ist unser DAU/MAU-Ratio gesunken – wir haben mehr angemeldete Benutzer, aber diese interagieren nicht. Metriken wie „Täglich aktive Benutzer“, „Neue Mitwirkende“ und „Beiträge“ haben keine Zunahme verzeichnet.
Dies beweist, dass die Leute dabei sein wollen , aber im Anmelde-Kreislauf verloren gehen und den Beitrag verlassen, bevor sie tatsächlich kommentieren können.
Dies wurde nun behoben, bitte aktualisieren Sie, um den neuen Anmelde-Ablauf zu erhalten.
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 „Gefällt mir“
Ich glaube, die neue Funktion für verschachtelte Antworten ist möglicherweise nicht mit dem Embed-Modus kompatibel.
Ich habe verschachtelte Antworten in einem Thema aktiviert, um es zu testen, und statt den Kommentarbereich zu laden, hat das iframe den Beitrag innerhalb des Beitrags geladen.
1 „Gefällt mir“
Das Werbe-Plugin fügt auch in die eingebettete Version Werbung ein, was das Layout zerstört.
Ich denke, wir könnten die Option „Nachrichtenende“ (die Anzeigen, die zwischen den Beiträgen erscheinen) beibehalten, da ihr Format gut in die Einbettung passt (normalerweise ein mittleres Rechteck: 300x250).
Die anderen Anzeigenplätze machen in der eingebetteten Version jedoch keinen Sinn, daher wäre es großartig, sie zu entfernen.
1 „Gefällt mir“
Ich habe den „Post-Bottom“-Slot konfiguriert, um zu sehen, wie er im Embed aussieht, und er hat in der Desktop-Ansicht einen horizontalen Bildlaufbalken erzeugt — obwohl ich nur Größen aktiviert habe, die deutlich kleiner als die Breite des Embeds sind.
Da ich dabei war, habe ich auch festgestellt, dass auf Mobilgeräten der rechte Rand der Beiträge breiter ist als der linke Rand (ich glaube nicht, dass dies mit den Anzeigen zusammenhängt).
