docs/slate-issues/open-issues-dossiers/3797-3708.md
mdmjgnone1This is basically an example-scope request, not a core editor capability gap.
The maintainer reply already pushes it in the right direction by asking whether it belongs to the example rather than to Slate itself.
Strong enough.
None.
Invalid.
Treat it as example-scope feature chatter, not architecture pressure.
share-status
Reply with scope/status rather than converting it into core roadmap debt.
None.
gmathieunone0The behavior is real, but it reads like cross-browser selection convention pain more than a robust Slate-owned defect.
There is no deeper thread to rescue it from that read.
Strong enough.
None.
Likely invalid.
Keep it de-weighted as browser convention pain unless a stronger Slate-owned seam appears.
share-status
Share status instead of pretending this is a straightforward editor bug.
None.
saschahofmannnone0This is testing infrastructure pain, but it is legitimate: Slate React makes drop handling hard to exercise in jsdom without hitting assumptions.
There is no long thread, but the issue is clear enough and useful for maintainer ergonomics.
Strong enough.
Poor.
Valid.
Keep it in test-surface debt, not product architecture.
share-status
Share status or leave a maintainer breadcrumb about supported test surfaces.
Indirect.
mwood23bug, typescript2This is a straightforward type-surface mismatch: the placeholder element props are not typed precisely enough for real use.
The thread is light, but that is fine. The issue is narrow and concrete.
Strong enough.
Acceptable.
Valid.
Keep it in the typing bucket, not runtime architecture.
share-status
Reply with scope/status or accept a small type-surface fix.
Indirect.
mwood23improvement, ♥ help2This is a low-drama but legitimate UI hook request: people want stable styling hooks for placeholder UI.
The thread is quiet, which is fine. The ask is small and clear.
Strong enough.
Acceptable.
Valid.
Low urgency, but legitimate runtime-surface pressure.
v2-roadmap
Reply with scope/status instead of treating it like a must-fix bug.
Indirect.
slotterbackWnone1This is a clean empty-state input bug: accented composition at the start of a new line still crashes in Firefox.
The later comment broadens it usefully: this is not one accent key, it is the empty-editor/newline plus IME path.
Strong enough.
Poor.
Valid.
Keep it open as placeholder and empty-state IME debt.
keep-open
Acknowledge the issue and keep it tied to empty-state composition handling.
Direct.
shomukainone3Enter at the end of an inline link still creates bogus empty inline content instead of a clean text boundary.
The workaround comment helps by proving the issue lives on the public insert-break plus inline-boundary seam.
Strong enough.
Acceptable.
Valid.
Keep it open as insert-break debt around inline boundaries.
keep-open
Acknowledge the issue and keep it tied to insert-break behavior around inlines.
Direct.
MustafaFarisnone0This is ecosystem package support noise around the old HTML serializer, not core Slate direction.
There is no meaningful thread to upgrade it into anything more serious.
Strong enough.
None.
Invalid.
Keep it out of current Slate architecture pressure.
close-invalid
Point at ecosystem package scope if it ever needs a reply at all.
None.
krvikash35none1This is just a support question about walking list nodes, not a sign that Slate’s data model is failing.
There is no thread evolution beyond the question itself.
Strong enough.
None.
Invalid.
Keep it out of architecture work entirely.
close-invalid
Share usage guidance if needed, otherwise close as support noise.
None.
dminkovskynone3This is a valid request, but it is really a current-surface limitation issue: people want the native iOS selection toolbar to own formatting.
The maintainer reply is the whole point. It already says the current contenteditable model cannot support this cleanly, which makes it strong v2 signal.
Strong enough.
None.
Valid.
Keep it on the v2 roadmap as surface-model pressure, not as a near-term bug.
v2-roadmap
Share status honestly: this wants a different surface model, not a tiny patch.
Direct.
maksidonnone0Selected checkbox-only content still behaves badly under delete/cut, which keeps landing in the structural-block deletion pile.
There is no big thread, but the issue is concrete enough to keep.
Strong enough.
Poor.
Valid.
Keep it open as structural deletion debt around checkbox-like blocks.
keep-open
Acknowledge the issue and keep it tied to expanded-selection deletion.
Direct.
TheSpydernone10Undo selection restoration in slate-history looked wrong here, but the later thread suggests the issue may have been overtaken by later fixes.
That makes it useful, but not clean active bug pressure. It is better as historical context for history semantics than as a top current issue.
The thread later points at PR #4717, which means this may already be partially or fully resolved by later history work.
Strong enough.
Poor.
Stale candidate.
Keep it de-weighted unless someone revalidates it on current Slate.
share-status
Share status and point at the later fix path instead of treating it like fresh breakage.
Direct.
silviubogannone3This is another current-contract mismatch: the reported failure depends on invalid or non-normalized empty-state structure.
The comments are useful because they point back to normalization and valid element structure rather than a broken insert operation.
Strong enough.
Strong.
Invalid.
Close it as contract mismatch unless someone provides a valid normalized repro.
close-invalid
Point at the normalization and valid-element contract rather than leaving it open as core bug debt.
None.
app/bug, ♥ help2This is a real history memory-retention report, not vague perf whining: repeated edit churn with history enabled appears to hold onto detached editor-linked memory.
The later thread matters because it proposes a plausible root cause around retained operation payloads, which makes this much better than a generic “memory leak?” issue.
Strong enough.
Poor.
Valid.
Keep it open as history-memory debt and benchmark input.
keep-open
Acknowledge the issue and keep it tied to history retention rather than generic performance.
Indirect.
jolanglinaisnone4Nested-leaf decoration behavior is still brittle enough that users end up reaching for memoization and workarounds.
The workaround is the interesting part. It proves the issue belongs to renderer invalidation breadth, not just one incorrect decoration result.
Strong enough.
Acceptable.
Valid.
Keep it in the slate-react invalidation bucket, not general bug sludge.
share-status
Share status and keep it tied to render breadth and decoration invalidation.
Direct.
zbeyensnone0Wrap and unwrap transforms still blow through too much React work, which is exactly the runtime breadth problem that keeps recurring.
The issue body is already strong. It ties rerender breadth to observable downstream cost instead of just “too many renders.”.
Strong enough.
Poor.
Valid.
Keep it in the renderer breadth bucket, not generic transform bugs.
share-status
Share status and keep it tied to subtree invalidation breadth.
Direct.
ksimonsnone1This was real touchbar autocomplete flicker pain, but it now reads more like resolved history than live architecture signal.
The thread is thin and mostly valuable because it points at the likely fix PR.
The only useful later signal is PR #3293, which appears to be the fix path for the original report.
Strong enough.
None.
Stale candidate.
De-weight it unless someone revalidates it on a current build.
close-stale
Share status and point at the old fix path instead of treating it like fresh debt.
None.
Node[] type but should return Element[] typethesunnynone3This is a clean type-surface issue: editor.children is typed wider than the actual normalized contract suggests.
The comments are useful because they show the change is not a one-line tweak. It has real ripple effects through the API surface.
Strong enough.
Acceptable.
Valid.
Keep it on the type-surface and data-model design pile.
v2-roadmap
Reply with scope/status instead of pretending it is a tiny isolated typing patch.
Direct.
spudlynone1This is strong cross-window runtime debt: onChange can break when the editor is rendered into another tab, window, or document.
The issue does not need much thread to prove itself. It cleanly points at document ownership assumptions leaking into runtime behavior.
Strong enough.
Poor.
Valid.
Keep it open as external DOM ownership debt.
keep-open
Acknowledge the issue and keep it tied to cross-document ownership rather than generic event weirdness.
Direct.
wlerouxnone2This is a real operation-model limitation: move_node does not carry enough information for some collaboration and undo layers to reason correctly.
The comments are strong and technical. They talk through OT semantics and prove this is not just API taste.
Strong enough.
None.
Valid.
Keep it in the operation-model and collaboration design bucket.
v2-roadmap
Reply with scope/status and treat it as operation-model design pressure, not a patch-sized ask.
Direct.
grandsongnone4This is a real annoyance, but it still reads mostly like browser selection convention pressure rather than strong Slate-owned debt.
The later comments make the pain feel real, but they do not move ownership clearly into Slate.
Strong enough.
None.
Likely invalid.
Keep it de-weighted unless someone proves a clearly Slate-owned selection bridge failure.
share-status
Share status instead of overcommitting to what is mostly convention-level browser behavior.
None.
ncqwernone3This is another DOM-point resolution thread, but it is better treated as duplicate noise than as independent architecture signal.
The most useful part is the workaround comment, which makes it even less worth keeping as a stand-alone issue.
The thread reads like another descendant of Issue #3421, and the last comment effectively resolves it with a workaround.
Strong enough.
Acceptable.
Duplicate candidate.
Point it at the better DOM-point parent if anyone ever revisits it.
close-duplicate
Share the duplicate/workaround path instead of keeping it as a separate source of truth.
Indirect.
thesunny♥ help, docs, examples, ⚑ collaboration6Collaboration docs demand is real. People keep reaching for this and finding no official example or maintained guidance.
The comments make it concrete and example-oriented, which is exactly why it belongs in docs and roadmap pressure instead of being dismissed as vague demand.
Strong enough.
Poor.
Direct.
Keep it in docs and roadmap pressure, not bug counts.
v2-roadmap
Reply with scope/status instead of pretending collaboration docs are already covered.
Direct.
nnurmanobug, ♥ help, examples, ignored-template4This older paste-html newline bug folds cleanly into the later HTML example newline thread.
The thread already does the duplicate work for us, which means this should not keep polluting architecture counts.
The last comment already points at Issue #4268, which is the cleaner home for the HTML example newline problem.
Strong enough.
Acceptable.
Duplicate candidate.
Point it at the later example newline issue and move on.
close-duplicate
Share the duplicate target instead of keeping two copies of the same example bug alive.
None.
akiwong-cnnone2Mark mutation followed by immediate insertText still crashes under React event timing, which is a very clean timing-order bug.
The workaround matters because it shows the failure is about immediate sequencing, not about marks themselves being fundamentally broken.
Strong enough.
Acceptable.
Valid.
Keep it open as timing-order debt around mark mutation and insertText.
keep-open
Acknowledge the issue and keep it tied to immediate operation timing after mark changes.
Direct.