* Fix `setNodes()` props argument type
Because Typescript can know which type of nodes we are modifying thanks to the `T` inferred from `match` function,
it can also properly narrow down the `props` argument type.
* Fix TS errors in examples
* Add a changeset
* fix double paste due to insertTextData being called when it should not
* Document return type of insertTextData and insert FragmentData
* Add changeset
* make editor.selection avaliable when Editor is contenteditable="false"
* remove dom selection limition of read-only
* Improve grammar of comments regarding selection when read-only is true
* Add Changeset
Co-authored-by: Xheldon <c1006044256@gmail.com>
* Fix crash when a void node deletes itself on click
Fixes https://github.com/ianstormtaylor/slate/issues/4240
* Add 'image delete' feature to example
My immediate motivation is to demonstrate the bug that this fixes. But
this is also a very common editor feature, and I think it's valuable
to show how to achieve it.
* add changeset
* fix:eslint
* revert changes to mentions.tsx
* Allow typing at the end of an inline
This fixes https://github.com/ianstormtaylor/slate/issues/4524
Steps to reproduce the buggy behavior:
* Create a page with an inline element, or go to
https://codepen.io/jameshfisher/pen/xxrXvVO
* Put the cursor at the end of the inline code element
* Type something
Expected behavior: If the cursor is at the end of an inline, text
should be inserted at the end of the inline.
Actual behavior: Slate moves the cursor outside the inline before
inserting text.
This current behavior is explicitly coded. I nevertheless claim that
this is a bug, or at least a misfeature in core. My expected behavior
comes from:
* The fact that the cursor is inside the inline. For the user, the
blinking cursor is visually inside the inline, not outside it. For the
developer, the cursor (i.e. editor.selection) is inside the inline,
not outside it. The definition of "the cursor" is "this is where your
text will go when you type". To break that behavior is really jarring.
* Slate's principle that "all of its logic is implemented with a series
of plugins". If the current behavior is actually desirable in some
circumstance, it should be in a plugin, not core. It's harder and less
elegant for me to remove the core behavior with my own plugin.
* Comparison with other editors. The following editors all insert text
at the end of the inline, as expected: default contenteditable,
Medium, Coda.io, Google Docs, OneNote, Evernote, QuillJS, TinyMCE,
EditorJS, ProseMirror. Two editors with the current buggy behavior are
Notion and Dropbox Paper, but I find it hard to imagine that their
current behavior on this issue is actually designed, and not just
accidental.
* Usability: how else is the user supposed to enter text at the end of
the inline ..? The only way seems to be to insert text before the end
of the inline, and then delete the rest of the inline. This is
obviously horrible.
* add changeset
* Fix test: insert at the end of an inline should _not_ have special behavior
* The selection is no longer moved in insertText so we don't need this special case
* fix:prettier
* Revert "The selection is no longer moved in insertText so we don't need this special case"
This reverts commit f9f36cd439.
* Explain the real reason for this special case - native browser bugs
* defer native events internally to Editable
* add changeset
* suggestions to make DeferredOperation a closure instead of an object type
Co-authored-by: Nemanja Tosic <netosic90@gmail.com>
* fix misapplied suggestion
Co-authored-by: Nemanja Tosic <netosic90@gmail.com>
* Fix bug: setting selection from contentEditable:false element causes crash
Fixes https://github.com/ianstormtaylor/slate/issues/4583
When clicking some text in a `contentEditable:false` element, if the
handler for this sets the selection, Slate crashes. Slate tries to find
a Slate range for the text that was clicked on, but there is no such
range, because the text is inside a `contentEditable:false` element.
Slate seems to be making a bad assumption that the current DOM selection
necessarily corresponds to a Slate range, but this is not the case if
the user just clicked into an element with `contentEditable: false`.
To fix this, I changed `exactMatch: false` to `exactMatch: true`,
which seems to mean "fail gracefully if there is no exact match".
* changeset
* Revert "Fix bug: setting selection from contentEditable:false element causes crash"
This reverts commit 71234284cd.
* Unconflate exactMatch flag: add suppressThrow flag for separate behavior
* Fix bug: setting selection from contentEditable:false element causes crash
Fixes#4583
When clicking some text in a `contentEditable:false` element, if the
handler for this sets the selection, Slate crashes. Slate tries to find
a Slate range for the text that was clicked on, but there is no such
range, because the text is inside a `contentEditable:false` element.
Slate seems to be making a bad assumption that the current DOM selection
necessarily corresponds to a Slate range, but this is not the case if
the user just clicked into an element with `contentEditable: false`.
* Don't remove selection when hovering over a non-selectable node
Fixes https://github.com/ianstormtaylor/slate/issues/4545
To reproduce the buggy behavior:
1. Create a page that renders a Slate element with a `contentEditable: false` element in it.
2. Start selecting some text with the mouse.
3. During the drag, mouseover the `contentEditable: false` element.
Expected behavior: After doing a drag-to-select with the mouse, from a valid anchor point on mousedown to a valid focus point on mouseup, the selection is set to those anchor and focus points.
Actual behavior: your selection is removed as soon as your mouse hits the `contentEditable: false` element. This is because the current behavior clears the selection if it is momentarily not a valid Slate location.
* Add changeset
* Allow passing custom slate editor creator to slate-hyperscript createEditor()
Makes it easier to create your own testing setup
* run fix:prettier
* remove unused createEditor
* Add changeset
* fix lint and remove accidentally committed file
In Firefox, `range.cloneContents()` returns an extra trailing '\n', when the document ends with a new-line character. This results in the offset length being off by one, so we need to subtract one to account for this.
