docs/slate-issues/open-issues-dossiers/5129-5066.md
JosNunfeature2Changing a node type with setNodes is awkward because it preserves or drops the wrong fields; the request is really for a first-class replace/rewrap transform.
Thread is a straightforward feature request with light follow-up, not a disputed bug.
Strong enough.
Acceptable.
Valid.
Keep it in the right cluster and do not let it drift into unrelated themes.
v2-roadmap
Capture it as roadmap input instead of treating it like routine bug debt.
Direct.
Not a direct test candidate.
dylansbug0This is browser-support cleanup: the old beforeinput polyfill should probably disappear now that the modern event exists everywhere Slate cares about.
No real thread yet; the value here is the cleanup direction, not extra reproduction detail.
Strong enough.
Strong.
Valid.
Keep it in the right cluster and do not let it drift into unrelated themes.
fix-current-architecture
Treat it as support-matrix cleanup, not as a user-facing bug story.
Indirect.
Not a direct test candidate.
yom-electbug, ⚑ cross platform8Chrome changed something about selection or caret behavior and Slate started placing the cursor wrong in a previously working editing path.
Thread adds confirmations and debugging notes, which makes it look like a real browser-triggered regression rather than one bad integration.
Strong enough.
Poor.
Likely valid.
Keep it in the right cluster and do not let it drift into unrelated themes.
keep-open
Keep it open and narrow the exact selection seam instead of arguing from browser version vibes.
Indirect.
Ready with minor setup.
idonovbug1Placeholder min-height from one editor leaks onto another when multiple editors are mounted, which means the measurement or cache key is shared too broadly.
Thread is short, but the bug shape is already clear from the report.
Strong enough.
Acceptable.
Valid.
Keep it in the right cluster and do not let it drift into unrelated themes.
keep-open
Treat it as a runtime identity/isolation bug, not as placeholder styling trivia.
Direct.
Ready now.
onzagbug1mergeNodes behavior and documentation do not line up cleanly; this looks more like contract ambiguity than a fresh algorithmic bug.
The follow-up pushes on docs and semantics more than on a clean current regression.
Strong enough.
Acceptable.
Likely valid.
Keep it in the right cluster and do not let it drift into unrelated themes.
share-status
Clarify the contract first. If the docs are wrong, fix that before calling it a deeper engine bug.
Indirect.
Not a direct test candidate.
beaugundersonbug36This is a Chrome 105 regression report against very old Slate packages, so it is useful history but not a strong current-Slate signal.
The thread is valuable archaeology, but it is pinned to pre-modern Slate versions.
Strong enough.
Poor.
Stale candidate.
This issue is mostly stale history now.
close-stale
Point at unsupported legacy versions and close it instead of letting it pollute current architecture work.
None.
Not a direct test candidate.
HAS_INPUT_EVENTS_LEVEL_2 is bug in chrome@105+ (Slate 0.47)WuQiuYangbug6Older Slate relied on a browser capability flag that Chrome 105 made less trustworthy, which is another piece of legacy browser-detection debt.
Thread is mostly legacy detection debate, not a current contract question.
Strong enough.
Acceptable.
Stale candidate.
This issue is mostly stale history now.
close-stale
Keep it as browser-support history, not as active v2 architecture pressure.
None.
Not a direct test candidate.
kledkbug, ⚑ cross platform1findEventRange in shadow DOM blows up because the browser point-to-range API does not line up with Slate expectations inside a shadow root.
The follow-up usefully points at Chrome shadow DOM limitations, which sharpens the seam instead of weakening it.
Strong enough.
Poor.
Valid.
Keep it in the right cluster and do not let it drift into unrelated themes.
keep-open
Keep it open as real shadow-DOM selection work, not as random browser weirdness.
Direct.
Ready now.
Sotatek-TiepLebug1This is an example limitation: search highlighting with decorations needs cross-node logic, and the example only decorates per text node.
The first comment already explains why the example behaves that way.
Strong enough.
Strong.
Invalid.
This is mostly unsupported or invalid current-contract behavior.
close-invalid
Explain the example limit and close it. This is not core editor breakage.
None.
Not a direct test candidate.
Shenpoyuanbug4On Android, pressing backspace in an empty editor clears the placeholder state incorrectly, which is another empty-state input bug.
Thread has maintainer acknowledgment, which is enough to treat this as part of the real Android empty-state cluster.
Strong enough.
Poor.
Valid.
Keep it in the right cluster and do not let it drift into unrelated themes.
keep-open
Keep it in the mobile empty-state cluster, not as a one-off placeholder bug.
Direct.
Ready with minor setup.
ugrinovskybug0Safari spellcheck behaves badly with Cyrillic text inside Slate after a few words, which points at external spellcheck and browser text-system interaction.
There is no thread yet, so the browser-vs-Slate boundary is still somewhat fuzzy.
Strong enough.
Poor.
Likely valid.
Keep it in the right cluster and do not let it drift into unrelated themes.
keep-open
Keep it open, but do not overclaim ownership until reproduction narrows the browser boundary more.
Indirect.
Blocked on a tighter repro.
ugrinovskybug0The same spellcheck failure shows up on iOS Safari with Cyrillic text, which strengthens the cross-browser Apple text-system angle.
No extra thread yet, but it clearly reinforces the Safari spellcheck cluster instead of standing alone.
Strong enough.
Poor.
Likely valid.
Keep it in the right cluster and do not let it drift into unrelated themes.
keep-open
Treat it as recurrence signal for the Safari/Cyrillic text-system issue.
Indirect.
Blocked on a tighter repro.
mikerhyssmithbug0Inserting a fragment that spans multiple blocks flattens or merges content incorrectly instead of preserving the block structure.
No follow-up was needed; the repro shape is already clear from the issue.
Strong enough.
Poor.
Valid.
Keep it in the right cluster and do not let it drift into unrelated themes.
keep-open
Keep it as a clean current transform bug with a direct public test seam.
Direct.
Ready now.
vercamachbug1scrollSelectionIntoView no longer fully suppresses scrolling after an update, so the customization seam is weaker than it claims to be.
The follow-up confirms it is still broken, which is enough to keep it in the active runtime pile.
Strong enough.
Acceptable.
Valid.
Keep it in the right cluster and do not let it drift into unrelated themes.
keep-open
Treat it as a contract regression in the selection bridge, not as app-specific sticky-toolbar noise.
Indirect.
Ready now.
stefanlibug2Selecting an inline void exposes the spacer span visually, which means the selection/rendering hack leaks into user-facing UI.
The update about visibility: hidden not being safe is useful and keeps this grounded in the real seam instead of a CSS band-aid.
Strong enough.
Acceptable.
Valid.
Keep it in the right cluster and do not let it drift into unrelated themes.
keep-open
Keep it open as selection rendering debt.
Indirect.
Ready now.
chrisfernandes102bug0Replacing an expanded selection by typing can crash because the path lookup goes null in the replace path.
No thread yet, but the error shape is concrete enough to test directly.
Strong enough.
Poor.
Likely valid.
Keep it in the right cluster and do not let it drift into unrelated themes.
keep-open
Keep it as a real replacement-path bug until proven otherwise.
Direct.
Ready now.
jiazhengbug, ⚑ cross platform0Expanding a selection and then composing Chinese text breaks the DOM/model relationship and can throw outright.
The issue is clean enough on its own; no extra thread was needed to show this is real IME-selection breakage.
Strong enough.
Poor.
Valid.
Keep it in the right cluster and do not let it drift into unrelated themes.
keep-open
Keep it in the mobile/selection cluster, not as generic CJK noise.
Direct.
Ready with minor setup.
Jokcybug1Deleting an empty paragraph next to an empty list item normalizes the previous list item into a paragraph unexpectedly.
The comment is a partial debugging note, but the behavioral seam is already sharp.
Strong enough.
Poor.
Valid.
Keep it in the right cluster and do not let it drift into unrelated themes.
keep-open
Keep it open as a clean normalization regression.
Direct.
Ready now.
Editor.nodes option reverse: true only partially reverses output.bebbibug4Editor.nodes(..., { reverse: true }) does not fully reverse traversal order when nested matches are involved.
The follow-up confirms others hit the same semantic mismatch in real code.
Strong enough.
Acceptable.
Valid.
Keep it in the right cluster and do not let it drift into unrelated themes.
keep-open
Keep it as a public API correctness issue, not a docs nit.
Direct.
Ready now.
YasinChanbug, ⚑ cross platform2Android does not surface text insert/remove operations through onChange during composition, leaving children and selection stale in user code.
The workaround in the thread is exactly the kind of bad app-layer patch that proves the runtime seam is real.
Strong enough.
Poor.
Valid.
Keep it in the right cluster and do not let it drift into unrelated themes.
keep-open
Keep it in the Android onChange cluster and do not let the workaround excuse the bug.
Direct.
Ready with minor setup.
nielpattinbug1The example typing pattern indexes a Node with a string key and TypeScript hates it; this is mostly example typing friction.
The follow-up workaround is a type escape hatch, not a real resolution.
Strong enough.
Acceptable.
Valid.
Keep it in the right cluster and do not let it drift into unrelated themes.
keep-open
Treat it as example typing debt, not as deep core breakage.
Indirect.
Not a direct test candidate.
CuriousCorrelationimprovement0The example Portal component can desync React tree assumptions from the DOM tree, which makes the official example itself a bad pattern.
No thread yet, but the issue already names the bad code path precisely.
Strong enough.
Poor.
Valid.
Keep it in the right cluster and do not let it drift into unrelated themes.
keep-open
Fix the example. Do not let official examples teach runtime footguns.
Indirect.
Ready now.
kamnakisbug3Keyboard selection across line boundaries behaves oddly, but the first comment says many editors share the same limitation, so ownership is fuzzy.
The comment muddies ownership enough that this should not be treated as a clean Slate bug without a tighter repro.
Weak.
Acceptable.
Unclear.
Keep it in the right cluster and do not let it drift into unrelated themes.
ask-for-scope-clarification
Ask for a sharper comparison against browser/native behavior before promoting it.
Indirect.
Blocked on a tighter repro.
PravunathSinghimprovement0This is an export request for PDF and DOCX, which is an ecosystem adapter problem more than a Slate core gap.
No thread yet. The ask is clear, but it is still an ecosystem integration story.
Strong enough.
Acceptable.
Valid.
Keep it in the right cluster and do not let it drift into unrelated themes.
share-status
Point at serialization/adapter ownership rather than bloating Slate core.
None.
Not a direct test candidate.
OldDreambug2Editing text before an inline element with Sogou IME can crash, which matches the existing inline-boundary IME failure family.
The thread already points at #5762, which is good enough duplicate evidence.
Strong enough.
Poor.
Valid.
Treat this as a duplicate of #5762.
mark-duplicate
Point at the stronger duplicate and consolidate the cluster instead of carrying parallel copies.
Direct.
Ready with minor setup.