Overview - Ghost

Ghost

7 days30 days

Latest CI Pipeline Executions

Fuzzy

Succeeded
29176
e250faa4 Fixed the inert background-lock never actually activating ref https://linear.app/ghost/issue/NY-1394/ - while responding to a CodeRabbit review comment on the previous commit, found that the effect making the background admin UI inert while the email editor is open was a silent no-op: dialogContentRef was a plain useRef, but Radix's Portal primitive renders null on its first pass and only mounts the real DOM node one render later (via its own useLayoutEffect, an SSR-safety trick since document isn't available server-side) — so dialogContentRef.current was still null by the time our effect ran, it bailed out immediately, and with an empty dependency array it never got a second chance - verified via devtools: document.querySelectorAll('[inert]') returned nothing before this fix, meaning the background was fully focusable/clickable the entire time the modal was open - fixed by tracking the node as state via a callback ref instead of a plain ref, so the effect re-runs once Radix actually attaches it - this also let us properly re-test CodeRabbit's suggestion of adding a MutationObserver to catch late-mounting body children: with the inert-lock actually working, that suggestion does break the stacked discard-confirm AlertDialog, confirming it shouldn't be applied
by Troy Ciesco
Succeeded
29176
0d0dab1c Fixed the inert background-lock never actually activating ref https://linear.app/ghost/issue/NY-1394/ - while responding to a CodeRabbit review comment on the previous commit, found that the effect making the background admin UI inert while the email editor is open was a silent no-op: dialogContentRef was a plain useRef, but Radix's Portal primitive renders null on its first pass and only mounts the real DOM node one render later (via its own useLayoutEffect, an SSR-safety trick since document isn't available server-side) — so dialogContentRef.current was still null by the time our effect ran, it bailed out immediately, and with an empty dependency array it never got a second chance - verified via devtools: document.querySelectorAll('[inert]') returned nothing before this fix, meaning the background was fully focusable/clickable the entire time the modal was open - fixed by tracking the node as state via a callback ref instead of a plain ref, so the effect re-runs once Radix actually attaches it - this also let us properly re-test CodeRabbit's suggestion of adding a MutationObserver to catch late-mounting body children: with the inert-lock actually working, that suggestion does break the stacked discard-confirm AlertDialog, confirming it shouldn't be applied
by Troy Ciesco
Succeeded
29176
f74bed9c Fixed the inert background-lock never actually activating ref https://linear.app/ghost/issue/NY-1394/ - while responding to a CodeRabbit review comment on the previous commit, found that the effect making the background admin UI inert while the email editor is open was a silent no-op: dialogContentRef was a plain useRef, but Radix's Portal primitive renders null on its first pass and only mounts the real DOM node one render later (via its own useLayoutEffect, an SSR-safety trick since document isn't available server-side) — so dialogContentRef.current was still null by the time our effect ran, it bailed out immediately, and with an empty dependency array it never got a second chance - verified via devtools: document.querySelectorAll('[inert]') returned nothing before this fix, meaning the background was fully focusable/clickable the entire time the modal was open - fixed by tracking the node as state via a callback ref instead of a plain ref, so the effect re-runs once Radix actually attaches it - this also let us properly re-test CodeRabbit's suggestion of adding a MutationObserver to catch late-mounting body children: with the inert-lock actually working, that suggestion does break the stacked discard-confirm AlertDialog, confirming it shouldn't be applied
by Troy Ciesco
Succeeded
29176
50cbe85a 🐛 Fixed link selection in automations email editor ref https://linear.app/ghost/issue/NY-1394/ - Koenig portals its link input/toolbar to document.body, but the automations email modal's Radix dialog is modal, so its focus trap couldn't contain those portals — clicks and focus never reliably reached them - attempted a Koenig-side fix (render portals into a container inside the dialog instead), but that surfaced a new focus fight between Radix's trap and Lexical's own focus handling - fixed in Ghost instead: the dialog is non-modal, and the rest of the admin UI is made inert while it's open, so nothing outside the editor can steal focus/clicks and Koenig's body-level portals work fine - inert is also more robust for accessibility than a JS focus trap — it's natively enforced by the browser, so background content is reliably unreachable by keyboard and screen readers regardless of where Koenig portals its UI
by Troy Ciesco