Tecnoblog の Discourse コメントに関する体験

Thiago_Mobilon · 2026 年 4 月 28 日午後 6:49

それは奇妙ですね…ログインされていますか？また、横スクロールバーが表示されるか確認するために横にスワイプしてみましたか？

もしそうなら、それが管理者アカウントにのみ発生する問題なのかもしれませんね。

pmusaraj · 2026 年 4 月 28 日午後 6:51

ログインしていません。左から右へのスワイプを試しましたが、機能しませんでした。

これは管理者にのみ発生する可能性のある問題のようです。Chrome のモバイルエミュレータウィンドウで通常ユーザーとしてテストした限り、再現しませんでした。

実際には、当社のブログで管理者として再現を確認できました。

pmusaraj · 2026 年 4 月 28 日午後 7:04

この変更がマージされ次第、水平スクロールバーの問題は修正されるはずです: UX: Ensure hidden upload field does not break layout by pmusaraj · Pull Request #39619 · discourse/discourse · GitHub

Thiago_Mobilon · 2026 年 4 月 28 日午後 7:05

ありがとうございます！@pmusaraj

Thiago_Mobilon · 2026 年 5 月 6 日午後 1:58

少しだけお知らせですが、このフローは Google One Tap については修正済みですが、ネイティブの Discourse ログインを使用する場合は、まだこのように動作しています。

Falco · 2026 年 5 月 6 日午後 3:08

そのフローの改善に取り組んでいます

github.com/discourse/discourse

FEATURE: Add in-iframe sign-in flow for full app embed mode (#39756)

main ← embed-full-app-signin-flow

drafted 04:08PM - 05 May 26 UTC

xfalcox

+677 -4

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.

複雑な変更ですが、より良いユーザーエクスペリエンスを実現できると期待しています。

Thiago_Mobilon · 2026 年 5 月 7 日午後 8:14

別の UI バグを見つけました:

投稿を編集するためにクリックすると、iframe の下部にコンテンツのない空白スペースが表示されます。「標準」フォームは開いたままですが、私のコメントは編集のためにその中に入っていません。また、スレッドの投稿数を表示する要素が左に移動します。

Falco · 2026 年 5 月 7 日午後 8:27

AIボット作曲者のバグに似ていますね、@keegan さん？

keegan · 2026 年 5 月 8 日午後 8:29

これは以下のコミットで解決されるはずです：

github.com/discourse/discourse

FEATURE: Add post editing support to docked composers (#39858)

committed 06:11PM - 08 May 26 UTC

keegangeorge

+277 -18

**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" />

Thiago_Mobilon · 2026 年 5 月 11 日午後 11:48

ちょうど統計を確認していたのですが、すべてが期待通りに機能しているか気になっています。「埋め込み表示」の項目で、1 日のページビュー数が 400 に満たないようです。

参考までに、フルアプリ埋め込みに切り替える前は、コミュニティ全体で 1 日あたり約 8,000 のページビューがありましたが、ローンチ以降その数は 5 倍以上に増加しました。

その差が「埋め込み表示」のセクションに反映されるべきではないでしょうか？

Falco · 2026 年 5 月 15 日午後 5:09

Thiago_Mobilon:

5. ログインの摩擦

現在のフローはコンバージョンを阻害する要因となっています。ユーザーがログインをクリックすると新しいタブが開き、ログインが完了すると、ユーザーはコミュニティのホームページに留まります。ブログ記事に戻ると、ユーザーがページ全体を手動でリフレッシュするまで、iframe はまだログアウト状態のまま表示されます。これは混乱を招くループであり、人々はコメントをする前に諦めて離脱してしまいます。

新しい埋め込み機能を有効にしてからは、新規登録数が2倍以上に増加しました。これは素晴らしいことです。しかし、エンゲージメント指標は全く変化していません。むしろ、DAU/MAU が低下しました。ログインしているユーザー数は増えているものの、彼らは交流していません。「1日あたりのアクティブユーザー数」「新規貢献者数」「投稿数」といった指標には、いかなる増加も見られません。

これは、人々が会話に参加したいと望んでいるものの、ログインのループに迷い込み、実際にコメントする前に投稿を離脱させていることを証明しています。

これは現在修正済みです。新しいログインフローを取得するには更新してください。

github.com/discourse/discourse

FEATURE: Add in-iframe sign-in flow for full app embed mode (#39756)

main ← embed-full-app-signin-flow

merged 04:07PM - 15 May 26 UTC

xfalcox

+644 -4

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.

Thiago_Mobilon · 2026 年 5 月 15 日午後 9:10

新しいネストされた返信機能は、埋め込みモードと互換性がないかもしれません。

テストのためにトピックでネストされた返信を有効にしたところ、コメントセクションが読み込まれる代わりに、iframe がポストの中にポストを読み込んでしまいました。

トピック		返信	表示
Embed Discourse comments on another website via Javascript Integrations embedding , how-to	127	303414	2026 年 6 月 2 日
Embed Discourse as a full comment system on your site Announcements embedding	24	1898	2026 年 6 月 2 日
Embed Discourse comments with on-page commenting? Feature	32	8057	2019 年 1 月 19 日
Should Discourse make an effort to become a viable comment platform? Community Building	62	5110	2026 年 3 月 25 日
Discourse Comments stuck on "Loading..." Support	22	2183	2024 年 9 月 18 日

Tecnoblog の Discourse コメントに関する体験

関連トピック