docs/slate-issues/open-issues-dossiers/5760-5666.md
These dossiers cover issues #5760 through #5666 from the pilot set. Use the top-level index for the range map and the ledger for the canonical structured cache.
domRange.setStart being called with offset of 1 on a zero length text nodewdonov4nbug, ⚑ cross platform0This is a strong DOM-range mapping bug. The report points at a concrete mismatch between Slate's zero-width rendering assumption and what iOS actually renders.
No thread, but the body is already useful: exact code pointers, screenshots, and a plausible failure chain into toDOMRange.
Strong.
Poor.
Likely valid.
This is worth keeping in the DOM-bridge cluster. It is specific enough to act on.
keep-open
The next useful step is to confirm the exact DOM shape on current iOS and make toDOMRange resilient when the zero-width sentinel is not actually present.
Direct.
Ready with minor setup.
Potential security issues in GitHub Actions workflowsgwahl-RUnone0This is not a product/runtime issue. It is a repo-security disclosure request.
No thread.
Not applicable.
Not applicable.
Valid, but repo-only.
Do not let this leak into Slate v2 architecture clustering.
redirect-private-report
Point the reporter to the private security reporting channel and move it off the public issue tracker.
None.
Not a test candidate.
Markdown does not interpret combo styles correctlyvinicciusbug0This looks like a real bug in the markdown preview example or its parser assumptions, not a vague formatting complaint.
No thread, but the body gives exact input, expected output, and a public reproduction surface.
Strong.
None.
Likely valid.
Keep it in the example/parser bucket. This should not be mistaken for a core data-model problem.
keep-open
Decide whether the markdown preview example is supposed to approximate CommonMark more closely or whether its current parser intentionally stops short.
None.
Ready now.
Shadow DOM - Drag-and-drop text throws errorHentuloobug2This is a strong runtime bug on an official example. Shadow DOM drag-and-drop currently falls into DOM-point resolution failure.
The thread is useful. One comment proposes a shadow-root-aware caret-position fix, and another adds an important Chrome version constraint.
Strong.
Poor.
Valid.
Keep it in the DOM-selection cluster. It is a good example of host-environment support gaps, not user confusion.
keep-open
Verify the fix surface against current Chrome shadow-root selection APIs, then decide whether Slate should harden this path or explicitly degrade.
Direct.
Ready with minor setup.
Wrap children of root not workingrazkolfbug1This is not really a bug. It is an API expectation mismatch around what at: [] means for wrapNodes.
The single reply already answers it cleanly with the right match usage.
Strong.
Strong.
Invalid as a current Slate bug.
This is a docs/semantics clarification case, not an architecture problem.
close-invalid
Point to root-path semantics and, if needed, add one doc example for wrapping direct children instead of the editor object itself.
None.
Not a test candidate.
How to implement transition animations for moving slate nodes?anonymousuaimprovement0This is a support/design question about UI animation, not a Slate engine issue.
No thread.
Not applicable.
Acceptable.
Likely invalid for the core issue tracker.
Do not let this inflate the framework roadmap.
close-invalid
Redirect toward consumer-side animation strategies. Slate should not own transition orchestration.
None.
Not a test candidate.
Text.equals extension/changenabbydudeimprovement1This is a legitimate low-level API ergonomics request. The current Text.equals surface is too rigid if consumers carry stable IDs on text nodes.
The one comment is useful: it shows that the naive external-omit workaround is awkward enough to push people toward ts-ignore.
Strong enough.
Acceptable, but ugly.
Valid.
Not urgent, but it is real and specific.
v2-roadmap
Decide whether the right abstraction is a lower-level equality helper or a narrow extension point on Text.equals.
Indirect.
Ready now.
Bntiendzvaybug0Spam. Nothing useful here.
No thread.
None.
Not applicable.
Invalid.
This should be closed, not analyzed.
close-invalid
None.
None.
Not a test candidate.
"Cannot resolve a Slate point from DOM point"ehsankh1370bug3This is one of the stronger iOS empty-editor / backspace issues in the set. It is not just “mobile is weird”; it captures a specific failure and non-recovery path.
The comments materially improve the issue. They add DOM-level evidence, a stronger local repro path, a Plate confirmation, and a related issue pointer.
The thread links to Plate discussion #3584 and Issue #5762.
Strong.
Poor.
Valid.
This should stay in the mobile empty-state cluster. It is stronger than the weaker duplicates orbiting it.
keep-open
The next useful step is to isolate which part is actually failing first: DOM restoration after empty-delete, point recovery, or selection sync after the DOM collapses.
Direct.
Ready with minor setup.
Load different contentWindRunnerMaxfeature1This is a real DX/API gap around replacing the entire document. The current answer is a pile of transforms or direct children replacement, which is not elegant.
The one reply just points to a Plate utility, which is basically confirmation that the gap is currently externalized.
Strong enough.
Acceptable.
Valid.
Keep it in the API ergonomics pile, not the bug pile.
v2-roadmap
Decide whether Slate wants a first-class content-replacement command or whether direct value replacement remains the intended pattern.
Direct.
Not a test candidate.
useSlate hook holds old editor instance after recreating a new oneskorenbbug3This is a strong slate-react runtime issue. Replacing the editor instance leaves hooks subscribed to stale context.
The thread is short but useful: it gives the current editor.children = ...; editor.onChange() workaround and another confirmation from a React Compiler use case.
Strong.
Acceptable, but awkward.
Valid.
Keep this high in the slate-react runtime bucket. It is a clean signal, not support noise.
keep-open
The real question is whether <Slate> should treat editor replacement as supported and update context, or whether editor identity is intentionally singleton-like.
Direct.
Ready now.
editor selection not change when selecting in a popup text boxscottlong1980bug, ⚑ cross platform0This reads like a selection-ownership misunderstanding. Selecting text in an external popup is not the same thing as changing the Slate editor selection.
No thread.
Strong enough.
Acceptable.
Likely invalid.
This should not enter the core bug cluster unless a narrower Slate-owned failure emerges.
close-invalid
Explain the distinction between preserved editor selection and focus/selection moving into external UI.
None.
Not a test candidate.
when i deleted all text, i cannot insert any textLuciferWZXbug, ⚑ cross platform2The original issue is weak, but the comments suggest it belongs to the same iOS empty-editor backspace cluster as the stronger reports.
The useful content is entirely in the comments. The body is basically empty, and the thread never reaches a clean repro.
Weak.
Poor.
Duplicate candidate.
This should probably collapse into a stronger tracked issue instead of living on its own.
mark-duplicate
Point to the stronger empty-editor iOS issue and ask the reporter to verify whether it is the same failure mode.
Indirect.
Blocked on repro.
Proposal: Improve the reliability of ReactEditor.findPath without compromising its efficiency12joanimprovement2This is one of the better runtime architecture proposals in the set. It names concrete weak-map failure modes instead of just complaining that findPath is flaky.
The thread mostly confirms the current workarounds and the awkward dependence on React render timing.
Strong enough.
Acceptable.
Valid.
Keep it near the top of the React/runtime cluster. It is a design pressure issue, not random DX noise.
v2-roadmap
Separate the problem into two decisions: whether core should own a traversal-based path finder, and whether ReactEditor.findPath should stop throwing on transient weak-map staleness.
Direct.
Ready now.
Legacy Chrome will be judged to support InputEventhujh-101bug, ⚑ cross platform0This is a narrow legacy-environment feature-detection complaint.
No thread.
Strong enough for the narrow case.
Acceptable.
Likely invalid under current support assumptions.
This should not influence the main runtime roadmap unless Slate still intends to care about legacy Chrome plus polyfill-heavy environments.
close-invalid
Clarify the support boundary first. Do not patch edge detection for dead environments by reflex.
None.
Not a test candidate.
Add [Symbol.dispose] support for ref typesyf-yangfeature2This is a sensible API ergonomics request. It is small, additive, and tied to a real language feature instead of random sugar.
The thread is light, but it does clarify that this is about standard-compatible disposal ergonomics, not a bespoke lifecycle invention.
The thread points at Issue #5726.
Strong enough.
Acceptable.
Valid.
Low urgency, but legitimate.
v2-roadmap
Decide whether Slate wants ref cleanup to stay explicit-only or whether disposable refs are worth the tiny surface-area increase.
Indirect.
Ready now.
Double-clicking a word before an inline element and deleting crashes Slate (Windows/Chrome)tamsingreenbug, ⚑ cross platform1This is a strong inline-boundary selection crash on the official examples, not just an app-specific edge case.
The only comment is useful: it suggests the old Chromium bugfix helper might be the actual culprit, which narrows the fix surface.
Strong.
Acceptable.
Likely valid.
Keep it in the inline-boundary selection bucket until someone verifies it is already gone on current examples.
keep-open
Verify this on current example code and decide whether the fix is “remove obsolete DOM hack” or “harden selection translation near inline boundaries.”
Direct.
Ready now.
Triple-click the mouse to select upward, the selection disappears.yyhappbug0This looks like a real selection-directionality bug, but the report is thin.
No thread.
Moderate.
None.
Likely valid.
It should stay in the selection cluster, but it needs a sharper anchor/focus expectation before it can drive design.
keep-open
Ask for a more explicit anchor/focus narrative or encode the gesture in a browser test directly.
Direct.
Ready with minor setup.
Transforms.setNodes` unexpected behavior of `childrenelectroluxcodebug5This is a clean example of current Slate contract versus user expectation. setNodes is not a deep structural replacement API, and the thread eventually says exactly that.
The comments are the real value. They explain why diff-based deep replacement is intentionally out of core and why this request is unsupported by design.
Strong.
Acceptable.
Likely invalid for current Slate, but still useful as v2 design pressure.
Do not count this as a current bug. Count it as a recurring “users want node replacement semantics” signal.
close-invalid
Point users toward explicit remove/insert or diff-based transforms instead of pretending setNodes is meant to rewrite subtrees.
Direct.
Not a test candidate.
SlateEditor.nodes match issueelectroluxcodebug0This is too vague to trust. It gestures at Editor.nodes traversal semantics, but it does not provide enough shape to know whether the bug is in Slate or the caller.
No thread.
Weak.
Unknown.
Unclear.
Needs a real repro before it should influence anything.
ask-for-repro
Ask for the exact document shape, match predicate, and expected yielded path.
Indirect.
Blocked on repro.
Keyboard hides when removing inline element (Chrome, Android)officialdakaribug, ⚑ cross platform, android0This is a strong Android inline-deletion bug. Removing the inline and trailing space kicks the keyboard out.
No thread, but the issue is already sharp: official example, clear platform, clear trigger.
Strong.
Poor.
Valid.
Keep this in the mobile inline-deletion cluster. It is not a vague “Android is broken” complaint.
keep-open
The next useful split is whether the keyboard hides because selection lands on a removed inline boundary or because the browser loses its editable target during the deletion sequence.
Direct.
Ready with minor setup.
How to get a "normally" working editor?ecosta1020improvement2This is basically a support/onboarding thread. It says more about expectation mismatch than about a concrete Slate defect.
The first reply is useful and answers the question. The second reply is user frustration and project abandonment, not technical signal.
Not applicable.
Strong.
Invalid as a bug.
Do not let generic support frustration bleed into the v2 requirements set.
close-invalid
If revisited at all, point to command overrides and event-handler docs. This is onboarding material.
None.
Not a test candidate.
event is not fired when deleting text or typing numbers in <Editable> componentkiryl-ivanoubug, ⚑ cross platform3This is a real API/runtime concern around event passthrough on <Editable>. It is not just one version regression.
The follow-up matters. It confirms the behavior across multiple Slate versions and platforms, which de-risks the “maybe this is one bad release” explanation.
Strong.
Poor.
Likely valid.
Keep this in the runtime adapter bucket. It is the kind of contract question users actually hit.
keep-open
Clarify whether Slate intends to preserve native input semantics on <Editable> or whether event normalization deliberately breaks parity.
Direct.
Ready with minor setup.
Mapping multiple slate editor, when deleting one of the array element the values are not correctly showsharshit-17bug0Classic React keyed-list misuse. This is not a Slate bug.
No thread.
Strong enough.
Strong.
Invalid.
Do not give this architectural weight. It is caused by key={index} and state retention.
close-invalid
Tell them to use stable keys and stop keying editors by array index.
None.
Not a test candidate.
Touch screen android TV and firefox gives multiple times occurring lettersdpranav007bug, ⚑ cross platform, android2Weird platform, real problem. This is another input-method bug where the first input and line-start behavior are clearly unstable.
The comments are helpful. They narrow the weirdness to letter keys, first input on an empty box, and cursor reversal after newline.
Strong.
Poor.
Likely valid.
Keep it in the input-method cluster, but do not collapse it too quickly into generic Android noise. The TV + Firefox combination may expose a distinct browser path.
keep-open
Split the problem into two assertions: repeated first-character insertion and reversed cursor progression after newline.
Direct.
Ready with minor setup.