docs/slate-issues/open-issues-dossiers/6038-6007.md
These dossiers cover issues #6038 through #6007 from the pilot set. Use the top-level index for the range map and the ledger for the canonical structured cache.
Perf: repeated tree updates need a batch-aware apply enginezbeyens0This is a maintainer-authored architecture/performance tracking issue, not a user bug report. It frames a repeated-tree-update performance cliff in Slate as a batch-engine problem rather than a narrow set_node helper request, and it explicitly records the desired semantics for any upstream fix.
There is no thread yet. The body already does the real work: requirements, rationale, benchmark context, and the active implementation link are all in one place.
Linked PR #6039 is the active implementation thread and should be treated as part of the issue context.
Repro is effectively confirmed by the attached benchmark command and the linked PR. This is not waiting on a user repro.
No user-facing workaround is proposed. The issue is about fixing the engine, not avoiding it.
Valid. This is a real current-architecture issue, already backed by implementation work and benchmark data.
Not a duplicate candidate in the normal tracker sense. It is the canonical architecture-tracking issue for this batch-engine line.
fix-current-architecture
No reply is needed unless the linked PR scope changes. If a reply is posted, it should stay narrow: status of the engine work, what is already proven, and what remains to justify further optimization.
Direct. This issue is basically a miniature argument for transaction-aware execution, private draft state, and better batch semantics. Even if the current rewrite lands, the underlying lesson still feeds a v2 engine model.
Not a direct test candidate. Use this issue as a parent architecture ticket and extract smaller behavior tests from it instead.
Ready now. Use the existing Slate perf harness as the benchmark seam and keep the workload broken down by operation family and mixed-batch shape instead of hiding everything in one giant lane.
Cursor moves to wrong position when pressing down arrow at end of table that is last nodeBiosSunbug0This is a DOM-selection escape bug around table boundaries. When the table is the last node, arrow navigation allows the browser selection to end up outside the valid editor position, and the next character inserts in two places. The same class of failure appears at the top boundary with the up arrow.
There is no comment thread yet. The issue body is clean: repro steps, recording, official example URL, and expected behavior are already present.
Likely reproducible from the official table example exactly as written. This is already better than the average bug report.
Poor. The obvious workaround is “don’t leave the table as the boundary node,” which is not a serious answer.
Likely valid. The report is specific and grounded in the official example.
Low duplicate risk from the pilot alone. It may eventually cluster with other boundary-selection issues, but nothing in this thread suggests it is invalid or stale.
keep-open
A short acknowledgement would help. The useful next maintainer move is to confirm repro and note whether this belongs in slate-dom, slate-react, or shared selection logic. No need to ask for more issue details unless the current example no longer reproduces.
Indirect. A React-first transaction engine does not magically solve browser-selection drift, but a cleaner DOM selection bridge and snapshot-driven runtime could reduce this class of boundary desync bug.
Ready now. Start with a DOM integration test around table-boundary arrow navigation and assert valid selection plus single insertion.
[Android] Soft keyboard dismisses and cursor jumps when typing after toggling a mark on a collapsed selectionvirgil1996bug, ⚑ cross platform2This is an Android collapsed-selection mark-toggle bug that immediately turns into a keyboard-dismiss and cursor-jump failure on the next typed character. The core symptom is not just “Android is weird.” It looks like selection state bouncing between stale and new text positions after mark toggling.
The comments make the issue much stronger. The reporter added an Android WebView repro wrapper around the official Slate examples and then posted the exact apply log sequence. That sequence shows an insert_node followed by repeated set_selection oscillation between [0,0] and [0,1], which is dramatically more useful than the body alone.
Strong. The issue has a recording, platform details, official example reference, Android wrapper code, and operation logs.
Poor. The only workaround mentioned implicitly is to apply the mark to a non-collapsed selection instead of toggling it on a collapsed caret. That is a user behavior dodge, not a real workaround.
Valid.
Low duplicate risk from this pilot. It is a real mobile/selection issue with concrete evidence.
keep-open
A useful maintainer reply would acknowledge the extra repro material and narrow the suspected seam: Android IME plus selection synchronization after mark toggles. If more follow-up is needed, ask whether the same failure occurs in Chrome on Android outside the WebView wrapper, but do not ask for generic “more info” nonsense because the thread already has plenty.
Direct. This issue smells like exactly the kind of runtime/selection-timing fragility that a transaction-first, React-first architecture is trying to excise. It is also a warning that mobile and IME behavior need first-class package ownership in any v2 plan, not a footnote.
Ready with minor setup. Start by testing the selection oscillation after collapsed mark toggle plus typing; do not block on reproducing Android keyboard dismissal perfectly in the first red test.
Displaying 2 Slate components with the same initialValue breaks the pagegrose-dgbug2This issue reports a crash when two <Slate> components render concurrently with the same value reference. The visible failure is a findPath error, but the maintainer explanation is more important than the symptom: Slate does not support sharing the same node-object graph across editors because global weak maps are keyed by node identity and can be overwritten across editor instances.
The thread materially changes the triage outcome. The maintainer states clearly that this usage is unsupported and explains why. The reporter then narrows the regression trigger to a specific findPath change in slate-dom, but also agrees their usage is outside the supported model and will be updated.
Strong. The issue has a concrete reproduction shape and an identified regression seam.
Acceptable. Deep-clone the Slate value before using it in either editor.
Likely invalid as a current-contract bug report, even though the crash itself is real.
Not obviously a duplicate from this thread, but it does look like unsupported usage rather than a bug Slate should promise to preserve.
close-invalid
If this gets a final maintainer reply before closure, it should be short and explicit: shared node graphs across concurrent editors are unsupported, deep clone the value, and the current crash/regression explanation is already in the thread.
Direct. Stable identity and editor-scoped bookkeeping are exactly the kind of constraints a v2 architecture should think about deliberately instead of inheriting accidentally.
Ready now if we want to make this a v2 capability test later. For current Slate, it is better treated as an unsupported-usage dossier than as a must-fix regression.
Improvement: Omit initialValue for pre-initialized editor instancesmkoskimimprovement4This is a real React API ergonomics complaint: if an editor instance is already initialized via editor.children, the Slate component still requires initialValue, forcing callers to pass what feels like obsolete or duplicate state.
The discussion is useful and concrete. The maintainer pushes back on the simplest proposal because editor.children defaults to [], which is sometimes intentional, so blindly making initialValue optional would remove an important guardrail. A more nuanced alternative emerges: allow omission, but warn when editor.children is still empty unless the caller explicitly passes initialValue={[]}.
Strong enough. This is a straightforward render-time API behavior, not a flaky runtime issue.
Acceptable. Pass initialValue={editor.children}.
Valid improvement request.
No duplicate signal in the thread. This looks like a legitimate API design question.
v2-roadmap
If a maintainer replies again, the useful move is to acknowledge the ergonomics problem while making the guardrail trade-off explicit. The thread already has the shape of the best current idea.
Direct. A React-first v2 should not force callers to thread redundant initialization props just to satisfy runtime ambiguity inherited from the current model.
Ready now. This can become a clean red React integration test around rendering <Slate editor={preinitializedEditor}> without initialValue.
NPM and GitHub latest releases do not concurjwoytekimprovement2This is not an editor-engine problem. It is a release-process integrity complaint: npm and GitHub releases/tags disagree, which is bad for supply-chain verification and trust.
The thread does the important triage already. A maintainer points to closed issue #6002 as the likely source. The reporter agrees that the issue may simply be a duplicate or reopening candidate.
Related issue #6002 is the likely canonical thread.
Strong enough for process triage. The problem statement is clear and the duplicate lead is already in the thread.
Poor. The whole point of the issue is that manual cross-checking should not be necessary.
Duplicate candidate.
High duplicate likelihood with #6002.
mark-duplicate
The right reply is short: acknowledge the duplicate target, link #6002, and close or consolidate. Do not let this sit open pretending it is a separate roadmap input.
None. This is release hygiene, not architecture direction.
Not a test candidate. This belongs in release-process verification, not editor TDD.