Describe the bug
On Safari/WebKit browsers, TinyMCE dialogs in the 2sxc WYSIWYG editor do not render as proper modal overlays.
Instead, the dialog appears to stay constrained inside the editor container / Shadow DOM context, so it does not escape the text editor area correctly. As a result, the dialog is clipped, not fully visible, and difficult or impossible to use.
This affects dialogs such as:
- Insert/Edit Link
- Insert/Edit Image
- Insert/Edit Media
In some cases, the URL-related control is also not usable or not visible, but the larger issue is that the dialog itself is rendered incorrectly on Safari.
To Reproduce
- Open a 2sxc edit form containing a WYSIWYG field in Safari
- Focus the TinyMCE editor
- Open a dialog such as:
- Insert/Edit Link
- Insert/Edit Image
- Insert/Edit Media
- Observe that the dialog does not behave like a normal modal overlay and remains visually constrained inside the editor area
Expected behavior
The TinyMCE dialog should render as a proper overlay/modal above the page UI, fully visible and usable.
Actual behavior
On Safari, the dialog appears trapped inside the editor container / Shadow DOM rendering context, causing clipping/layout problems and making it unusable.
Root cause analysis
2sxc wraps TinyMCE inside a Shadow DOM for CSS isolation.
TinyMCE 6.x does not officially support Shadow DOM. In 2sxc, TinyMCE is initialized with:
inline: truefixed_toolbar_container pointing to an element inside the Shadow DOM
When fixed_toolbar_container is present, TinyMCE renders UI in fixed container mode rather than split UI mode. This means dialogs are rendered inside the Shadow DOM/editor context instead of being rendered on document.body.
On Safari/WebKit, this causes the dialog to remain visually constrained inside the editor area instead of appearing as a normal modal overlay. Controls using TinyMCE/Alloy urlinput may also fail in this context.
Why ui_mode: "split" alone does not fix it
TinyMCE only uses split UI mode if no fixed container is active.
Relevant logic:
isSplitUiMode = (editor) =>
!useFixedContainer(editor) && "split" === editor.options.get("ui_mode");So if fixed_toolbar_container is present, ui_mode: "split" is ignored. That means the fixed toolbar container must be removed for split mode to take effect.
Working workaround
A Safari-only workaround was tested successfully by intercepting tinymce.init() and:
- removing
fixed_toolbar_container
- setting
ui_mode: "split"
- injecting the TinyMCE skin CSS globally into
<head>
This causes dialogs to render outside the Shadow DOM on document.body, where they behave like proper overlays and become usable again.
Side effects
On Safari only, the toolbar switches from fixed-container behavior to TinyMCE’s normal floating inline toolbar behavior.
Other chromium browsers remain unaffected.
Tested with
- 2sxc: 19.03.03
- TinyMCE: 6.8.5
- TinyMCE skin: 2sxc-tinymce-skin
- Safari on macOS and iOS
- Chromium Browsers unaffected
Suggested fix
Consider a Safari-specific fallback in 2sxc’s TinyMCE integration:
- disable
fixed_toolbar_container on Safari
- force
ui_mode: "split"
- ensure TinyMCE dialog skin CSS is available globally when dialogs render outside the Shadow DOM
Describe the bug
On Safari/WebKit browsers, TinyMCE dialogs in the 2sxc WYSIWYG editor do not render as proper modal overlays.
Instead, the dialog appears to stay constrained inside the editor container / Shadow DOM context, so it does not escape the text editor area correctly. As a result, the dialog is clipped, not fully visible, and difficult or impossible to use.
This affects dialogs such as:
In some cases, the URL-related control is also not usable or not visible, but the larger issue is that the dialog itself is rendered incorrectly on Safari.
To Reproduce
Expected behavior
The TinyMCE dialog should render as a proper overlay/modal above the page UI, fully visible and usable.
Actual behavior
On Safari, the dialog appears trapped inside the editor container / Shadow DOM rendering context, causing clipping/layout problems and making it unusable.
Root cause analysis
2sxc wraps TinyMCE inside a Shadow DOM for CSS isolation.
TinyMCE 6.x does not officially support Shadow DOM. In 2sxc, TinyMCE is initialized with:
inline: truefixed_toolbar_containerpointing to an element inside the Shadow DOMWhen
fixed_toolbar_containeris present, TinyMCE renders UI in fixed container mode rather than split UI mode. This means dialogs are rendered inside the Shadow DOM/editor context instead of being rendered ondocument.body.On Safari/WebKit, this causes the dialog to remain visually constrained inside the editor area instead of appearing as a normal modal overlay. Controls using TinyMCE/Alloy
urlinputmay also fail in this context.Why
ui_mode: "split"alone does not fix itTinyMCE only uses split UI mode if no fixed container is active.
Relevant logic:
So if
fixed_toolbar_containeris present,ui_mode: "split"is ignored. That means the fixed toolbar container must be removed for split mode to take effect.Working workaround
A Safari-only workaround was tested successfully by intercepting
tinymce.init()and:fixed_toolbar_containerui_mode: "split"<head>This causes dialogs to render outside the Shadow DOM on
document.body, where they behave like proper overlays and become usable again.Side effects
On Safari only, the toolbar switches from fixed-container behavior to TinyMCE’s normal floating inline toolbar behavior.
Other chromium browsers remain unaffected.
Tested with
Suggested fix
Consider a Safari-specific fallback in 2sxc’s TinyMCE integration:
fixed_toolbar_containeron Safariui_mode: "split"