docs/slate-issues/open-issues-dossiers/5558-5480.md
These dossiers cover issues #5558 through #5480 from the pilot set. Use the top-level index for the range map and the ledger for the canonical structured cache.
I think we will need Operation.isInsertNodeOperation, Operation.isMergeNodeOperation,...etcjiawei686feature0Small but legitimate TypeScript/API ergonomics request. Operation.isNodeOperation is too coarse if you want operation-specific narrowing in custom-op-heavy code.
No follow-up yet. The ask is straightforward: either expose finer-grained type guards or accept that consumers will keep reimplementing them.
Strong enough.
Acceptable.
Valid.
Keep this small. It is API polish, not evidence that the whole operation model is broken.
v2-roadmap
State clearly whether Slate wants first-class operation-specific guards or whether this stays consumer-land helper code.
Indirect.
to wrong for later siblings?beornbug2Real transform-semantics issue. moveNodes becomes hard to reason about when multiple matched siblings are moved to a later sibling path.
The follow-up comment makes the real pain explicit: the current one-by-one move behavior is technically explainable, but semantically awful for multiselect drag/drop.
Strong.
Poor.
Valid.
Do not collapse this into generic drag-and-drop noise. It is really about path semantics for grouped moves.
keep-open
The useful maintainer reply is to decide whether to is defined against the pre-operation tree or the sequential intermediate states, then lock that down with tests.
Direct.
Inconsistent Firefox selection with rowspan in td elementnlulicbug, ⚑ cross platform0Probably real browser-selection weirdness, but it lives inside a custom table plugin with rowspan, which is not a normal Slate-owned surface.
No maintainer follow-up yet. The repro is solid, but the ownership boundary is not.
Strong.
Poor.
Unclear.
Do not let this inflate core table architecture pressure. It is a custom table/runtime boundary problem first.
ask-for-scope-clarification
Ask whether there is a reduced repro without custom rowspan table logic before treating it as Slate-owned.
Indirect.
When rendering elements using components encapsulated with Web Components, the selection is abnormalZhang-Wei-666bug0Selection breaks when content is rendered through Web Components. That is not surprising; encapsulated DOM boundaries are hostile to Slate’s selection mapping.
No comments. The repro is visual only, and the report never narrows the ownership question beyond “Web Components break selection.”
Acceptable.
Poor.
Likely invalid.
This is interesting for future renderer portability, but it is not a clean current Slate contract bug.
close-invalid
State plainly that Web Component encapsulation is outside Slate’s supported DOM assumptions.
Indirect.
Editor.start / Editor.end broke when migrating from slate 0.93.0 -> 0.94.0gajusbug1This is not an engine regression. The issue body calls Editor.start(editor) without the root path, and the comment gives the correct call immediately: Editor.start(editor, []).
The single comment effectively resolves the report.
Strong enough.
Strong.
Invalid.
Treat this as docs or migration confusion, not a live core bug.
close-invalid
Point at the root-path API contract and close it.
None.
Slate editor scrolls on focus.shashtagimprovement3Could be a real focus/scroll interaction, but the report is muddy. The original case is user code selecting the end on focus, and the later comment broadens the symptom without a fresh repro.
Comments prove there is at least one workaround (preventDefault on focus), but they do not establish a stable current-Slate bug shape.
Weak.
Acceptable.
Unclear.
Keep it de-weighted until someone posts a cleaner repro that separates consumer focus logic from Slate scroll behavior.
ask-for-repro
Ask for a minimal repro that does not rely on app-specific whiteboard focus wiring.
Indirect.
Input field of the Editor doesn't accept input when programatically focused + there are multiple Editor componentsTeinovicbug0This looks like consumer focus misuse, not a proven Slate bug. The issue focuses a raw DOM node with .focus() instead of going through Slate’s focus utilities, and never ships a repro.
No follow-up, no sandbox, no maintainer context.
Weak.
Acceptable.
Likely invalid.
Do not let “multiple editors” alone push this into the shared-identity cluster. The real seam here is raw DOM focus.
share-status
Point users toward Slate-owned focus APIs and ask for a reduced repro if the problem still exists with those.
Indirect.
Is there any way to achieve collaborate editing without yjs ?jiawei686feature0Clean collaboration feature request. The ask is not “support Yjs better”; it is “can Slate operations be the collaboration primitive directly?”
No comments, but the issue body is already sharp enough to matter.
Strong enough.
None.
Valid.
This should feed collaboration requirements, not get buried as generic feature chatter.
v2-roadmap
Reply with the current status honestly: operations are the right primitive direction, but the repo does not ship a first-party OT/collab layer today.
Direct.
selection anchor jump issuedingyu-zhangbug, ⚑ cross platform0Real selection-gesture instability report. The anchor jumps during mouse drag after a triple-click block selection.
No extra comments, but the repro uses the official richtext example, which makes it more credible than random app code.
Strong.
Poor.
Likely valid.
Keep it with gesture-selection bugs, not generic selection complaints.
keep-open
The useful reply is to confirm whether this is Chrome-only block-selection drift and ask for a reduced browser-only diagnosis if needed.
Indirect.
Down arrow doesn't update selection even if cursor movesmartinhonzabug0Potentially real, but the contract is muddy. The report cares about previous-character inference around soft breaks, not just cursor motion itself.
No comments yet. The sandbox is useful, but the issue still mixes visual cursor movement with model-position expectations.
Acceptable.
Poor.
Unclear.
Worth keeping around, but low-confidence until someone states the expected model position more precisely.
ask-for-scope-clarification
Ask whether the bug claim is about actual selection points or only about deriving “line” state from characters around soft breaks.
Indirect.
Node.common()ch1ll0ut1improvement0Good docs issue. The current description of Node.common blurs the “common ancestor” case with the special-case same-text-node return.
No comments needed. The report is already precise.
Strong enough.
Strong.
Valid.
Pure docs cleanup. Do not overcomplicate it.
keep-open
Reply with the intended semantics and tighten the docs wording.
None.
Undo/Redo All maylortaylorimprovement1Legitimate history API request, and the comment immediately surfaces the real design constraint: collaboration makes “undo all” semantics messy fast.
The lone reply is valuable because it converts a seemingly simple feature request into a real history/collaboration design question.
Strong enough.
Acceptable.
Valid.
Good roadmap input. Not a current bug.
v2-roadmap
The right reply is to frame this as semantics-first, not implementation-easy.
Direct.
use with mobx-react-lite errorkringt06bug2Strong slate-react runtime smell. Parent observer rerenders appear to desynchronize DOM and Slate points unless the editor subtree is memoized away from the reactive parent.
The follow-up comment is the useful part: wrapping the editing component in memo stabilizes it again, which points straight at rerender pressure and stale DOM-point mapping.
Acceptable.
Acceptable.
Likely valid.
Keep it in the React runtime cluster, not generic MobX support noise.
keep-open
Reply should ask for a reduced repro, but the memo workaround already says enough about where to look.
Direct.
OmitFirstArg prop breaks typing.asizerbug0Clear TypeScript regression. Overriding any BaseEditor member that uses OmitFirstArg collapses the editor type to any.
No comments needed; the repro is already strong and specific.
Strong.
Poor.
Valid.
This is a real typing seam, not docs confusion.
keep-open
The best maintainer reply is to confirm the regression and point at a type-test PR seam.
Direct.
Update Stale Dependenciesdylansimprovement3Maintainer-authored repo maintenance issue. Useful for roadmap context, but not architecture signal for Slate v2.
The comments are useful process signal: Dependabot would create noise before the dependency baseline and test debt are fixed.
Strong enough.
Acceptable.
Valid.
Do not let repo maintenance issues distort runtime architecture priorities.
keep-open
No reply needed beyond status if this ever gets revisited.
None.
Cursor Skip Issue with Text Node Paddingflashthemanbug0This is a rendering/DOM misuse seam. Padding individual text leaves changes the DOM selection geometry enough to make cursor navigation skip positions.
No comments, but the repro is already specific enough to blame the rendered DOM shape rather than Slate’s model.
Strong.
Acceptable.
Likely invalid.
This belongs with custom render DOM interference, not core selection architecture.
close-invalid
Point users toward wrapping/styling higher-level containers instead of altering the leaf text boxes themselves.
None.
The first letter is typing twice on Androiddudtjr913bug, ⚑ cross platform, android12Major Android IME thread. The first composed character is duplicated, and the comments dig all the way into missing selection updates inside the Android input manager.
This thread is high-value. Multiple reporters confirm the bug across Korean, Chinese, Japanese, and even plain English composition, and the deeper comments narrow it to Android input manager selection syncing.
Strong.
Poor.
Valid.
This is a core mobile input cluster issue, not one-off Korean IME noise.
keep-open
The useful reply is not “any update?”; it is to capture the narrowed AndroidInputManager seam and point future fixes there.
Direct.
PropsMerge type is invalid.NikitaITnone1Good TypeScript issue. PropsMerge is typed as object-level merge, but setNodes actually invokes it per property value.
The later comment sharpens the mismatch and proposes the right direction for the generic shape.
Strong.
Poor.
Valid.
This is a real typing contract mismatch, not docs confusion.
keep-open
Reply should point at a type-test seam and the per-key invocation reality.
Direct.
Missing of value={value} and I am out of ideas PLS HELP!!Alllexklarimprovement2Real API ergonomics pain, not a bug. Users want to replace editor content programmatically without faking a controlled value model or triggering onChange feedback loops.
The later “same problem” comments show this did not die as one-off confusion.
Strong enough.
Poor.
Valid.
This should inform runtime/API design, not get treated as a support-thread annoyance.
v2-roadmap
Reply should explain the current uncontrolled model plainly and point at the least-awful update pattern, while acknowledging the ergonomics gap.
Direct.
createEditor returns Editor, but the returned type is really just BaseEditor => breaks type checking of pluginsbeornbug0Strong type-system design complaint. createEditor returning the fully-augmented Editor type hides plugin-order mistakes that should fail at compile time.
No comments, but the report is well-argued and specific.
Strong.
Acceptable.
Valid.
This is not just typing polish. It is about whether plugin composition can be expressed honestly in the type system.
v2-roadmap
The right reply is to say whether Slate intentionally chose global CustomTypes over plugin-order type safety, or whether this is v2 material.
Direct.
backspace bug on Google Chrome (not all chromium)CarlKelThasbug, ⚑ cross platform0Likely real caret-restoration issue in Chrome. Delete a character, type it back, and the caret lands behind it.
No comments and no sandbox, so confidence is not perfect, but the behavior report is concrete.
Acceptable.
Poor.
Likely valid.
Keep it with browser caret-restoration bugs, not IME-specific composition issues.
keep-open
Ask for a reduced repro if someone wants to actually fix it, but the symptom itself is clear.
Indirect.
Unable to type Malayalamzcraberbug0Legit input-method compatibility issue. Using Keyman’s Malayalam keyboard drops letters and corrupts the composed output.
No comments, but the repro path is concrete and uses the public demo.
Strong.
Poor.
Likely valid.
Keep this with external IME/input-method support, not generic Android composition bugs.
keep-open
Reply should ask whether the behavior still reproduces on current versions, but the class of bug is clear.
Direct.
Slate-React team needs to learn semantic versioning!heidi-derekimprovement2This is release-process feedback, not a runtime issue. The maintainer reply already explains the major-zero semver position and monorepo version skipping.
The thread is effectively resolved in comments, and it cross-links to the dependency/test modernization work in #5507.
Strong enough.
Acceptable.
Stale candidate.
Do not let this weigh on v2 architecture. It is release-process feedback with an in-thread answer.
close-stale
Point at the existing maintainer explanation and close it if someone triages stale process issues.
None.
Placeholder text is partially selectable on IOSjosephmrbug, ⚑ cross platform0Clean iOS placeholder bug. Placeholder text can be partially selected even though it should behave like non-content decoration.
No comments needed. The issue reproduces on the official examples.
Strong.
Poor.
Valid.
Good DOM/selection seam. Keep it out of generic placeholder chatter.
keep-open
A good reply would confirm whether the placeholder is being exposed as real selectable text in iOS selection APIs.
Indirect.
Spellcheck - fixing one issue clears otherslandoGriffin1bug2Originally a real browser integration problem: accepting one spellcheck suggestion cleared the others. The thread now says Chromium fixed it and the behavior looks resolved on current Chrome/Edge.
This is exactly why comments matter. Without them, it looks like a current Slate bug. With them, it is mostly stale upstream browser fallout.
Strong enough.
Acceptable.
Stale candidate.
Do not keep this hot in the architecture set. It should probably be closed as resolved upstream.
close-stale
Point at the Chromium bug and ask for retest only if someone can still reproduce it on current stable builds.
None.
Not a direct test candidate.