ui: false does not suppress the new visible "edit-rejected" status banner (2.11.0) — English text painted over a non-English host's document

[Y-PLONI]

Summary

superdoc@2.11.0 added a visible status banner for rejected keyboard edits:

V2_EDIT_REJECTED_MESSAGE =
  "This edit couldn’t be completed. Adjust the selection and try again."

It is rendered by SuperDoc.vue inside .superdoc__layers, as
div.superdoc__mutation-status > p.superdoc__edit-rejected-status[data-superdoc-v2-edit-rejected],
with new CSS that gives it position: sticky; top: 12px over the document surface.

It renders even when the integration passes ui: false.

That is the problem. ui: false is documented as "SuperDoc renders no toolbar, dialog or popover — the host owns the entire UI". An application that opted out of SuperDoc's chrome, and that is not in English, now gets an English sentence painted over its own document surface, with no configuration option to translate or suppress it.

Why ui: false should exclude it

The banner is not a document artifact — it is product chrome. Every other piece of SuperDoc chrome honors ui: false. The equivalent notice in 2.10.0 was sd-visually-hidden (screen-reader only, [data-superdoc-v2-author-required]), so it was invisible and harmless to a host with its own UI. 2.11.0 promotes the new edit-rejected sibling to a visible element, and does not gate it.

Measured

Same integration, same key sequence, both packaged dist builds in headless Chrome, ui: false in both:

	2.10.0	2.11.0
.superdoc__mutation-status present in the DOM	no	yes
[data-superdoc-v2-edit-rejected] text after a rejected Backspace	(element absent)	This edit couldn’t be completed. Adjust the selection and try again.

Reproduce

1. new SuperDoc({ selector, document, ui: false, ... }), wait for onReady.
2. Click into the document body and trigger a keyboard delete that the shell rejects (Backspace / Delete / cut on a selection the mutation path refuses).
3. Read the DOM:

document.querySelector('[data-superdoc-v2-edit-rejected]')?.textContent
// 2.11.0 → "This edit couldn’t be completed. Adjust the selection and try again."
// 2.10.0 → undefined (no such element)

The English text is now visible on screen, on top of the host's own document view.

Expected

Any of these would resolve it, in order of preference:

1. ui: false suppresses the banner entirely. The rejection is already reported through onException (code: 'edit-rejected'), which is the correct channel for a host that owns its UI — it can render its own notice, in its own language.
2. A config option to override the string (the way FindReplace / PasswordPrompt surfaces already accept resolved texts), so it can be localized.
3. At minimum, a documented, stable way to opt out.

Right now the only workaround available to a non-English host is a CSS rule hiding .superdoc__mutation-status, which suppresses information the user arguably should get — just not in English.

Environment

• superdoc@2.11.0 (@superdoc/docx-engine@0.10.0), compared against superdoc@2.10.0 (0.9.0)
• Headless Chrome, packaged dist, ui: false, modules.surfaces.passwordPrompt: false
• Host application UI is Hebrew (RTL)

---

אנגלית אינה שפת האם שלי, אז נתתי ל-AI לנסח לי את הבעייה — the measurements and the reproduction are mine; the English wording is not.

[linear-code]

IT-1565

SD-4841

[vivienne-sd]

Hi @Y-PLONI ! Thanks for the detailed report and clear reproduction steps. We’ve reproduced this on our end: with ui: false, a rejected edit still displays SuperDoc’s built-in English status banner.

We’ve got the issue documented and in queue for the team to address. I’ll follow up here as soon as a fix is live.