docs/slate-issues/open-issues-dossiers/4741-4643.md
zhugexinxinfeature1This is an API-usage question about traversing a fragment, not a live engine bug.
The reporter resolved it themselves in the only follow-up, so this is just stale support residue.
Strong enough.
Strong.
Stale candidate.
This should be closed as resolved support history, not treated as architecture signal.
close-stale
Close it as stale/resolved and move on.
None.
Not a direct test candidate.
leochow-houzzbug0Typing immediately after a multi-line mouse selection can blow up React DOM reconciliation with a removeChild DOMException.
The report is concise but it reproduces on the official richtext example, which is enough to treat it as real runtime debt.
Strong enough.
Poor.
Likely valid.
Keep it in the runtime-boundary bucket instead of dismissing it as generic React noise.
keep-open
Keep it open and scoped to selection-plus-typing DOM instability.
Direct.
Ready now.
kGe-zbug1Selecting all and deleting in the images example can leave the wrong residual paragraph state when an image sits at the end.
The thread is light, but the repro targets an official example and the bug shape is clear.
Strong enough.
Poor.
Valid.
This is solid current-Slate behavior debt with a good integration seam.
keep-open
Keep it open and test through the images example behavior.
Direct.
Ready now.
bryanphfeature0This asks for insert transforms to return the affected range so follow-up transforms do not have to reconstruct it from brittle refs.
There is no disagreement in the thread, just a clear API ergonomics request with real transform semantics behind it.
Strong enough.
Acceptable.
Valid.
This is better treated as v2 API shaping than as a current bug.
v2-roadmap
Keep it on the roadmap as core transform API work.
Direct.
Not a direct test candidate.
async event handlers to be attached to Editable's eventsunageekimprovement0Async Editable handlers get treated as handled just by returning a Promise, which breaks built-in hotkeys and default behavior.
The report points to the exact helper and the proposed fix is coherent, so this is easy to classify.
Strong enough.
Acceptable.
Valid.
This is a clean slate-react contract bug, not just user confusion about async handlers.
keep-open
Keep it open and fix the handler contract instead of telling users to avoid async.
Direct.
Ready now.
AkromDevbug, ⚑ cross platform0Android cannot reliably select void nodes like images by tapping them, which makes common media workflows miserable.
The report is simple but specific and uses the official images example.
Strong enough.
Poor.
Valid.
This is another real Android runtime seam, not a one-off device quirk.
keep-open
Keep it open under mobile selection behavior.
Direct.
Ready with minor setup.
AleksandrHovhannisyanbug1Passing editor.selection explicitly to at can behave differently from relying on the implicit default selection.
The issue has a real repro and a plausible explanation in the follow-up, so it is good current test fodder.
Strong enough.
Acceptable.
Valid.
This is clean transform semantics debt in slate, not just docs ambiguity.
keep-open
Keep it open and test the explicit-vs-implicit selection path.
Direct.
Ready now.
zhugexinxindiscussion5This is not really “table copy is broken”; it is a design argument about what a fragment should preserve and who should own that behavior.
The discussion is valuable because it exposes the real ambiguity: generic copy/paste heuristics versus plugin-controlled semantics.
Strong enough.
Acceptable.
Valid.
Do not treat this as a simple bug. It belongs in the clipboard strategy and extensibility lane.
v2-roadmap
Keep it open as architecture pressure around fragment semantics and override seams.
Direct.
Not a direct test candidate.
text field interferes with selectionakonsubug0Decoration ranges that inject a text field with a different length can desync the rendered leaf from the caret position.
The issue is concise but specific enough to test directly.
Strong enough.
Poor.
Valid.
This is a real decoration/runtime contract bug in slate-react.
keep-open
Keep it open and test through decoration rendering plus caret placement.
Direct.
Ready now.
AleksandrHovhannisyanbug7Typing at the end of a trailing inline got better, but users can now get trapped inside that inline at the end of the editor.
The thread has concrete mitigation ideas and linked follow-up work, which makes this strong runtime signal rather than vague UX whining.
Strong enough.
Acceptable.
Valid.
This is exactly the kind of inline-boundary behavior that should have explicit runtime ownership.
keep-open
Keep it open around end-of-inline exit behavior, not around reverting prior fixes.
Direct.
Ready now.
NEWESTERSbug1Slate hardcodes empty text node creation, which makes richer custom text defaults awkward or impossible to express cleanly.
The workaround is ugly but real, and the follow-up does not actually disprove the pressure point.
Strong enough.
Acceptable.
Valid.
Treat this as core typing/extensibility pressure, not a quick current bug fix.
v2-roadmap
Keep it on the v2 API/typing roadmap.
Direct.
Not a direct test candidate.
peteshillingbug, ⚑ cross platform3Changing Editable white-space to a collapsing mode breaks trailing-space input in Chrome and Safari, while the default mode breaks certain alignment layouts.
The report has a real sandbox and the problem sits squarely at the contenteditable/browser-layout boundary.
Strong enough.
Poor.
Likely valid.
This is browser/layout debt, but still real runtime pressure.
keep-open
Keep it open as layout-vs-editing boundary behavior.
Indirect.
Ready with minor setup.
GrinchakAndrewfeature1Autofocus can place the caret at offset zero instead of the end, which is jarring for input-like editor uses.
The thread is small, but there is even a linked PR, so the issue is concrete enough.
Strong enough.
Acceptable.
Likely valid.
This is routine focus-timing debt in slate-react.
keep-open
Keep it open or link it to the corresponding fix attempt.
Indirect.
Ready now.
AkromDevbug1Android Chrome and Samsung Internet cannot compose Korean cleanly; characters get split into junk instead of forming words.
Another commenter confirms Japanese too, so this is a real IME cluster member.
Strong enough.
Poor.
Valid.
This is direct mobile/IME architecture pressure.
keep-open
Keep it open and group it with Android composition behavior.
Direct.
Ready with minor setup.
gland2015feature5This is a generic product question about release timing and batteries-included editors, not an actionable issue.
The thread is just roadmap chatter, not implementation signal.
Not applicable.
None.
Invalid.
Keep this out of the architecture corpus.
close-invalid
Close or redirect it as out of scope.
None.
Not a direct test candidate.
silviuboganimprovement0The request is simply for printable or downloadable docs, not an engine problem.
No one disputed it; it just belongs in docs maintenance, not v2.
Strong enough.
Acceptable.
Valid.
Do not let this leak into package architecture work.
share-status
Treat it as docs backlog only.
None.
Not a direct test candidate.
schnuderlimprovement1Clearing the whole document resurrects a default node shaped like the last deleted block, which is hostile to custom schemas.
The workaround is detailed and the failure mode is obvious.
Strong enough.
Acceptable.
Valid.
This belongs in the core normalization/default-node contract.
v2-roadmap
Keep it on the core roadmap and test the empty-document reset path.
Direct.
Ready now.
akonsubug, ⚑ cross platform0Paste does not trigger onDOMBeforeInput, which makes a supposedly generic event hook incomplete on a key input path.
The report is minimal but direct and easy to verify.
Strong enough.
Poor.
Valid.
This is a straightforward Editable event contract bug.
keep-open
Keep it open and test the paste event path.
Direct.
Ready now.
akonsubug, ⚑ cross platform4The complaint is really that useSlate returns a stable editor object, not that rerenders do not happen.
The workarounds and hook distinction make this look more like expectation mismatch than a broken contract.
Strong enough.
Acceptable.
Likely invalid.
Useful for API clarity, weak as a current bug.
close-invalid
Reply with the hook contract or close as expectation mismatch.
Indirect.
Not a direct test candidate.
NorseGaudimprovement0The docs are overwhelmingly React-shaped, which makes core-only or alternate-framework adoption much harder than it should be.
The request is reasonable and not hostile to the React-first runtime story.
Strong enough.
Poor.
Valid.
This is docs debt, not a reason to make the core framework-neutral by force.
share-status
Keep it in docs backlog, not v2 core requirements.
None.
Not a direct test candidate.
jesusmdybug3The placeholder rendering model can collapse weirdly inside flex layouts because of how Slate positions placeholder leaves.
The thread even contains concrete workarounds, which makes this real rendering debt rather than user styling confusion.
Strong enough.
Acceptable.
Valid.
This belongs in placeholder/rendering runtime cleanup.
keep-open
Keep it open and test through flexbox placeholder rendering.
Indirect.
Ready now.
christian-schulzebug, ⚑ cross platform3A table at the end of the document can let the cursor escape the table bounds, after which typing corrupts both DOM and Slate state.
The reporter even found a normalization workaround, which sharpens rather than weakens the issue.
Strong enough.
Acceptable.
Valid.
This is strong selection/DOM-boundary debt even if the structure is custom.
keep-open
Keep it open around table end-of-document cursor ownership.
Direct.
Ready now.
tiavina-mikabug, ⚑ cross platform3This was a Next.js hydration-warning thread with an immediate prop-level workaround and a linked PR.
That makes it stale docs/runtime drift, not live architecture pressure.
Strong enough.
Strong.
Stale candidate.
Close or fold into docs for SSR props.
close-stale
Close it as stale/resolved-in-thread.
None.
Not a direct test candidate.
$ sign was considered part of the word when using Editor.before(editor, start, {unit: 'word'});Yoomin233bug3The complaint is really about Unicode word-boundary semantics not matching a mention implementation’s expectations.
The follow-ups show workarounds and point to intentional underlying behavior.
Strong enough.
Strong.
Likely invalid.
Useful docs/API clarity maybe, weak as a current bug.
close-invalid
Reply with the word-boundary contract or close it.
None.
Not a direct test candidate.
ricardoimprovement3Invalid selections can crash the editor with an uncatchable DOM point error instead of degrading gracefully.
The follow-ups connect this to external document replacement, which makes it more than one bad caller.
Strong enough.
Poor.
Valid.
This is good v2 error-resilience pressure, but the exact current behavior choice is still a design call.
v2-roadmap
Keep it on the roadmap as selection error-resilience work.
Direct.
Not a direct test candidate.