feat(super-editor): visual-only loading overlay toggle (IT-1365)

[caio-pizzol]

Stack 1/2 — internal only, no public API change. Public surface is #3881.

Problem

The built-in loading skeleton (EditorSkeleton) was gated solely on editorReady, so the only way to hide it was the internal suppressSkeletonLoader option — which works by forcing editorReady = true.

That is too blunt. editorReady also gates the interactive chrome: ContextMenu, LinkClickHandler, TableResizeOverlay, ImageResizeOverlay, TextboxResizeOverlay.

Change

Adds an internal showLoadingOverlay option (default true) that controls only whether the placeholder paints.

.placeholder-editor is not just a visual: it is a full-surface, z-indexed element with no pointer-events: none, so it is also the only thing stopping pointer input reaching the editable surface underneath while editorReady is false (the editor is mounted, and editable defaults to true in Editor.ts:793). So the element stays mounted whenever editorReady is false and merely goes transparent when the overlay is off.

Result: hiding the overlay changes pixels and nothing else. Readiness, collaboration timing, the five chrome gates, and the interaction barrier are all untouched — a half-loaded document still cannot be edited.

suppressSkeletonLoader keeps its broader legacy semantics and is unchanged.

Review feedback addressed

• Codex + cubic (P2), interaction barrier: valid, confirmed in source, fixed in 8eab403. The first revision unmounted the barrier along with the visual.
• cubic (P3), test coverage: valid. Every test passed a fileSource, so the collaboration init path was never exercised. Added a lane that mounts without a file source and drives provider synced.

Tests

SuperEditor.loading-overlay.test.js — 10/10, split into barrier vs. paint assertions, plus the real collaboration path. Existing SuperEditor.test.js 36/36 unchanged.

Refs IT-1365

🤖 Generated with Claude Code

[linear-code]

IT-1365

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

---

Great, no issues found!

Qodo reviewed your code and found no material issues that require review

---

_{To customize comments, go to the Qodo configuration screen, or learn more in the docs.}

Previous review results

Review updated until commit 8eab403 🚀 Fast

Results up to commit d00e2af 🚀 Fast

No changes from previous review

Powered by Qodo

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: d00e2afe95

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[cubic-dev-ai]

All reported issues were addressed across 2 files

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[caio-pizzol]

Closing as superseded by superdoc/orbit#1474.

This targeted V1 (superdoc@1.x on docx-editor/main) and fixed the V1 EditorSkeleton. That was the wrong product: IT-1365 is a V2 blocker for Keyora, and V2 lives on superdoc/orbit branch v2 (superdoc@2.4.0-next.48), which has no super-editor package and no EditorSkeleton at all.

V2 has its own loading overlay with a progress percentage, which matches the reporter's description far better than the V1 skeleton did. It also explains the ticket's replaceFile claim, which is real on V2 (replacement resets the loading state and re-arms the overlay) and is not on V1.

The API intent and the test scenarios carried over; none of the V1 skeleton or interaction-barrier implementation did, because V2's architecture already prevents a partial first paint.