docs/slate-issues/open-issues-dossiers/4642-4542.md
Transforms.removeNodes sets selection to next line if next line is emptyricardobug0removeNodes can leave selection on the next empty line instead of the logical current insertion target.
The repro is clear and the intended consistency is easy to understand.
Strong enough.
Poor.
Valid.
Good current core test case.
keep-open
Keep it open and test the empty-next-line selection path.
Direct.
Ready now.
raitucarpbug4Node properties meant to be unique identity get cloned during splits, which makes normalize-time id assignment brittle.
The comments explain the real mechanism: split behavior copies element props before normalization ever runs.
Strong enough.
Poor.
Valid.
This is real identity pressure, but likely wants a better contract than a narrow bug patch.
v2-roadmap
Keep it on the roadmap as stable identity and split semantics work.
Direct.
Ready with minor setup.
Bellinebug, ⚑ cross platform1Safari can let users backspace the placeholder itself after clearing formatted content, leaving the editor unusable until reload.
The reporter also posted a workaround that clarifies this is happening below the normal Slate delete hooks.
Strong enough.
Acceptable.
Valid.
This is good selection/placeholder runtime debt, not just a browser quirk footnote.
keep-open
Keep it open under Safari placeholder/input behavior.
Direct.
Ready with minor setup.
jameshfisherbug8insertNodes(..., { select: true }) briefly regressed to place the cursor before the inserted node.
The thread quickly turned into a revert discussion, which makes this look more like resolved historical regression tracking than live debt.
Strong enough.
Acceptable.
Stale candidate.
Treat it as historical context unless it is still reproducible now.
close-stale
Close or fold into the linked regression thread.
Indirect.
Not a direct test candidate.
rmccuebug0Dragging a void to the top padding area can duplicate it instead of moving it, which smells like bad internal-vs-external drop detection.
The thread is short but the hypothesized boundary bug is plausible and the behavior is clear.
Weak.
Poor.
Valid.
This is worth keeping, but it still wants a tighter sandbox.
keep-open
Keep it open and ask for a minimal sandbox if the reporter resurfaces.
Direct.
Ready with minor setup.
echarlesimprovement7This is a maintenance/architecture issue about the AndroidEditable fork drifting from the default Editable and the cost of carrying two runtimes.
The comments are valuable because they explain why Android support is hard and why naive convergence is not enough.
Strong enough.
Poor.
Valid.
This belongs in runtime package architecture, not as a one-off bug.
v2-roadmap
Keep it on the runtime roadmap, especially if AndroidEditable remains distinct.
Indirect.
Not a direct test candidate.
jameshfisherfeature0The request is for an explicit point-normalization hook so apps can decide which cursor positions should be treated as equivalent.
This is strong architecture pressure built on multiple linked selection debates, not a random feature whim.
Strong enough.
Poor.
Valid.
This is v2-grade API design work, not a small patch.
v2-roadmap
Keep it on the selection API roadmap.
Direct.
Not a direct test candidate.
echarlesfeature1Custom paste pipelines still require copying too much built-in logic instead of extending smaller chunks cleanly.
The discussion is brief but precise, and it aligns with later runtime ownership pressure around copy/paste APIs.
Strong enough.
Poor.
Valid.
This belongs squarely in runtime extensibility planning.
v2-roadmap
Keep it on the roadmap as insertData/clipboard strategy work.
Direct.
Not a direct test candidate.
Ghost---Shadowbug39This is one of the clearest threads showing how painful uncontrolled-only editor state is for non-trivial React apps.
The thread is long, detailed, and full of real downstream pain, workarounds, and design disagreement.
Strong enough.
Poor.
Valid.
This is not background noise. It is one of the biggest slate-react contract pressure points in the whole corpus.
v2-roadmap
Keep it on the v2 roadmap, not in support limbo.
Direct.
Not a direct test candidate.
robin-macphersonbug, ⚑ cross platform, android8Android spellcheck corrections can move the cursor back to the corrected letter and insert the next space in the wrong place.
The comments are great context because they explain the likely compositionend/diff sequence behind the bug.
Strong enough.
Poor.
Valid.
This is exactly the kind of Android runtime behavior that needs explicit ownership.
keep-open
Keep it open and group it with Android spellcheck/autocorrect handling.
Direct.
Ready with minor setup.
ugrinovskyfeature2The built-in scroll behavior assumes the editor itself is the scroll container, which is too rigid for real layouts.
This is a clean API gap around scrolling customization rather than a deeper engine bug.
Strong enough.
Poor.
Valid.
Good runtime API-shape pressure, not a core model problem.
v2-roadmap
Keep it in slate-react scrolling API planning.
Indirect.
Not a direct test candidate.
jakedbug, ⚑ cross platform0Typing at the beginning of an inline can place text outside the inline in Chrome and Safari, even though programmatic insertText goes to the right spot.
The contrast between typed and programmatic insertion is useful signal that this is a runtime boundary bug.
Strong enough.
Poor.
Valid.
Keep it in the inline-boundary runtime cluster.
keep-open
Keep it open and test both native typing and programmatic insertion behavior.
Direct.
Ready now.
jasonchhaybug, ⚑ cross platform4Firefox can crash or corrupt typing after deleting a mention or decorated text and then typing again.
The follow-ups even point to a plausible exactMatch-related DOM range issue, which makes this strong bridge signal.
Strong enough.
Poor.
Valid.
This is a real Firefox DOM bridge bug, not just example slop.
keep-open
Keep it open and test through mentions/highlighting examples.
Direct.
Ready with minor setup.
churichardbug1This is another manifestation of the paste-html example deserializer producing an invalid mixed fragment.
The sole comment basically proves it is example code, not Slate core.
Strong enough.
Strong.
Valid.
Mark it duplicate of the example deserializer issue instead of inflating the core clipboard cluster.
mark-duplicate
Point it at the example fix path.
None.
Not a direct test candidate.
justingolden21bug1The markdown preview example does not handle nested styles in headers because the Prism token rendering is intentionally limited.
The follow-up makes it clear this is an example limitation, not a core markdown engine bug.
Strong enough.
Acceptable.
Valid.
Keep it out of architecture work.
share-status
Treat it as example improvement only.
None.
Not a direct test candidate.
alexej-dimprovement1The paste HTML example deserializer can emit a stray top-level string for certain simple structures like `<div>
</div>`.The report and follow-up are concrete and clearly scoped to the example.
Strong enough.
Strong.
Valid.
This is example/docs debt, not core clipboard semantics.
keep-open
Keep it on the examples backlog.
None.
Not a direct test candidate.
diskszkbug2The mentions example uses word-based matching, so hyphenated values like R2-D2 break the dropdown.
The comments explain why this is example logic, not a Slate core tokenizer bug.
Strong enough.
Acceptable.
Valid.
This belongs with example ergonomics, not core API.
share-status
Treat it as example improvement only.
None.
Not a direct test candidate.
prioloimprovement, docs0insertData was under-documented in the API reference.
This is plain docs debt.
Strong enough.
Poor.
Valid.
Keep it in docs, nowhere else.
keep-open
Add or point to the missing reference docs.
None.
Not a direct test candidate.
shtbikbug0Pasting an image URL into an empty images example after select-all can hit a null parent path and error out.
The issue is clean and uses an official example.
Strong enough.
Poor.
Valid.
Good current regression test material.
keep-open
Keep it open and test through the public paste path.
Direct.
Ready now.
Torvinbug3Programmatically clearing the editor on Enter can leave selection pointing into vanished content and crash with a DOM point error.
The workarounds make the underlying selection-reset problem clearer, not weaker.
Strong enough.
Acceptable.
Valid.
This is good current selection-reset test material and also ties into external replacement ergonomics.
keep-open
Keep it open under document replacement and selection repair.
Direct.
Ready now.
arnav-and-projectsbug2This is a hot-refresh environment issue already pointed at an older duplicate.
Nothing new is learned here beyond the duplicate reference.
Strong enough.
Strong.
Duplicate candidate.
Do not count this twice.
mark-duplicate
Mark it duplicate of the linked hot-refresh issue.
None.
Not a direct test candidate.
Torvinbug, ⚑ cross platform1A rerender right after focus can make Slate restore the wrong remembered caret instead of honoring the click target.
The update showing it can happen in Chrome too makes this more general than one Firefox quirk.
Strong enough.
Poor.
Valid.
This is a real focus/runtime timing bug.
keep-open
Keep it open and test focus followed by immediate rerender.
Direct.
Ready now.
bryanphimprovement0Undo after deleteFragment should reselect the restored content instead of leaving the caret at the end.
This is a clean history-behavior request with concrete expected behavior.
Strong enough.
Poor.
Valid.
This is one of the few strong slate-history semantics issues.
v2-roadmap
Keep it on the history model roadmap.
Direct.
Ready now.
churichardbug, ⚑ cross platform0Safari autocorrect can clear selection entirely, forcing the user to click back into the editor mid-typing.
The report is clean and points at the official richtext example.
Strong enough.
Poor.
Valid.
This is another real browser-input contract bug.
keep-open
Keep it open under Safari autocorrect behavior.
Direct.
Ready with minor setup.
jameshfisherbug28This is a major copy/paste semantics debate, not just a broken paste bug.
The long thread makes the real problem obvious: Slate needs clearer copy/paste strategies and override seams instead of pretending one default behavior fits everyone.
Strong enough.
Acceptable.
Valid.
Do not reduce this to one bug row. It is architecture pressure around fragment semantics and clipboard override APIs.
v2-roadmap
Keep it on the v2/runtime roadmap, not in generic bug triage.
Direct.
Not a direct test candidate.