This gif shows the issue:

It seems the caret is stuck in a non-editable part of the document, can't get out of it unless you click somewhere in the text.
This reproduces on the any of the other editors (rich editor, etc) if you click at the end of a line.

Importanly, this does not happen on the React version of slate (slate official examples, for instance).

No errors are shown in the console, just a lack of ability to edit. Works fine on Chrome/Safari.

Hello,

I was looking at the source code for the sample editor, and I noticed that there is a Toolbar child component that seems to not be rendered anywhere. Is there something I'm missing?

Thanks in advance.

hello i have a bug reported on react-slate but not reported in svelte-slate
ianstormtaylor/slate#4914

for test

https://svelte.dev/repl/b2fd358f082b444d873f95a8dedaf1ea?version=3.48.0

triple click on text

bug: no line selected

Hey, any plans to update this package to support svelte 4? I tested it out with npm install --force and it seemed to work fine, although I haven't tested it super in depth. Svelte 3 no longer receives updates, so it would be helpful to have official support for Svelte 4.

The code is basic:

<script>
let value = [{
	type: 'paragraph',
	children: [
		{ text: 'This is editable ' },
		{ text: 'rich', bold: true },
		{ text: ' text, ' },
		{ text: 'much', italic: true },
		{ text: ' better than a ' },
		{ text: '<textarea>', code: true },
		{ text: '!' }
	]
}];
</script>

...

<Slate {editor} bind:value>
    <Editable placeholder="Enter some text..." 
        {Element}
        {Leaf}      
    />
</Slate>

This seems to only happen in Firefox and may be caused by #5 with the additional whitespace being inserted. If the first character in the editor is highlighted, and you try to type, you get an error:

Uncaught Error: Cannot resolve a Slate point from DOM point: [object Text],0

This does not happen in Chromium. See the following GIF: https://gyazo.com/1e59a43c34826eec4ae56085839ae499

Yes, I have addons installed, but I also tested this in a clean-install of Firefox Developer Edition and can confirm the same still happens.

I modified toSlateRange in utils.js to simply log what is being passed for domRange. It seems that the starting element is an invisible empty text node whereas it is correctly the first text node in Chromium. It seems the next sibling node is the correct element so perhaps a fix for this specific issue could be an IS_FIREFOX check selecting the sibling node as the start to the range.