docs/slate-issues/open-issues-dossiers/3558-3435.md
pau-not-paulnone1External agents like Google Translate can mutate the DOM and make Slate crash with removeChild errors.
The thread is small, but the problem is concrete and clearly tied to foreign DOM mutation rather than ordinary typing.
Strong enough.
Acceptable.
Valid.
Keep it as real runtime-boundary debt around foreign DOM mutation.
share-status
Share status and keep it attached to external DOM mutation, not generic typing crashes.
Indirect.
zengemnone11Users expect overriding insertNode or insertFragment to catch paste flows, but the real pipeline goes through insertData and leaves them stranded.
The thread matters because it shows the current paste pipeline is understandable to maintainers but confusing to plugin authors.
Strong enough.
Poor.
Likely valid.
Keep it as plugin-hook and paste-pipeline ergonomics pressure, not a core crash.
share-status
Share the real paste hook surface and decide whether the API should be clearer.
Indirect.
hadrysmateuszbug, ♥ help1Undo after moveNodes could restore the wrong state.
The thread is thin and mostly valuable because it points at a likely later fix.
The only useful later signal is PR #4717, which makes this look more like historical history debt than a fresh unknown.
Strong enough.
Poor.
Stale candidate.
De-weight it unless someone revalidates it on current Slate.
share-status
Share the likely fix path instead of treating it like fresh breakage.
Direct.
ecklfbug4If the user is still holding the mouse button, toggling a mark can break the selection.
The comments are useful because they narrow the failure to mark toggles plus tiny mouse movement, not just any selection drag.
Strong enough.
Acceptable.
Valid.
Keep it open as real selection-plus-mark-toggle debt.
keep-open
Acknowledge it and keep it tied to active drag selection during mark changes.
Direct.
hadrysmateuszbug1Undo after a multi-block edit can restore the wrong selection start.
The thread is short, but the repro is crisp and selection-specific, which makes it perfect history debt.
Strong enough.
Poor.
Valid.
Keep it open as real history selection-restore debt.
keep-open
Acknowledge it and keep it in the history-selection family.
Direct.
skogsmaskinbug, ♥ help3Marked text moved to a new line can break caret placement and then undo to the wrong mark state.
This is useful because it ties insert-break, marks, and history together in one concrete repro instead of three separate complaints.
The comments matter because they show parts of the issue were thought fixed by PR #3602 and PR #3690, but later reports say at least one part still survives.
Strong enough.
Poor.
Likely valid.
Keep it open, but treat it as mixed history and mark-state debt instead of a narrow text-format bug.
keep-open
Acknowledge it and keep it tied to mark plus history semantics across line splits.
Direct.
skokenesbug, ♥ help4Unrelated parent state updates can still steal focus from the editor.
The comments are useful because they broaden the issue to multiple editors and external state changes, not just one inline node case.
Strong enough.
Poor.
Valid.
Keep it open as high-signal React runtime focus debt.
keep-open
Acknowledge it and keep it grouped with rerender-driven focus loss.
Direct.
lcswillemsquestion0This is a fair design-question issue: the transfer-data base64 step is not obvious and wants explanation.
There is no thread, but the question is concrete enough to count as docs debt rather than noise.
Strong enough.
Acceptable.
Valid.
Keep it as docs and design-explanation debt, not a bug.
share-status
Answer the design question or document it plainly.
None.
lcswillemsfeature1The hard-coded fragment transfer-data id causes trouble when multiple Slate-based systems need to coexist.
The lone comment is useful because it pressures the real question: is this already achievable through existing copy hooks, or does the API need a better seam?
Strong enough.
Acceptable.
Valid.
Low urgency, but legitimate clipboard API pressure.
share-status
Share status and decide whether existing copy hooks are enough.
Indirect.
skogsmaskindiscussion, ⚑ collaboration13The required empty text child inside void nodes remains one of the strongest old data-model design tensions in Slate.
The thread is rich and worth preserving because it argues the tradeoff from multiple angles instead of treating it as a simple bug.
Strong enough.
None.
Valid.
Keep it as serious v2 data-model pressure, not a patch request.
v2-roadmap
Share status and frame it as data-model tradeoff, not a missing fix.
Direct.
marawannwhquestion2This is a legacy 0.47 support question, not meaningful current Slate debt.
The thread never leaves old-version support territory.
Strong enough.
None.
Stale candidate.
Close or ignore it as pre-0.5 support noise.
close-stale
Point at the old extension seam if anyone still asks, but do not let it steer current work.
None.
arpit016bug20If onChange feeds an async external store like Redux, the editor can crash under ordinary typing speed.
The thread is strong because multiple people reproduced it outside Redux too, which makes the real seam async external updates, not one library.
Strong enough.
Acceptable.
Valid.
Keep it open as high-signal external-store integration debt.
keep-open
Acknowledge it and keep it grouped with async controlled-value crashes.
Direct.
RudeySHbug, android13Selecting text and moving the cursor on Android could insert ghost text and completely break editing.
The thread is valuable because it shows both the old unsupported status and ongoing attempts to patch Android behavior in later forks.
Strong enough.
Poor.
Invalid for current Slate.
Do not count it as current-contract bug debt, but keep it as strong Android platform signal.
v2-roadmap
Share status honestly and keep it in the Android-demand bucket.
Direct.
thalladabug5Copying or deleting a whole list still fails because the selection does not actually include the block structure the user thinks it does.
The comments strengthen it by generalizing the same bug to more block-level nodes, not just lists.
Strong enough.
Poor.
Valid.
Keep it open as strong structural selection and delete debt.
keep-open
Acknowledge it and keep it in the same select-all structural-delete family.
Direct.
kleinspirebug, ♥ help4Backspacing in the middle of bold text can merge paragraphs when it should just delete a character.
The thread is still useful because it narrows the exact caret position needed to hit the bug.
The comments already point at Issue #3339, so this looks more like a sharper repro for an older delete-and-merge family than a new problem line.
Strong enough.
Poor.
Duplicate candidate.
Keep the repro, but consolidate it under the older delete-and-merge family.
close-duplicate
Share the duplicate target and keep the sharper repro if the older issue is too fuzzy.
Direct.
davidruisingerfeature10Slate still lacks a clean story for normalizing the initial value or imported documents before first user edits.
The comments make it stronger because multiple migration and import flows hit the same missing full-document normalization seam.
Strong enough.
Poor.
Valid.
Keep it as high-signal normalization lifecycle pressure.
v2-roadmap
Share status and frame it as normalization lifecycle design, not just helper API churn.
Direct.
EditorContextlcswillemsquestion7People want to put toolbars and command UI outside the editor subtree without losing easy editor access.
The thread is messy, but the core pressure is real: current access patterns are awkward once the toolbar stops living next to Editable.
Strong enough.
Acceptable.
Likely valid.
Keep it as moderate API-surface pressure for React composition.
share-status
Share the current options and decide whether this needs a stronger public seam.
Direct.
lcswillemsfeature, ♥ help3This was a real placeholder-styling request, but it now mostly reads like old API surface before renderPlaceholder and related follow-ups.
The later comments are the whole point: they give both a workaround and a likely close target.
The thread and linked follow-up show this request was effectively superseded by later placeholder customization seams.
Strong enough.
Acceptable.
Stale candidate.
Close or de-weight it as superseded placeholder API debt.
close-stale
Share the newer placeholder surface and close it if nobody disputes that.
Indirect.
dmarkowbug, ♥ help11Arrow navigation breaks around single-character text nodes next to inline elements.
The thread is strong because multiple people generalized the same problem and even narrowed it into Editor.positions().
Strong enough.
Poor.
Valid.
Keep it open as strong inline-boundary and caret-navigation debt.
keep-open
Acknowledge it and keep it tied to inline-boundary navigation rather than generic arrow keys.
Direct.
hanselkequestion2This is simple component contract confusion: Slate is not a DOM element and should not receive an id for DOM lookup.
The comments already answer it cleanly.
Strong enough.
Strong.
Invalid for current Slate.
Close it as current-contract confusion.
close-invalid
Point at Editable or a wrapping div and move on.
None.
jiangpingshendd01question6Calling setState during click handling used to restore an older caret position.
The later comments make it read as historical fix context rather than live debt.
The thread already says PR #3355 fixed the issue, which is the only part worth preserving.
Strong enough.
Acceptable.
Stale candidate.
De-weight it as likely resolved by later selection work.
close-stale
Share the fix breadcrumb and move on unless someone revalidates it.
Indirect.
rockettomatooodiscussion0This is a reasonable namespace-coherence request around addMark and removeMark.
There is no thread, but the issue is coherent and maps cleanly to public API organization.
Strong enough.
Acceptable.
Valid.
Keep it as low-drama API surface pressure.
v2-roadmap
Share status and keep it in namespace and surface cleanup, not bug counts.
Indirect.
mpkellynone0ReactEditor.findEventRange gives inconsistent results on void nodes under mousemove.
There is no thread, but the issue body is specific and compares it to a working seam, which is enough.
Strong enough.
Poor.
Valid.
Keep it open as hit-testing debt around void content.
keep-open
Acknowledge it and keep it tied to event-range stability over void elements.
Direct.
arahansennone0Once the first line is selected with the keyboard, the selection cannot shrink back correctly.
There is no thread, but the issue has a crisp keyboard repro and a clear expected behavior.
Strong enough.
Poor.
Valid.
Keep it open as keyboard selection debt.
keep-open
Acknowledge it and keep it tied to selection expansion and shrink behavior.
Direct.
kleinspirequestion, discussion1There is no clean way to insertBreak after a selected void element without weird double-insert behavior.
The workaround discussion is useful because it proves the current input handling captures the same Enter key twice across the manual and built-in path.
Strong enough.
Acceptable.
Valid.
Keep it open as real insert-break debt around void boundaries.
keep-open
Acknowledge it and keep it tied to Enter handling after selected void elements.
Direct.