# Tecnoblog 使用 Discourse 评论系统的体验
**URL:** https://meta.discourse.org/t/tecnoblogs-experience-with-discourse-comments/400721
**Category:** Feature
**Tags:** embedding
**Created:** [2026年四月15日 18:15 UTC](https://meta.discourse.org/t/tecnoblogs-experience-with-discourse-comments/400721 "2026-04-15T18:15:07Z")
**Posts on this page:** 14
**Page:** 3
### Author:  [@Thiago\_Mobilon](https://meta.discourse.org/u/Thiago_Mobilon)
#### Post date: [2026年四月28日 18:49 UTC](https://meta.discourse.org/t/tecnoblogs-experience-with-discourse-comments/400721/43 "2026-04-28T18:49:36Z")
这很奇怪……你登录了吗？另外，你有没有尝试左右滑动，看看是否会出现水平滚动条？
如果是的话，我怀疑这可能是只有管理员账户才会遇到的问题。
---
### Author:  [@pmusaraj](https://meta.discourse.org/u/pmusaraj)
#### Post date: [2026年四月28日 18:51 UTC](https://meta.discourse.org/t/tecnoblogs-experience-with-discourse-comments/400721/44 "2026-04-28T18:51:10Z")
我未登录，尝试过左右滑动。
这可能是管理员特有的问题。在 Chrome 移动模拟器窗口中，我使用普通用户无法复现该问题。
实际上：我可以在我们自己的博客上以管理员身份复现该问题。
---
### Author:  [@pmusaraj](https://meta.discourse.org/u/pmusaraj)
#### Post date: [2026年四月28日 19:04 UTC](https://meta.discourse.org/t/tecnoblogs-experience-with-discourse-comments/400721/45 "2026-04-28T19:04:07Z")
此问题在以下 PR 合并后应得到修复：[UX: Ensure hidden upload field does not break layout - Pull Request #39619 - discourse/discourse - GitHub](https://github.com/discourse/discourse/pull/39619)
---
### Author:  [@Thiago\_Mobilon](https://meta.discourse.org/u/Thiago_Mobilon)
#### Post date: [2026年四月28日 19:05 UTC](https://meta.discourse.org/t/tecnoblogs-experience-with-discourse-comments/400721/46 "2026-04-28T19:05:32Z")
太好了，谢谢！@pmusaraj
---
### Author:  [@Thiago\_Mobilon](https://meta.discourse.org/u/Thiago_Mobilon)
#### Post date: [2026年五月6日 13:58 UTC](https://meta.discourse.org/t/tecnoblogs-experience-with-discourse-comments/400721/47 "2026-05-06T13:58:42Z")
> [@Thiago\_Mobilon](#):
>
> 目前的流程确实很劝退：用户点击登录 → 新标签页打开 → 完成登录 → 用户被留在社区首页。回到博客文章时，iframe 仍然显示未登录状态，直到用户手动刷新整个页面。这种令人困惑的循环会让用户在评论前就放弃并离开。
简单提醒一下：虽然这个流程在 Google One Tap 中已修复，但在使用 Discourse 原生登录时仍然表现如此。
---
### Author:  [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [2026年五月6日 15:08 UTC](https://meta.discourse.org/t/tecnoblogs-experience-with-discourse-comments/400721/48 "2026-05-06T15:08:25Z")
我们正在努力优化这一流程
>
>
> 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 \`\\` 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.
这是一个复杂的变更，但我们希望能带来更好的用户体验。
---
### Author:  [@Thiago\_Mobilon](https://meta.discourse.org/u/Thiago_Mobilon)
#### Post date: [2026年五月7日 20:14 UTC](https://meta.discourse.org/t/tecnoblogs-experience-with-discourse-comments/400721/49 "2026-05-07T20:14:52Z")
我发现了另一个 UI 错误：
当我点击编辑帖子时，iframe 底部出现了一个空白区域，里面没有任何内容。“标准”表单仍然处于打开状态，但我的评论不在其中，无法进行编辑。此外，显示帖子数量的元素向左移动了。
---
### Author:  [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [2026年五月7日 20:27 UTC](https://meta.discourse.org/t/tecnoblogs-experience-with-discourse-comments/400721/50 "2026-05-07T20:27:44Z")
听起来像是 AI Bot composer 的一个 bug 对吧 @keegan ？
---
### Author:  [@keegan](https://meta.discourse.org/u/keegan)
#### Post date: [2026年五月8日 20:29 UTC](https://meta.discourse.org/t/tecnoblogs-experience-with-discourse-comments/400721/52 "2026-05-08T20:29:15Z")
> [@Thiago\_Mobilon](#):
>
> 当我点击编辑帖子时，iframe 底部会出现一个没有内容的空白区域。“标准”表单保持打开状态，但我的评论不在其中供编辑。此外，显示帖子数量的元素向左移动了。
这应该已经通过以下链接解决了：
>
>
> \*\*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:
> \
### Author:  [@Thiago\_Mobilon](https://meta.discourse.org/u/Thiago_Mobilon)
#### Post date: [2026年五月11日 23:48 UTC](https://meta.discourse.org/t/tecnoblogs-experience-with-discourse-comments/400721/54 "2026-05-11T23:48:16Z")
> [@Falco](#):
>
> [FEATURE: Route full app embed pageviews into a dedicated `page_view_embed` counter - Pull Request #39535 - discourse/discourse - GitHub](https://github.com/discourse/discourse/pull/39535)
我刚才看了一下统计数据，不确定一切是否按预期正常运行。我在“嵌入视图”（Embedded Views）下看到的每日页面浏览量不到 400 次。
作为背景参考，在我们切换到完整应用嵌入之前，整个社区每天的页面浏览量约为 8,000 次——而自上线以来，这个数字已增长了 5 倍以上。
这个差异难道不应该反映在“嵌入视图”部分吗？
---
### Author:  [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [2026年五月15日 17:09 UTC](https://meta.discourse.org/t/tecnoblogs-experience-with-discourse-comments/400721/55 "2026-05-15T17:09:29Z")
> [@Thiago\_Mobilon](#):
>
> ### **5. 登录摩擦**
>
> 当前的流程有点像是转化率的杀手：用户点击登录 → 打开新标签页 → 完成登录 → 用户停留在社区主页。回到博客文章页面，iframe 仍然显示未登录状态，直到用户手动刷新整个页面。这是一个令人困惑的循环，导致人们在评论前放弃并离开。
>
> 自从启用新的嵌入功能后，我们的 **每日注册量翻了一番以上** ，这很好。然而，我们的参与度指标没有任何变化。事实上，我们的 **DAU/MAU 下降了** ——我们有更多登录用户，但他们并没有互动。像“每日活跃用户”、“新贡献者”和“发帖数”等指标都没有任何增长。
>
> 这证明人们_想要_参与讨论，但他们在登录循环中迷失了方向，在能够实际评论之前就放弃了帖子。
这个问题现在已经修复，请更新以获取新的登录流程。
>
>
> 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 \`\\` 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.
---
### Author:  [@Thiago\_Mobilon](https://meta.discourse.org/u/Thiago_Mobilon)
#### Post date: [2026年五月15日 21:10 UTC](https://meta.discourse.org/t/tecnoblogs-experience-with-discourse-comments/400721/56 "2026-05-15T21:10:54Z")
我认为新的嵌套回复功能可能与嵌入模式不兼容。
我启用了一个主题的嵌套回复功能进行测试，结果iframe没有加载评论部分，而是在帖子内部加载了帖子。
---
### Author:  [@Thiago\_Mobilon](https://meta.discourse.org/u/Thiago_Mobilon)
#### Post date: [2026年六月18日 23:14 UTC](https://meta.discourse.org/t/tecnoblogs-experience-with-discourse-comments/400721/57 "2026-06-18T23:14:52Z")
广告插件还会在嵌入版本中插入广告，这会导致布局错乱。
我认为我们可以保留“帖子底部”选项（即帖子之间出现的广告），因为其格式很适合嵌入场景（通常是中等矩形：300x250）。
不过，其他广告位在嵌入版本中并不合适，因此最好将其移除。
---
### Author:  [@Thiago\_Mobilon](https://meta.discourse.org/u/Thiago_Mobilon)
#### Post date: [2026年六月18日 23:59 UTC](https://meta.discourse.org/t/tecnoblogs-experience-with-discourse-comments/400721/58 "2026-06-18T23:59:15Z")
我配置了“帖子底部”插槽，以查看其在嵌入中的显示效果，结果在桌面视图中生成了水平滚动条——尽管我只启用了远小于嵌入宽度的尺寸。
顺便提一下，我还注意到在移动端，帖子的右边距比左边距更宽（我认为这与广告无关）。
> **[Amazon lança Alexa+ no Brasil, com nova voz e inteligência artificial •...](https://tecnoblog.net/noticias/alexa-do-brasil-ganha-nova-voz-e-fica-mais-inteligente/)**
>
> Empresa inicia acesso antecipado. Serviço está incluso na assinatura do Prime.
[上一頁](https://meta.discourse.org/t/tecnoblogs-experience-with-discourse-comments/400721.md?page=2)