docs/slate-issues/open-issues-dossiers/3878-3798.md
kamilmielniknone7Programmatic value replacement can leave useSlate().selection pointing at a dead path, which is still one of the clearest controlled-value runtime failures in old Slate.
The comments are useful because they confirm the issue survived later versions, produced real crashes in production, and pushed users into ugly remount workarounds instead of a real fix.
Strong enough.
Poor.
Valid.
Keep it open as controlled-value and selection-reconciliation debt.
keep-open
Acknowledge the issue and keep it tied to selection remapping during external value replacement.
Direct.
arimahmlh11This is direct pressure for explicit history transaction grouping instead of inferring undo boundaries from a loose stream of operations.
The thread is thoughtful, not noisy. It compares the ask to existing batching patterns and makes it clear this is a history API seam, not random sugar.
Strong enough.
Acceptable.
Valid.
Keep it on the roadmap as real transaction-boundary pressure.
v2-roadmap
Reply with scope/status instead of pretending this is a tiny patch.
Direct.
pubuzhixing8none1Slate still lets normal keydown logic punch through during IME composition, which is exactly how composition bugs keep becoming caret bugs.
The thread is short but sharp. It ties the problem to the broader composition-gating family instead of leaving it as one weird keyboard anecdote.
The thread points at Issue #4127, which looks like the same composition-gating family rather than unrelated noise.
Strong enough.
Poor.
Valid.
Likely part of the same composition-gating family as later issues, but still worth keeping as its own repro.
keep-open
Acknowledge the issue and keep it tied to composition gating instead of generic key handling.
Direct.
evasteingrimsnone1Triple-click selection is still wrong when inline elements sit inside the block, which means Slate is not faithfully owning common paragraph-selection gestures.
The comments add a useful extension: the issue is not just missing text, it is the whole selection envelope around inline content.
Strong enough.
Poor.
Valid.
Keep it open as part of the triple-click and inline-selection family.
keep-open
Acknowledge the issue and keep it tied to gesture-level block selection.
Direct.
evasteingrimsnone3Triple-click selection can bleed into the block below, which is the other half of the paragraph-gesture bug family.
The thread is useful because it captures the common workaround, and that workaround is basically “turn off the browser gesture,” which is not a serious fix.
The comments point toward Issue #4908, which looks like a more specific descendant of the same selection-gesture family.
Strong enough.
Acceptable.
Valid.
Related to later triple-click selection bugs, but still a distinct repro shape.
keep-open
Acknowledge the issue and keep it tied to triple-click block selection boundaries.
Direct.
ebasicnone2The crash report is real enough, but the thread points back to an invalid void-node contract rather than a core Slate failure.
The comments are what matter here. They make it clear the repro depends on missing required children, so this should not steer architecture work.
Strong enough.
Strong.
Invalid.
This is a current-contract problem, not an open engine mystery.
close-invalid
Reply with the void-element contract and close it if nobody produces a valid repro.
None.
markogresaknone2Selection deletion still falls apart when the range crosses void nodes, which is one of the clearest structural-delete failures in old Slate.
The comments narrow it to a real public seam: delete/remove over an expanded selection containing an image should delete the selected thing, not some adjacent text.
Strong enough.
Poor.
Valid.
Keep it open as real structural deletion debt around void content.
keep-open
Acknowledge the issue and keep it tied to deletion semantics over expanded selections.
Direct.
idevelopnone8Deeply emptying the editor still looks like controlled-value reset debt: Slate keeps references to descendants that no longer exist.
The thread broadens the issue into multiple reset variants, which makes it slightly messier, but still clearly about stale paths after external value replacement.
Strong enough.
Acceptable.
Likely valid.
Keep it in the same external-value and selection-reset family as other stale-path crashes.
keep-open
Acknowledge the issue and keep it tied to stale path cleanup on external resets.
Direct.
kamilmielniknone4Cutting selected blocks copies them but can leave them in place, which is a clean user-facing structural-edit bug.
The comments do real work here: they tie the bug to the same deleteFragment and expanded-selection family instead of leaving it as a vague clipboard complaint.
Strong enough.
Poor.
Valid.
Keep it open as part of the structural delete and cut family.
keep-open
Acknowledge the issue and keep it tied to cut/delete semantics on expanded block selections.
Direct.
dustinknopoffnone1Firefox still diverges on one of the most common extension seams: overriding insertBreak and then moving the caret.
The thread is tiny, but the repro is crisp enough that the issue should stay in the browser-specific caret-placement pile.
Strong enough.
Poor.
Valid.
Keep it open as browser-specific insert-break caret debt.
keep-open
Acknowledge the issue and keep it tied to Firefox caret movement after custom line breaks.
Indirect.
qktrzrjnone8This is one more Cannot resolve a Slate point from DOM point thread, but the issue is too generic to trust without a stronger repro.
The comments are mostly confirmations and stack traces. They increase noise more than they improve classification.
Weak.
Poor.
Unclear.
Needs a tighter repro or a sharper duplicate target before it should influence architecture work.
ask-for-repro
Ask for a reproduction that narrows the DOM/Slate mismatch instead of treating this as stand-alone signal.
Indirect.
silviubogannone1This is a slightly better-written DOM-point crash than the other generic threads, but it still does not isolate the actual owning seam.
The thread never gets past “same here,” so it should stay de-weighted until someone produces a real repro.
Weak.
Poor.
Unclear.
Still too generic to become meaningful architecture input.
ask-for-repro
Ask for a tighter reproduction or consolidate it under a cleaner DOM-point issue.
Indirect.
matt-savvynone2This is simple docs debt: the custom-formatting walkthrough omitted a required import and left readers to fail in avoidable ways.
The thread is small, but it proves the docs path was rough enough to block a real user.
Strong enough.
Strong.
Valid.
Keep it in docs debt, not architecture pressure.
share-status
Reply with scope/status or fix the docs silently; it does not need a grand roadmap answer.
None.
TejaReddy7none6This thread is mostly user surprise about how active marks behave after deletion, not evidence of a broken core mark model.
The comments are decisive: they explain that the observed behavior is expected unless the consumer clears marks explicitly.
Strong enough.
Strong.
Invalid.
Close it as expectation mismatch unless someone produces a stronger contract argument.
close-invalid
Point at the current mark behavior and close it if the user still expects a different default.
None.
mwood23none0useFocused lies when the editor is rendered through portals, which is exactly the sort of focus-state ownership bug that keeps surfacing in Slate React.
The issue is already precise enough. It does not need a long thread to prove the runtime assumption is wrong.
Strong enough.
Poor.
Valid.
Keep it open as focus-state ownership debt around external DOM trees.
keep-open
Acknowledge the issue and keep it tied to focus tracking across portals.
Direct.
affinitygithonielnone0PathRef affinity is still too blunt for real operation sequences, which is a real API pressure point for anyone doing nontrivial structural edits.
The thread is light, but the ask is precise and easy to map to deeper path-tracking design debt.
Strong enough.
Acceptable.
Valid.
Keep it as API design pressure, not patch work.
v2-roadmap
Reply with scope/status and keep it in the path-ref design pile.
Direct.
kamilmielniknone3Programmatic caret placement still goes wrong around mention-like inline flows, which makes one of Slate’s core imperative seams feel brittle.
The workaround is useful because it confirms this is timing- and selection-reconciliation debt, not a misunderstanding of the API.
Strong enough.
Acceptable.
Valid.
Keep it open as programmatic selection-placement debt.
keep-open
Acknowledge the issue and keep it tied to imperative caret placement around inline content.
Direct.
mdmjgnone7This is mostly an example-scope mismatch: users expect the paste-html example to also own image file ingestion.
The comments clarify that the real gap is example scope, not proof that Slate’s HTML handling is fundamentally broken.
Strong enough.
Acceptable.
Likely invalid.
Share scope/status instead of treating it as core serialization architecture.
share-status
Explain the example’s scope and point users at the right example or custom file-handling surface.
None.
RavenColEvolnone8This was filed while Android was still effectively unsupported, but it is still valuable because it captures real demand and a concrete failure mode.
The comments matter because they explicitly say Android support was not there yet, which keeps this out of current-contract bug counts while preserving it as v2 signal.
Strong enough.
Poor.
Invalid for current Slate, but valuable for v2.
Do not count it as a current-contract bug, but do keep it as Android demand signal.
v2-roadmap
Share status honestly: unsupported in current Slate, but still relevant to future platform scope.
Direct.
BrentFaresemlh3This is half API ergonomics request and half real transform bug, both living on the same setNodes seam.
The later recording/comment is what keeps it meaningful. Without that split repro, the issue would look like ordinary API wishfulness.
Strong enough.
Acceptable.
Valid.
Keep it on the transform API and structural-edit design pile.
v2-roadmap
Reply with scope/status instead of pretending the two asks are unrelated.
Direct.
eeknone1This is niche, but it still looks like a real offset-zero node-resolution seam rather than user error.
The workaround helps a lot because it narrows the failing condition to cursor-at-start behavior and wrong node lookup.
Strong enough.
Acceptable.
Likely valid.
Keep it open, but do not overweight it architecturally.
keep-open
Acknowledge the issue and keep it scoped to node resolution at offset zero.
Indirect.
markogresaknone5This is a docs request around a real core quirk: node identity and object references behave in ways that surprise people over and over again.
The comments make it clear this is not hypothetical. People really do get cut by this identity rule repeatedly.
Strong enough.
Acceptable.
Valid.
Keep it in docs and design signal, not bug counts.
share-status
Document the identity rule plainly instead of treating it like trivia.
Direct.
Teiponone1Cutting a selection with nested list content leaves the survivor with the wrong block type, which is textbook structural-delete debt.
The follow-up comment is valuable because it ties the issue to the same delete/backspace family instead of a random list oddity.
Strong enough.
Poor.
Valid.
Keep it open as structural cut/delete normalization debt.
keep-open
Acknowledge the issue and keep it tied to selection deletion and post-cut normalization.
Direct.
vshmelevnone9This is old IE11 compatibility churn, not meaningful v2 architecture pressure.
The thread never escapes old-browser support territory, so it should stay de-weighted.
Strong enough.
Poor.
Stale candidate.
Close or de-weight it as legacy-browser debt.
close-stale
Share status plainly if anyone still asks, but do not let it steer modern design.
None.
user-select: all not working on Chrome w/ Slaterneissnone2This looks much more like browser and contenteditable interaction pain than a strong Slate-owned selection bug.
The workaround comment supports that read: users can dodge it, but Slate does not obviously own the underlying behavior.
Strong enough.
Acceptable.
Likely invalid.
Do not let this count as core architecture pressure without a stronger argument.
close-invalid
Share status or close if nobody can show a clearly Slate-owned failure.
None.