هذا غريب… هل أنت مسجل الدخول؟ أيضًا، هل جربت التمرير جانبيًا لمعرفة ما إذا كانت شريط التمرير الأفقي يظهر؟
إذا كان الأمر كذلك، أتساءل عما إذا كان هذا يحدث فقط مع حسابات المشرفين.
إعجاب واحد (1)
pmusaraj
28 أبريل 2026، 6:51م
44
لم أقم بتسجيل الدخول، وقد حاولت التمرير يمينًا ويسارًا.
قد يكون هذا الأمر يحدث مع المشرفين. لا أرى أي إمكانية لإعادة إنتاج المشكلة مع مستخدم عادي في نافذة محاكي Chrome للجوال.
في الواقع: يمكنني إعادة إنتاج المشكلة كمسؤول على مدونتنا الخاصة.
إعجابَين (2)
pmusaraj
28 أبريل 2026، 7:04م
45
4 إعجابات
رائع، شكراً لك! @pmusaraj
4 إعجابات
ملاحظة سريعة: بينما تم إصلاح هذا المسار لـ Google One Tap، إلا أنه لا يزال يتصرف بهذه الطريقة عند استخدام تسجيل الدخول الأصلي في Discourse.
إعجاب واحد (1)
Falco
6 مايو 2026، 3:08م
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 بدون أي محتوى. يظل النموذج “قياسي” مفتوحًا، لكن تعليقى ليس بداخله للتعديل. بالإضافة إلى ذلك، فإن العنصر الذي يعرض عدد منشورات الموضوع يتحرك إلى اليسار.
إعجاب واحد (1)
Falco
7 مايو 2026، 8:27م
50
يبدو وكأنه خلل في مُلحّن الروبوت الذكي، أليس كذلك @keegan ؟
إعجاب واحد (1)
keegan
8 مايو 2026، 8:29م
52
يجب أن يتم حل هذه المشكلة الآن مع:
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 إعجابات
كنت أراجع الإحصائيات للتو وأتساءل عما إذا كان كل شيء يعمل كما هو متوقع. ألاحظ أن عدد المشاهدات اليومية أقل من 400 تحت قسم «المشاهدات المضمنة».
للتوضيح، كان المجتمع بأكمله يحصل على حوالي 8000 مشاهدة يومية قبل أن ننتقل إلى تضمين التطبيق الكامل — وقد ارتفع هذا الرقم بأكثر من خمسة أضعاف منذ أن بدأنا العمل.
ألا ينبغي أن يعكس هذا الفرق في قسم «المشاهدات المضمنة»؟
إعجاب واحد (1)
Falco
15 مايو 2026، 5:09م
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 إعجابات
أعتقد أن ميزة الردود المتداخلة الجديدة قد لا تكون متوافقة مع وضع التضمين.
قمت بتفعيل الردود المتداخلة على موضوع ما لأختبرها، وبدلاً من تحميل قسم التعليقات، انتهى الأمر بإطار iframe بتحميل المنشور داخل المنشور نفسه.
إعجاب واحد (1)
يقوم إضافة الإعلانات أيضًا بإدراج الإعلانات في النسخة المضمنة، مما يؤدي إلى تعطيل التخطيط.
أعتقد أننا يمكننا الإبقاء على خيار «أسفل المنشور» (الإعلانات التي تظهر بين المنشورات)، حيث يناسب تنسيقها النسخة المضمنة بشكل جيد (عادةً مستطيل متوسط: 300×250).
ومع ذلك، لا معنى لبقية أماكن الإعلانات في النسخة المضمنة، لذا سيكون من الرائع إزالتها.
إعجاب واحد (1)
قمتُ بتكوين خانة “أسفل المنشور” لأرى كيف ستبدو في التضمين، وقد أوجدت شريط تمرير أفقي في عرض سطح المكتب — على الرغم من أنني فعّلت أحجاماً أصغر بكثير من عرض التضمين.
وبما أنني على أي حال، لاحظتُ أيضاً أنه على الهاتف المحمول، الهامش الأيمن للمنشورات أوسع من الهامش الأيسر (لا أعتقد أنه مرتبط بالإعلانات).
