docs/slate-issues/open-issues-dossiers/5994-5918.md
These dossiers cover issues #5994 through #5918 from the pilot set. Use the top-level index for the range map and the ledger for the canonical structured cache.
【examples/mentions】Unexpected position of cursor when backspacezindler323bug0This looks like a selection-boundary bug in the mentions example. After creating a new line after a trailing mention and then backspacing that line away, the cursor disappears and the mention becomes selected instead.
There is no thread. The problem is the repro reliability: the reporter says it happens on a local checkout of main, but not on the deployed official example.
Unclear. The steps are concrete, but the environment discrepancy matters.
Poor.
Unclear.
No duplicate signal yet. This needs reproduction before it deserves stronger conclusions.
ask-for-repro
Ask for a tighter repro: exact commit or local diff, and whether the issue still reproduces in a clean local checkout of the example.
Indirect. It is another signal that inline/selection boundary behavior is still fragile, but the issue is too underconfirmed to carry much architectural weight yet.
Blocked on repro. Do not write a test from this yet.
In the case of large documents, using the cut function took a lot of time.Guan-Erjiabug0This is a large-document performance complaint against the huge-document example. Cutting a selection in a 50,000-block document is reported as excessively slow, with the reporter pointing at array destructuring cost in the profile.
No thread yet. The issue is thin but still useful because it names a concrete workload and example URL instead of just saying “Slate is slow.”
Likely reproducible from the official huge-document example.
Poor.
Likely valid.
No duplicate signal in the thread.
keep-open
If a maintainer replies, the useful move is to acknowledge the workload and push it toward a benchmark/profiling lane instead of generic bug back-and-forth.
Direct. This is exactly the kind of workload that pressures execution model and scaling choices.
This is really a benchmark candidate, not a classic red-test candidate. The right artifact is a reproducible perf lane.
Ready with minor setup. The right next move is a stable huge-document cut benchmark with a fixed document generator, fixed selection shape, and cut through the public transform path.
[Chrome, Android] The Hangul composition breaks on the first character when the placeholder is visiblemugglimbug, ⚑ cross platform1This is a strong Android IME bug report: with placeholder visible, the first Hangul composition does not combine into a syllable correctly and instead inserts separate characters.
The only comment is a ping, so the body carries almost all the value. It is still a good report: official example, exact sequence, platform, and a plausible hint that placeholder rendering is involved.
Strong.
Poor.
Valid.
No duplicate signal in the thread.
keep-open
Acknowledge and narrow the likely seam: Android composition plus placeholder/empty-state handling.
Direct. This is another signal that mobile IME and empty-state behavior need to be first-class in runtime design.
Ready with minor setup. First red test should target the composition result, not every browser-level IME nuance at once.
Caret jumps to wrong position when decorate callback changes from async state updatedannelundqvistbug1This is a real slate-react stability bug: when decorate changes from an async state update, the caret can jump to the wrong position when the new decorations apply.
The maintainer reply is useful and specific. It ties the issue to a known decoration rewrite, suspects DOM remount plus selectionchange, and points directly at the likely source files. That is real evidence, not hand-waving.
Strong. The issue includes a sandbox and a stable async timing trigger.
Poor. The reported workaround is a hacky deselect/reselect after a timeout.
Valid.
No duplicate signal in the thread.
keep-open
Share status if more is known. Otherwise the issue already has a useful maintainer breadcrumb and should remain a good test candidate.
Direct. This is exactly the sort of render/subscription/selection timing garbage a transaction-plus-snapshot runtime is meant to reduce.
Ready now. This wants a React integration test around async decoration updates and selection stability.
Android Chinese Input Issue: Backspace requires two presses to trigger one onChange eventXXPermanentXXbug, ⚑ cross platform1This is a high-signal Android Chinese IME bug: one backspace press does not trigger the expected single delete/onChange, while the second press deletes twice.
The comment is interesting because it links a PR and claims a root cause/fix, but it is not maintainer-verified. That raises the value of the issue, but it does not close it.
Linked PR #5985 may contain useful debugging or fix context, but it should not be trusted without review.
Strong. The issue includes minimal code and a very clear behavior contract.
Poor.
Valid.
No duplicate signal in the thread.
keep-open
Share status around the linked PR or confirm whether that line of investigation is still considered plausible.
Direct. This is another concrete mobile IME editing-semantics failure.
Ready with minor setup. The first useful test is about delete semantics and emitted state change, not every browser/input-method combination.
When the content is empty, the first voice input on Android repeatsmayingjie123bug, ⚑ cross platform0This is a voice-input duplication bug on Android when the editor is empty. The first dictated input repeats, while the same flow behaves normally if the editor already contains content.
No thread yet. The body is still decent: official example, specific IMEs, and a clear empty-vs-non-empty distinction.
Likely valid from the official example.
Poor.
Likely valid.
No duplicate signal in the thread.
keep-open
Short acknowledgement is enough for now. The next useful step is reproduction and clustering with other Android empty-state input issues.
Direct. Empty-state behavior plus mobile input keeps recurring as a weak seam.
Ready with minor setup. Likely first test should focus on duplicate insertion from empty state, not voice input plumbing itself.
IsOperation method do not handle the custom operationsrighetnbug2This issue starts from custom operations, but the stronger thread conclusion is narrower and more important: Editor.isEditor should not depend so heavily on validating the exact shape of editor.operations.
The comments are the real value here. One maintainer argues that strict editor.operations validation is unnecessary and has already caused performance trouble. Another points out that true custom-operation support is broader and currently awkward across multiple seams. So the issue is not “custom ops fully work today.” The issue is that one current validation seam is too brittle.
Strong enough. The failure mode is concrete and the discussion identifies the architectural seam.
Poor.
Valid.
No duplicate signal in the thread.
fix-current-architecture
If a maintainer replies again, the useful message is to narrow scope: this is about loosening a brittle validation seam, not promising full custom-operation support everywhere.
Direct. It touches the core question of what operations are allowed to mean and how extensibility should work.
Ready now. This can become a test that editor detection does not collapse just because custom operations exist in the operations list.
chrome devtools emulator iPhone devices can't input Chinese charaters.welkangbug2This is a Chinese composition/input complaint, but only in Chrome DevTools iPhone emulation. The reporter also found a workaround by overriding onCompositionEnd with slate-dom internals.
The thread increases technical detail but not confidence. The workaround is invasive and environment-specific, and the issue is still framed around emulator behavior rather than a real device.
Unclear outside the emulator setup.
Acceptable, though ugly.
Unclear.
No duplicate signal in the thread, but this needs scope clarification before it deserves high priority.
ask-for-scope-clarification
Ask whether the failure reproduces on real iOS devices or only in Chrome emulation. That is the key fork.
Indirect. It may just be an emulator quirk, but it still points at fragile composition handling.
Blocked on repro. Emulator-only behavior is too weak a foundation for a serious test.
In the inlines mode, when I delete an input element, the preceding character of that element will also be deleted.elevenwangyangbug2This is a deletion-semantics complaint around empty inline elements. Backspace at the boundary deletes the preceding character instead of just removing the empty inline.
The thread is useful because it exposes both a likely current cause and a real ambiguity. A contributor explains why current 'character' delete behavior leads here and points out that more complex inline cases become murky quickly. The reporter clarifies the desired basic case.
Strong for the simple case.
Poor.
Valid.
No duplicate signal in the thread.
ask-for-scope-clarification
Ask for the desired semantics on the harder nested-inline cases before changing core delete behavior broadly.
Direct. This is core editing semantics, not just example polish.
Ready now for the simple documented case. The harder nested cases can stay as follow-up scope questions.
Warning: Cannot update a component (Slate) while rendering a different component (ForwardRef) in onKeyDown handler when DevTools is openMaxVhanamanebug5This started as a possible Slate/React timing bug, but the thread eventually shows the reporter was still running stale requestAnimationFrame code and the original warning disappeared once that was fixed.
The thread is long but useful. It moves from speculation to proper debugging, and then to resolution by the reporter. The remaining discussion is about a separate decoration-delay issue, not the original warning.
Resolved by the reporter.
Strong. The underlying bad pattern was removed.
Stale candidate.
This should probably be closed unless someone can still reproduce the original warning without the stale code path.
close-stale
Short closure note: the original report appears resolved in-thread; reopen with a minimal repro if the warning still exists independently of requestAnimationFrame.
None.
Not a test candidate. The original report resolved into consumer-side timing misuse.
Burmese IME composing stops working on some combinationslucoceanobug, ⚑ cross platform1This looks serious at first glance: Burmese IME composition stops responding after a specific key sequence in the plaintext example on Windows browsers.
The only comment is the real triage outcome. The reporter later says this is a Chromium issue and links the upstream browser bug directly.
Linked Chromium issue 344767735 is the most important artifact in the thread.
The repro steps are concrete and likely valid, but the current evidence points at browser behavior more than Slate behavior.
Poor. There is no Slate-level workaround in the thread.
Likely invalid as a Slate issue.
This should not stay open as if Slate owns the fix. The current thread points upstream.
close-invalid
Short and explicit: link the Chromium issue, note that the current evidence points upstream, and close unless new Slate-specific evidence appears.
Indirect. It still counts as evidence that input-method behavior is a real pain cluster, but not every member of that cluster will be fixable in Slate.
Not a good Slate test candidate while the thread points at Chromium itself.
no cursorszkj-web-hebug, ⚑ cross platform2This is not a core editor bug. The reported “no cursor” behavior is the caret being visually hidden by the focus ring.
The thread already resolves it. A contributor explains the focus-ring interaction, cites the relevant accessibility guidance, and the reporter acknowledges the answer.
Resolved in thread.
Strong. Adjust the focus ring or padding.
Stale candidate.
This is effectively solved support traffic, not active roadmap input.
close-stale
No long discussion needed. Point at the existing explanation and close.
None.
Not a test candidate. This belongs to consumer styling and accessibility guidance.
DOMEditor.toSlatePoint could find a point in a parent editorchristianhgbug0This is a strong writeup of a nested-editor bug in DOMEditor.toSlatePoint. The important claim is that global DOM-to-node bookkeeping can let a nested editor resolve a point inside the parent editor.
There is no comment thread, but the body is already maintainer-grade: concrete control flow, exact file references, and a plausible mitigation.
Strong enough from the writeup alone.
None in the thread.
Likely valid.
No duplicate or stale signal yet. This should stay open.
keep-open
A useful maintainer reply would acknowledge the nested-editor/global-map angle and confirm whether the proposed mitigation is directionally right.
Direct. This is exactly the kind of cross-editor identity leak that a cleaner runtime and editor-scoped bookkeeping model should avoid.
Ready now. This wants a DOM integration test with nested editors and a point resolution path that currently escapes into the parent editor.
Slow Pasting of Large Text Content in Slate.jselectroluxcodeimprovement2This is a good performance report, not vague whining. It compares large plain-text paste behavior against Tiptap and gives a reproducible workload.
The thread is the useful part. A contributor profiles the path and identifies two concrete costs: repeated normalization during insertData, and isEditor spending O(n^2) time validating editor.operations through isOperationList.
Strong. The workload is explicit and the thread already contains profiler-backed diagnosis.
Poor. The only real answer is to optimize the engine path.
Valid.
Not stale, not invalid, and clearly part of the same large-document performance cluster as other recent perf reports.
fix-current-architecture
The right reply is not “try less text.” It is to acknowledge the workload and point at the normalization and editor-validation costs already identified in-thread.
Direct. It reinforces the case for transaction-aware execution and for removing per-operation overhead from bulk text ingestion.
Not a correctness test candidate. The right artifact is a reproducible perf lane.
Ready now. Start from a large plain-text paste benchmark and make normalization plus editor-validation cost visible instead of hiding everything in one top-line number.
Stable per-line pagination support (avoid flicker at page boundaries)Malek-dotcom-cpuimprovement0This is an advanced-layout request, not a conventional bug. The user wants stable word-processor-style pagination and is fighting measurement feedback loops caused by DOM spacers affecting the next layout pass.
There is no thread yet, so the issue is still one-sided. The body is useful, though: it describes the exact strategy already attempted and why it still flickers.
Weak. The issue mentions a repro link and GIF, but they are not actually present.
Poor. The whole issue exists because the current attempts still oscillate.
Unclear as a current Slate issue, but valuable as a v2 capability signal.
Not stale, but not mature enough to treat as a concrete fix ticket either.
v2-roadmap
If someone replies, the useful move is to ask for the missing minimal repro and keep the conversation focused on whether Slate should own this at all versus leaving it to higher-level layout systems.
Direct. Pagination/layout composition is one of the clearest “custom use case” pressures on the current model.
Not a current TDD candidate. This belongs in architecture requirements first.
DOMEditor.findPath returns no or wrong pathdelijahbug5This is a real render-timing bug: DOMEditor.findPath can throw or return the wrong path in onChange because DOM-index caches update on render, but onChange fires first.
The thread is good. A contributor explains the quirk, points at related issue #5800, gives a workaround using deferred selectors, and the reporter links a PR attempt that fails under tests.
Related issue #5800 and attempted fix PR #5939 are both part of the real context.
Strong. The issue has a sandbox and a crisp four-step repro.
Acceptable. Deferred selector evaluation works, but only by waiting until after render.
Valid.
Not a duplicate. It is part of an existing problem family, but still a live issue in its own right.
keep-open
The useful reply is a narrow status update: related to the broader path-computation problem, workaround exists, easy fixes fail, deeper seam likely needed.
Direct. This is exactly what “transaction-first internally, op-first externally” is supposed to clean up on the runtime side.
Ready now. Write the first red test around DOMEditor.findPath inside onChange after a structural edit, not around private cache maps.
Windows text suggestions append instead of replace in Slate editorAtronybug, ⚑ cross platform0This is a Windows suggestion-acceptance bug. Accepting a suggested completion appends the chosen word after the typed prefix instead of replacing the active word segment.
No thread yet. The body still carries enough weight because it names the exact environment, the exact expected behavior, and the likely event-model seam.
Likely strong, assuming Windows suggestion bars are available in the test environment.
Poor. There is no real Slate-level workaround in the issue.
Likely valid.
No direct duplicate signal, but it clearly belongs in the broader Windows/input-method cluster.
keep-open
A useful maintainer reply would confirm whether this lands in the same seam as composition and beforeinput handling, then ask for any browser differences if repro is attempted.
Direct. This is another case where the runtime/input bridge is doing too much guesswork.
Ready with minor setup. The hard part is the Windows suggestion harness, not the behavioral assertion.
Slash commands (/) don’t trigger command palette on mobile (keydown not firing)MaxVhanamanebug, ⚑ cross platform2This is mostly a consumer integration trap, not a Slate engine bug. The command palette logic was wired to keydown, which is unreliable on Android, and the thread lands on onDOMBeforeInput plus requestAnimationFrame as the practical fix.
The thread already resolves the useful answer. A contributor explains the Android event-model difference, and the reporter confirms the working pattern.
Resolved in thread.
Strong.
Stale candidate.
This should not stay open as an unresolved engine issue.
close-stale
Short closure note: mobile slash-trigger logic belongs on input events, not keydown; the thread already contains the working pattern.
Indirect. It is still useful as evidence that the runtime should not make keydown-driven integrations feel reliable on mobile when they are not.
Not a test candidate. This is a docs/pattern handoff.
Ability to exclude structural DOM elements from contentEditable contextvoi1iimprovement4This is a thoughtful request for a structural-layout affordance: mark some DOM nodes as part of component structure without letting the browser place the caret there.
The thread weakens the case as a current issue. A contributor suggests existing contentEditable={false} plus CSS approaches, and the reporter later says they could no longer reproduce the issue in isolation and that it was likely something local.
No longer credible as a live repro.
Acceptable, at least for the cases discussed in-thread.
Stale candidate.
Not a duplicate, but not a solid current-ticket either.
close-stale
If this gets closed, point at the current workaround discussion and the reporter’s later note that the issue no longer reproduced cleanly.
Direct, but only at the requirements level. It still says something useful about advanced layout composition and structural editing pressure.
Not a current test candidate. Keep it as a capability note, not a failing behavior obligation.
Text input error when typing Vietnamese on Windows OSlongbd-stringeebug1This is another Windows input-method issue. The reported symptoms are duplicated words and broken deletion after committing a Vietnamese word and starting the next one.
The thread is weak. The only comment suggests switching away from the default Windows Vietnamese input method, which is more folklore than maintainer triage.
Weak. The reporter says their app shows one problem and the official example shows a different one.
Acceptable only in the worst sense: “use another IME” is not a real product answer.
Unclear.
This belongs in the Windows/input-method cluster, but the issue itself still needs sharper repro boundaries before it becomes actionable.
ask-for-scope-clarification
Ask for the exact IME, exact browser, and whether the official example can reproduce the same failure mode instead of a related-but-different one.
Direct. Even fuzzy reports like this are telling us the Windows input bridge is a real pain surface.
Blocked on repro. Do not write a fake Windows IME test until the failure shape is narrowed.