docs/slate-issues/open-issues-dossiers/5912-5771.md
These dossiers cover issues #5912 through #5771 from the pilot set. Use the top-level index for the range map and the ledger for the canonical structured cache.
How can we use this library on browsers that don't support composition events?LLwillbug, ⚑ cross platform0This is a Windows WeChat Browser composition/input-method failure with no evidence yet that Slate can or should paper over the missing browser behavior.
There is no thread. The body is concrete enough to classify, but not strong enough to prove Slate ownership.
Likely real in the named browser.
No workaround in-thread.
Likely invalid as a current Slate issue.
This looks more like a browser-support boundary than a Slate bug.
close-invalid
Keep the reply narrow: state that the report depends on a browser lacking normal composition support, and ask for Slate-specific evidence before keeping it open.
Indirect. It still reinforces the input-method support cluster.
Not a good Slate test candidate while ownership is this fuzzy.
final bullet point or number doesn't get erased when the user hits backspaceakac2016bug6This is user-expected rich-text behavior, but the thread makes clear Slate does not promise it as a built-in default.
The thread already does the useful triage: contributor guidance says this belongs in consumer/plugin logic, and later comments share working custom implementations.
Strong.
Acceptable. Custom plugin logic exists.
Likely invalid as a core Slate bug.
This should not be allowed to masquerade as a core defect just because users expect Google Docs behavior.
close-invalid
Point at the existing plugin-level solutions and keep the answer grounded in Slate’s actual scope.
Indirect. It is more about default-editor expectations than engine architecture.
Not a direct Slate test candidate.
Inconsistent link exit behavior with space key when link is within elementsMaxVhanamanebug6This started as an inline-exit bug report, but the thread ends up as a plugin/presentation pattern exchange more than a current Slate defect.
The reporter gets working custom logic for exiting links and later resolves the boundary-detection problem with non-breaking spaces around the inline element.
Strong.
Acceptable. The thread already contains a working path.
Stale candidate.
This looks resolved enough in-thread that it should not stay open as live engine work.
close-stale
Close it with a short note pointing at the working pattern and the non-breaking-space clarification.
Indirect. It does say something about inline-boundary ergonomics, but not enough to drive architecture.
Not a current test candidate.
[Android] The autocorrect doesn’t work when creating the first linebibixxbug, ⚑ cross platform, android0This is a strong Android empty-editor autocorrect bug: first-line correction fails when moving from placeholder state into real content.
No thread yet. The body is already good enough: repro, sandbox, and multiple Android devices.
Strong.
Poor.
Likely valid.
This belongs in the empty-state mobile IME cluster.
keep-open
Simple acknowledgement is enough until someone repros and narrows the event path.
Direct. Empty-state input is one of the recurrent runtime pain seams.
Ready with minor setup. The behavioral seam is clear.
Composition interrupted in empty text nodes on Android IME12joanbug, ⚑ cross platform, android1This is a high-signal Android IME bug around empty leaves, with concrete internal hypotheses already captured in the thread.
The comment is excellent. It narrows the interruption to a mix of RestoreDOM, empty-node rendering, and DOM text mutation during composition.
Potentially related issue #4400 is already called out.
Strong.
Poor.
Valid.
Not stale and not duplicate. This is one of the best mobile runtime issues in the set.
keep-open
If anyone replies, it should be a status note on which of the identified factors are still believed causal.
Direct. This is exactly the kind of runtime statefulness a cleaner engine/runtime contract should kill.
Ready with minor setup. The empty-leaf composition seam is clear.
Inserting the same node more than once causes strange desyncing behaviornabbydudebug4This is a real identity/desync issue caused by reusing the same node object in multiple tree positions.
The thread is strong. It does not pretend the usage is valid, but it argues convincingly for a better guardrail or error because the failure mode is brutal and cryptic.
Related issue #4309 and performance work around PR #5871 are relevant context.
Strong.
Acceptable, but ugly. The structuredClone fallback is explicitly presented as a stopgap.
Valid.
This is not “support duplicate nodes.” It is “fail less stupidly when they happen.”
keep-open
Keep the thread focused on guardrail/error strategy and performance cost, not on pretending shared object identity should work.
Direct. Stable identity and editor-scoped bookkeeping are right in the blast radius here.
Ready now. This can become a guardrail or error-shape test.
Calling DOMEditor.focus(editor) when a mention is selected causes the selection to be lost.felixfeng33bug0This is a sparse but plausible DOMEditor.focus selection bug around inline voids such as mentions.
No thread yet. The body is thin, but the behavior claim is concrete.
Moderate.
No workaround in-thread.
Likely valid.
Low duplicate signal so far.
keep-open
Ask for a minimal repro only if the current mention example does not reproduce it.
Direct. This is another DOM focus/selection bridge issue.
Ready now as a focused DOM integration test.
In Chrome and Safari, triple-click and backspace should remove the entire block, not just its contents12joanimprovement1This is a worthwhile editing-semantics issue around hanging ranges, triple-click behavior, and block deletion.
The follow-up comment adds the real caution: table cells and other structured content complicate any blanket switch to hanging delete behavior.
Potential regression to #3871 is already called out.
Strong.
Poor at the engine level.
Valid improvement.
This should stay open as an editing-semantics decision, not a bug cleanup.
keep-open
Keep the discussion framed around browser parity and structured-content exceptions.
Direct. This is operation/selection semantics, not example polish.
Ready with minor setup. Browser-specific integration coverage matters here.
Show Mentions after @ symbolmaliuta-oleksandrimprovement1This is a mentions-example/product UX request, not a core editor issue.
The only comment is extra implementation detail from the reporter.
Clear enough.
Acceptable. This is consumer/example logic.
Stale candidate.
It should not remain open as if Slate core owes this behavior.
close-stale
Answer it as example/plugin logic, not as engine work.
None.
Not a core test candidate.
In Safari browser, when the last node is a block node, the cursor position will be misalignedzhugexiaogou666bug, ⚑ cross platform0This is almost certainly a Safari selection boundary bug, but the issue is too thin to classify confidently beyond that.
No thread, minimal body, only a video.
Weak.
Unknown.
Unclear.
Needs a real repro before it deserves more weight.
ask-for-repro
Request a minimal repro or clearer exact steps. Do not guess from the video alone.
Indirect.
Blocked on repro.
Slate-vue3 has been released and all test cases have passed. Welcome to try it outGuan-Erjiafeature0This is an ecosystem announcement, not an issue.
There is no thread and no problem statement.
Not applicable.
Not applicable.
Invalid.
Out-of-scope announcement.
close-invalid
No reply needed beyond closure if this is ever cleaned up.
None.
Not a test candidate.
The cursor is not shifted to the left as expectedlindadadebug, ⚑ cross platform, android1This is another real Android cursor/selection drift report under repeated insert/delete of the same character.
The only comment asks for help, so the body still carries the classification.
Strong enough from the official-site repro plus videos.
Poor.
Valid.
This belongs in the same Android selection-sync cluster as several later issues.
keep-open
Simple acknowledgement is enough unless someone can narrow the exact event sequence further.
Direct.
Ready with minor setup.
Slate is adding link (inline bode) next to text nodesewellstephensbug2This is not a Slate core bug. The thread resolves it to consumer link-element rendering logic.
The reporter partially resolves it themselves, and a contributor later explains the concrete rendering mistake with a fixed sandbox.
Resolved in-thread.
Strong.
Stale candidate.
This is solved consumer code, not active engine work.
close-stale
Close it with the fixed sandbox reference if needed.
None.
Not a test candidate.
onBlur not called while composing (Japanese or Korean)Benrskibug, ⚑ cross platform0This is a credible composition/focus-lifecycle bug, specifically on empty editors during non-Latin composition.
No thread yet, but the body is strong enough: repro, sandbox, and a plausible suspect condition in the code.
Strong.
Poor.
Likely valid.
This fits the broader composition/focus lifecycle cluster.
keep-open
Good next step is confirming whether this is empty-editor-specific and whether other browsers show the same blur suppression.
Direct.
Ready with minor setup.
Unexpected auto-scrolling behavior when refocus the editorederzzbug0This is a plausible focus/selection restoration bug where refocusing a long editor scrolls unexpectedly to the old position.
No thread yet, but the body is concrete and includes a sandbox plus a code pointer.
Strong.
Unknown.
Likely valid.
Low duplicate signal so far.
keep-open
Ask whether the stale selection survives even after an explicit DOM click target change if the first repro attempt is unclear.
Direct.
Ready now.
Copy and paste not copying style on iOSquentingrchrbug, ⚑ cross platform1This is really an HTML-deserialization capability gap, not a simple bug. iOS Notes emits non-semantic HTML and Slate’s example parser does not interpret that styling.
The contributor reply is the useful answer: explains the clipboard formats, shows why the pasted HTML is awkward, and points at Plate’s richer CSS-aware deserializer.
Strong.
Acceptable. Use richer HTML parsing if this matters.
Likely invalid as a current Slate core bug.
This should be treated as parser-capability scope, not as a mysterious paste regression.
close-invalid
Keep the answer grounded in parser scope and non-semantic clipboard HTML.
Indirect.
Not a direct core test candidate.
Cannot get the leaf node at path [0,0] because it refers to a non-leaf node.CaseSensbug2This looks like a crash at first, but the thread points at outdated/currently incorrect editor-value swapping patterns instead of a live core bug.
The important comment explains that the sandbox is on older behavior and that swapping document content in newer Slate needs different handling.
Weak as a current-version issue.
Acceptable. The thread already lists viable patterns.
Likely invalid.
This is another consumer integration misuse thread, not a v2 signal.
close-invalid
Answer with the current supported patterns and close.
None.
Not a test candidate.
Debugger and Paused Rendering Break Slate's renderLeaf and decorator Functionsvodolazskikhbug0This is debugger/pause-mode pain, but the issue is too thin to know whether the culprit is Slate, React, or the debugger environment.
No thread yet.
Weak.
Unknown.
Unclear.
Needs much sharper isolation before it deserves real weight.
ask-for-scope-clarification
Ask for a minimal repro and whether the problem persists without custom decorators.
Indirect.
Not a worthwhile first test candidate.
Could not completely normalize the editor after 3150 iterations!ilya2204bug0This is a high-signal normalization conflict report after a known built-in normalization change.
No thread yet, but the body already identifies the seam: custom wrap normalization now fights built-in unwrap behavior.
The report already points at PR #5768 as the likely trigger.
Moderate but plausible.
Acceptable for the reporter, but that does not erase the regression risk.
Valid.
This belongs in the custom-normalization conflict cluster.
keep-open
Useful next reply would ask for a reduced repro of the wrap/unwrap loop if one does not already exist internally.
Direct.
Ready now around custom normalization loop behavior.
Selection is empty when sliding to select a custom inline element such as a buttondaifuyangbug0This is a likely valid custom-inline selection bug: drag-selection over the inline yields no selection where one is expected.
No thread yet, but the body has a sandbox and a clear interaction difference between drag selection and keyboard selection.
Strong.
Unknown.
Likely valid.
This fits the custom-inline selection cluster cleanly.
keep-open
No need to ask for more until someone checks the sandbox.
Direct.
Ready with minor setup.
Cannot Input Chinese Characters in Comments Feature in iphone Mobile Modelizheng-steedosbug, ⚑ cross platform2This is a real iPhone Safari composition/input bug in the comments example or comments-like flows.
The thread is useful because it includes a known workaround adapted from ProseMirror, with a zero-width-space hack around deleteCompositionText.
Related Liveblocks issue #2194 and ProseMirror issue #934 are both relevant context.
Strong.
Acceptable in the ugly, browser-specific sense.
Likely valid.
This belongs in the mobile composition/deletion cluster.
keep-open
If anyone replies, the useful move is to confirm whether the workaround points at a Slate seam we should own or just another Safari workaround bucket.
Direct.
Ready with minor setup.
Input box quickly input file insertion problemssnwzcimprovement0This is too thin right now. It sounds like a first-focus / fast-input positioning bug for symbols like @, but the issue body is barely above a caption.
No thread.
Weak.
Unknown.
Unclear.
Needs real repro steps before it should influence planning.
ask-for-repro
Ask for a sandbox and exact key sequence. Anything else is guesswork.
Indirect.
Blocked on repro.
Issues when updating linting rulesdylansbug1This is repo/tooling debt, not editor architecture.
The issue is still basically an inventory of lint failures after a config change, plus one volunteer asking to fix it.
Strong enough for repo maintenance.
None.
Valid, but out of scope for Slate v2 architecture.
Keep it out of product/runtime clustering.
keep-open
If touched again, treat it as repo-maintenance work, not framework strategy.
None.
Not a test candidate.
After the Vite hot reload, I was unable to edit or input againimmortal-oebug1This smells like HMR/runtime integration trouble, but the issue body is basically a pasted component and a symptom.
There is no real triage thread, just another user saying they saw it too.
Weak to moderate.
Poor.
Unclear.
Needs a narrower repro before it deserves strong conclusions.
ask-for-scope-clarification
Ask for a minimal repo and whether the problem still exists on current Vite/React versions.
Indirect.
Blocked on repro.
Exception between Select and Anchor Operations in Collaborationelectroluxcodebug0This is one of the strongest collaboration issues in the set: local selection stability breaks under aggressive remote edits in the same block.
No follow-up thread, but the body is rich: video, code, a synthetic 50 QPS remote-edit workload, and specific selection failure modes.
Strong.
None.
Likely valid.
This should stay in the top collaboration cluster until disproven.
keep-open
A useful next move is to isolate which selection transforms are expected under remote ops versus which are clearly wrong.
Direct. If a v2 engine weakens collaboration semantics, it’s dead on arrival.
Ready with minor setup. The workload is already explicit.