feat(super-editor): visual-only loading overlay toggle (IT-1365) - #3880
feat(super-editor): visual-only loading overlay toggle (IT-1365)#3880caio-pizzol wants to merge 2 commits into
Conversation
The built-in loading skeleton (EditorSkeleton) was gated solely on `editorReady`, so the only way to hide it was the internal `suppressSkeletonLoader` option, which forces `editorReady` true. That is too blunt: `editorReady` also gates the interactive chrome (context menu, link handler, table/image/textbox resize overlays), so suppressing the skeleton also arms that chrome before collaboration has synced. Introduce `showLoadingOverlay` (default true) as a strictly visual gate on EditorSkeleton. Readiness, collaboration timing and the existing chrome gates are untouched, so hiding the overlay cannot change editing behaviour. `suppressSkeletonLoader` keeps its broader legacy semantics. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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 reviewTo customize comments, go to the Qodo configuration screen, or learn more in the docs. Previous review resultsReview updated until commit 8eab403 Results up to commit d00e2af
|
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 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".
| </div> | ||
|
|
||
| <EditorSkeleton v-if="!editorReady" /> | ||
| <EditorSkeleton v-if="showLoadingOverlay" /> |
There was a problem hiding this comment.
When a collaborative document is initialized with showLoadingOverlay: false, this removes the only full-size, z-indexed element intercepting pointer input while editorReady is false (EditorSkeleton.vue renders .placeholder-editor across the container). Although the auxiliary chrome remains unmounted, the underlying editor can now receive clicks and edits before collaborationReady, changing editing behavior and potentially allowing mutations against incompletely synchronized state. Keep an invisible input barrier or otherwise disable editor interaction until readiness independently of the skeleton's visual visibility.
Useful? React with 👍 / 👎.
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
All reported issues were addressed across 2 files
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
The skeleton is not only a visual placeholder: `.placeholder-editor` is a full-surface, z-indexed element with no `pointer-events: none`, so it is also the only thing stopping pointer input from reaching the editable surface underneath while `editorReady` is false. The editor is mounted and `editable` defaults to true (Editor.ts), so unmounting the skeleton allowed edits against a document that had not finished synchronizing. Keep the element mounted whenever `editorReady` is false and let `showLoadingOverlay` control only whether it paints. Hiding the overlay is now genuinely visual-only. Also adds coverage through the collaboration init path (no file source, provider `synced`), which the previous tests never exercised because they always passed a file source. Reported by Codex and cubic on #3880. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
caio-pizzol
changed the title
1 participant
Stack 1/2 — internal only, no public API change. Public surface is #3881.
Problem
The built-in loading skeleton (
EditorSkeleton) was gated solely oneditorReady, so the only way to hide it was the internalsuppressSkeletonLoaderoption — which works by forcingeditorReady = true.That is too blunt.
editorReadyalso gates the interactive chrome:ContextMenu,LinkClickHandler,TableResizeOverlay,ImageResizeOverlay,TextboxResizeOverlay.Change
Adds an internal
showLoadingOverlayoption (defaulttrue) that controls only whether the placeholder paints..placeholder-editoris not just a visual: it is a full-surface, z-indexed element with nopointer-events: none, so it is also the only thing stopping pointer input reaching the editable surface underneath whileeditorReadyis false (the editor is mounted, andeditabledefaults totrueinEditor.ts:793). So the element stays mounted whenevereditorReadyis 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.
suppressSkeletonLoaderkeeps its broader legacy semantics and is unchanged.Review feedback addressed
8eab403. The first revision unmounted the barrier along with the visual.fileSource, so the collaboration init path was never exercised. Added a lane that mounts without a file source and drives providersynced.Tests
SuperEditor.loading-overlay.test.js— 10/10, split into barrier vs. paint assertions, plus the real collaboration path. ExistingSuperEditor.test.js36/36 unchanged.Refs IT-1365
🤖 Generated with Claude Code