docs/slate-issues/open-issues-dossiers/3705-3568.md
grumpyTofu♥ help, ⚑ needs info, ignored-template5Undo and redo can still emit incomplete set_selection operations when the editor has no current selection, which is especially nasty in off-screen or collaborative flows.
The comments improve the issue a lot because they move it from generic history crash to a concrete partial-selection edge case with a duplicate target.
The thread points back to Issue #3921, and the later comment makes it clear this is the same partial-selection-history family rather than a fresh bug line.
Strong enough.
Poor.
Duplicate candidate.
Keep the signal, but consolidate it under the stronger history-selection parent instead of counting it twice.
close-duplicate
Share the duplicate target and keep the collaboration-flavored note, because that is the useful part.
Direct.
babalugats76bug, ♥ help, selection5Tabbing into the editor can show focus and then immediately lose it, leaving the user unable to type until they click again.
The comments are useful because they isolate rerender timing as the real trigger, not just keyboard tab handling.
The thread ties this directly to Issue #3634, which is useful because both issues collapse into the same focus-versus-rerender ownership bug.
Strong enough.
Acceptable.
Valid.
Keep it open as real focus ownership debt in slate-react.
keep-open
Acknowledge it and keep it grouped with the broader rerender-driven focus failures.
Direct.
pubuzhixing8none8IME input next to marked text can render twice or desync after a left-arrow move, which is another mark-boundary composition failure.
The comments are strong. They reason through browser versus Slate ownership and converge on composition plus mark-boundary mismatch rather than random React churn.
Strong enough.
Poor.
Valid.
Keep it open as part of the long-running IME and mark-boundary family.
keep-open
Acknowledge it and keep it tied to composition behavior near formatted text.
Direct.
pzhinebug, ♥ help0Normalization can remove the wrong node in a very specific reproduced tree shape.
The issue is valuable because it already comes with a precise test-shaped reproduction instead of a hand-wavy GIF.
The issue exists because PR #3602 already had a concrete reproduction, which makes this better than a vague normalization complaint.
Strong enough.
Poor.
Valid.
Keep it open as a strong core normalization regression.
keep-open
Acknowledge it and keep it attached to exact reproduced tree shapes, not generic normalization fear.
Direct.
lcswillemsbug, selection5Toggling a list on Safari can throw the caret to the top of the document.
The comments make the regression shape useful: this appears tied to a specific selection change introduced in a narrow version window.
Strong enough.
Poor.
Likely valid.
Keep it open as Safari caret-placement debt around list formatting.
keep-open
Acknowledge it and keep it tied to selection regression history on Safari.
Direct.
pzhinenone2Editor.addMark could apply to the wrong node when the selection anchor sat exactly on an edge.
The useful part of the thread is the fix breadcrumb, not more confirmations.
The comments point at PR #4168 as the fix path, which makes this look more like resolved history than current roadmap pressure.
Strong enough.
Acceptable.
Stale candidate.
De-weight it unless someone revalidates it on a current build.
close-stale
Share the likely fix path instead of treating it like fresh debt.
Indirect.
rafael-castelonone7Editing one text leaf can rerender far too many sibling leaves inside the same block, which turns rich inline documents into a performance mess.
The comments are useful because maintainers already agreed the expectation is reasonable, even if the implementation surface is tricky.
The thread explicitly points at Issue #3507 and PR #3515, which is useful because it shows this is not one isolated complaint but a known renderer-breadth family.
Strong enough.
Poor.
Valid.
Keep it as a real slate-react performance lane, not vague perf whining.
share-status
Share status and keep it attached to render breadth, not generic optimization wishes.
Direct.
mpkellydiscussion, selection16Slate still throws page-killing errors for a bunch of selection and DOM-mapping failures that could often degrade more gracefully.
The comments make the design pressure clearer: this is about fail-fast policy and runtime boundaries, not just one broken handler.
The thread points at Issue #3575 and similar DOM-point failures, which reinforces that this is a systemic error-policy question, not one bad stack trace.
Strong enough.
Acceptable.
Valid.
Keep it as design pressure for error policy and runtime resilience.
v2-roadmap
Share status and frame it as error-policy design, not a one-line bugfix.
Direct.
kocka5⚑ needs info, ⚑ needs gif1Transforms.unwrapNodes appears to fail on a very specific nested structure that already exists as a test-shaped repro.
There is barely any thread, but the issue body does the real work because it already provides input and expected output trees.
Strong enough.
Poor.
Likely valid.
Keep it open as a crisp structural transform repro.
keep-open
Acknowledge it and keep it tied to the exact failing test, not generic unwrap behavior.
Indirect.
harrisonturtonbug, ♥ help4Calling ReactEditor.focus can appear to work but still drop the next typed input.
The comments narrow it to focus and blur ordering plus rerender timing, which is exactly the runtime seam we care about.
The later workaround link to Issue #3696 is useful because it proves this is the same rerender-driven focus bug, not a separate focus API.
Strong enough.
Acceptable.
Valid.
Keep it open as real focus timing debt in slate-react.
keep-open
Acknowledge it and keep it grouped with the same-tick rerender focus bugs.
Direct.
jolanglinaisnone17This mostly turns out to be a stale-closure and editor-recreation problem, not a core Slate state bug.
The comments do useful triage work: they keep pointing back to recreating the editor and stale closures instead of exposing a broken core invariant.
Strong enough.
Acceptable.
Invalid for current Slate.
Treat it as current-contract misuse and API ergonomics confusion, not a live engine bug.
close-invalid
Point at editor lifetime and closure stability instead of keeping it as generic state corruption.
Indirect.
codeGun123none9People keep wanting a stable DOM ref for Editable, mostly for focus and positioning work.
The comments are useful because they separate true DOM access needs from the existing focus helpers.
Strong enough.
Acceptable.
Valid.
Low urgency, but legitimate API-surface pressure.
share-status
Share the existing helpers and decide whether exposing the ref is worth the extra surface area.
Indirect.
Obiwarnfeature, discussion3This is mostly example-scope pressure around paste-html, not a case for shipping paste-from-websites as core policy.
The maintainer response is the important part. It explains why paste handling stays domain-specific even if the example could be nicer.
The comments and linked PR #3472 make it clear the real pain is example behavior and line-break handling, not proof that this belongs in core.
Strong enough.
None.
Invalid for current Slate.
Keep it de-weighted as example and package-scope chatter.
share-status
Share scope and keep it out of core architecture counts.
None.
GenesisSamnone0If a void image is selected, IME composition can still slip text into the spacer around it.
There is no thread, but the issue body is concrete enough to keep it as real void-plus-IME debt.
Strong enough.
Poor.
Valid.
Keep it open as void focus and IME ownership debt.
keep-open
Acknowledge it and keep it tied to composition around selected void elements.
Direct.
nikglavinnone7Select-all then delete can leave empty blocks and trailing void content behind instead of actually clearing the editor.
The thread is strong because later comments widen the same failure to void nodes and multiple examples, not just plaintext placeholder weirdness.
Strong enough.
Poor.
Valid.
Keep it open as high-signal structural delete debt.
keep-open
Acknowledge it and keep it in the select-all delete family.
Direct.
1egomannone0A background requestAnimationFrame or setInterval loop can make Slate accept focus only for a split second.
There is no thread, but the repro is sharp and it fits the same rerender-driven focus loss family as later issues.
Strong enough.
Poor.
Valid.
Keep it open as focus ownership debt around background rerenders.
keep-open
Acknowledge it and keep it grouped with focus loss under unrelated rerender pressure.
Direct.
ArsalanSavanddiscussion5This is real ecosystem demand for Angular, but not a case for first-party Angular support inside Slate core.
The maintainer answer is already the classification: built-in Angular support is unlikely, but ecosystem adapters are real and welcome.
Strong enough.
None.
Invalid for current Slate.
Treat it as ecosystem demand, not a core roadmap bug or feature.
share-status
Share status and point at the ecosystem adapter path.
Indirect.
wugengliuli-webnone4Chinese input can still desync data and view on the stock examples.
The comments are strong because they reason through the event order and explain why IME plus React reconciliation is the real fault line.
The comments link this to Issue #3824 and walk through event-flow differences, which makes it much more useful than a generic Chinese-input complaint.
Strong enough.
Poor.
Valid.
Keep it open as real IME event-normalization debt.
keep-open
Acknowledge it and keep it tied to event normalization across IME flows.
Direct.
beornnone1Applying bold or italic with keyboard shortcuts can crash with Cannot find DOMPoint in the official examples.
The thread is small, but the workaround hint is useful because it narrows the fault line to custom handling in onDOMBeforeInput.
Strong enough.
Acceptable.
Valid.
Keep it open as high-signal DOM-point debt around formatting shortcuts.
keep-open
Acknowledge it and keep it attached to shortcut handling through onDOMBeforeInput.
Direct.
majelbstoatnone1Selection can occasionally look stale in a consumer onClick handler, but the repro is weak and intermittent.
The comments do not improve the issue much beyond confirming that somebody else has seen something similar.
Strong enough.
Poor.
Unclear.
Needs a tighter repro before it should influence architecture work.
ask-for-repro
Ask for a sharper reproduction that isolates selection timing on click.
Indirect.
majelbstoatnone2In read-only mode, consumers still want selection changes to flow through onChange without allowing content edits.
The comments keep the issue grounded in real use cases like comments and review flows, not generic API bikeshedding.
The thread points at PR #4375, which matters because this is a real API seam and not just a random idea.
Strong enough.
Poor.
Valid.
Keep it as legitimate runtime API pressure for read-only interaction.
v2-roadmap
Share status and frame it as read-only interaction design, not a trivial callback tweak.
Direct.
cucarnone1Slate breaks event handling inside iframes because it assumes the wrong document.
The single comment does the key work: it points straight at document ownership as the real fault line.
Strong enough.
Poor.
Valid.
Keep it open as strong cross-document runtime debt.
keep-open
Acknowledge it and keep it grouped with iframe and external-document ownership bugs.
Direct.
cucarnone2This looks like docs confusion around Editor.isBlock, not live runtime debt.
The thread already points readers at the next walkthrough page, which makes this more like stale docs friction than an open platform issue.
Strong enough.
Strong.
Stale candidate.
Close or de-weight it as resolved docs confusion.
close-stale
Share the docs breadcrumb and move on.
None.
thesunny⚑ mobile, android12This is not a current bug ticket, but it is strong evidence that Android support kept demanding specialized work and economic support.
The thread is valuable because it shows sustained user demand and maintainer acceptance that Android is a major separate investment.
Strong enough.
None.
Invalid for current Slate.
Do not count it as current-contract bug debt, but keep it as strong platform-scope signal.
v2-roadmap
Share status honestly and treat it as Android platform demand, not a hidden patch request.
Direct.
majelbstoatbug, discussion2Calling addMark during onDOMBeforeInput with a non-collapsed selection can crash Slate.
The thread is useful because it leaves the issue open instead of pretending the usage is obviously invalid, and it documents a workaround path.
Strong enough.
Acceptable.
Valid.
Keep it open as real mark-mutation timing debt.
keep-open
Acknowledge it and keep it tied to mark changes during DOM-before-input handling.
Direct.