Странно… вы вошли в систему? А ещё, пробовали ли вы провести пальцем в сторону, чтобы проверить, появляется ли горизонтальная полоса прокрутки?
Если да, то мне интересно, происходит ли это только с учетными записями администратора.
1 лайк
pmusaraj
28.Апрель.2026 18:51:10
44
Я не вошел в систему, я пробовал свайпать влево-вправо.
Возможно, это происходит только с администраторами. Я не вижу воспроизведения с обычным пользователем в эмуляторе Chrome для мобильных устройств.
На самом деле: я могу воспроизвести это как администратор на нашем собственном блоге.
2 лайка
pmusaraj
28.Апрель.2026 19:04:07
45
4 лайка
Отлично, спасибо! @pmusaraj
4 лайка
Thiago_Mobilon:
Текущий процесс немного убивает конверсию: пользователь нажимает «Войти» → открывается новая вкладка → происходит вход → пользователь оказывается на главной странице сообщества. Возвращаясь к записи в блоге, пользователь видит, что iframe всё ещё показывает статус «не авторизован», пока он вручную не обновит всю страницу. Это запутанный цикл, из-за которого люди сдаются и уходят, не оставив комментария.
Просто небольшая заметка: хотя этот процесс был исправлен для Google One Tap, он всё ещё ведёт себя таким образом при использовании стандартного входа в Discourse.
1 лайк
Falco
06.Май.2026 15:08:25
48
Мы работаем над улучшением этого процесса.
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.
Это сложное изменение, но мы надеемся, что сможем улучшить пользовательский опыт.
6 лайков
Я нашел еще одну ошибку в интерфейсе:
Когда я нажимаю, чтобы отредактировать свой пост, внизу iframe появляется пустое пространство без контента. Форма «standard» остается открытой, но мой комментарий не находится внутри нее для редактирования. Кроме того, элемент, показывающий количество постов в теме, смещается влево.
1 лайк
Falco
07.Май.2026 20:27:44
50
Звучит как ошибка в AI Bot-компоновщике, верно, @keegan ?
1 лайк
keegan
08.Май.2026 20:29:15
52
Thiago_Mobilon:
Когда я нажимаю, чтобы отредактировать свой пост, внизу iframe появляется пустое место без содержимого. Форма «standard» остаётся открытой, но мой комментарий находится не внутри неё для редактирования. Также элемент, отображающий количество постов в теме, сдвигается влево.
Это должно быть теперь исправлено с помощью:
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 лайков
Я только что просматривал статистику и задумался, всё ли работает как положено. В разделе «Встроенные просмотры» (Embedded Views) я вижу менее 400 ежедневных просмотров.
Для контекста: ранее всё сообщество получало около 8 тыс. просмотров в день, прежде чем мы перешли на полное встраивание приложения, — и с тех пор, как мы запустились, эта цифра выросла более чем в 5 раз.
Разве эта разница не должна отражаться в разделе «Встроенные просмотры»?
1 лайк
Falco
15.Май.2026 17:09:29
55
Thiago_Mobilon:
5. Трудности с входом в систему Текущий процесс немного убивает конверсию: пользователь нажимает «Войти» → открывается новая вкладка → происходит вход → пользователь оказывается на главной странице сообщества. Возвращаясь к записи блога, пользователь видит, что в iframe он всё ещё не вошёл в систему, пока не обновит всю страницу вручную. Это запутанный цикл, из-за которого люди сдаются и уходят, так и не оставив комментарий.
После активации новой вставки количество ежедневных регистраций более чем удвоилось , что отлично. Однако наши показатели вовлечённости остались на прежнем уровне. Более того, наш DAU/MAU упал – у нас больше пользователей, вошедших в систему, но они не взаимодействуют с контентом. Показатели вроде «Ежедневно активных пользователей», «Новых участников» и «Публикаций» не показали никакого роста.
Это доказывает, что люди хотят присоединиться к обсуждению, но они теряются в цикле входа в систему и покидают запись, так и не оставив комментарий.
Это теперь исправлено, пожалуйста, обновитесь, чтобы получить новый процесс входа в систему.
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 лайка
Кажется, новая функция вложенных ответов может быть несовместима с режимом Embed.
Я включил вложенные ответы на одной из тем, чтобы проверить, и вместо загрузки раздела комментариев iframe загрузил пост внутри поста.
1 лайк
Плагин рекламы также вставляет объявления в встроенную (embed) версию, что ломает верстку.
Полагаю, мы можем оставить опцию «внизу поста» (реклама, появляющаяся между постами), поскольку её формат хорошо подходит для встроенной версии (обычно это средний прямоугольник: 300x250).
Однако остальные места для рекламы не имеют смысла во встроенной версии, поэтому было бы здорово их убрать.
1 лайк
Я настроил слот «после сообщения», чтобы посмотреть, как он будет выглядеть во встраиваемом блоке, и он создал горизонтальную полосу прокрутки в настольной версии — даже несмотря на то, что я включил только размеры, которые намного меньше ширины встраиваемого блока.
Пока я этим занимаюсь, я также заметил, что на мобильных устройствах правый отступ сообщений шире левого (я не думаю, что это связано с рекламой).
