createSelection() primitive odd behaviour in contentEditable div's
Now I am not entirely looking for a solution with this post, though one would be appreciated, I believe I am just going to work around this behaviour for my use case. However, when using the createSelection() primitive to get the user selection in a textarea versus a contentEditable div, the behaviour is fairly different and bordering on broken in the case of the contentEditable div ( and I am aware of why this is and will get into that soon ).
If you take a look at the attached video, and pay close attention to whenever I input a newline character, moving the cursor to the beginning of that newly created line, in the contentEditable div ( above ) the primitve returns the [start,end] tuple of [0,0] regardless of whether or not there is content on previous lines - contrast this to the textarea where it correctly gets the length of the text previous to the cursor and also accounts for this when the selection is not collapsed, i.e start !== end.
I am aware this is because of differences in the window.getSelection() API and the properties available on each DOM element's object representation in TS, we can see this in the source code of the primitive where you'll notice special handling of the textarea and input element cases since those objects have the available selectionStart and selectionEnd properties which simplify the process of fetching these values, and for other cases the function goes on to fallback to the window.getSelection() API:
Now I suppose my question, or more accurately discussion topic, is what could be done about this in terms of a PR to improve this behavior, or if that should be done at all - for all I know this is the preferred or best possible solution, so I am opening it up to discussion, I suppose.
I spent a good couple hours fiddling around with a fork of the primitive and tried to handle it by introducing a special case for contentEditable divs where I would walk the DOM and check for linebreak
Thoughts?
If you take a look at the attached video, and pay close attention to whenever I input a newline character, moving the cursor to the beginning of that newly created line, in the contentEditable div ( above ) the primitve returns the [start,end] tuple of [0,0] regardless of whether or not there is content on previous lines - contrast this to the textarea where it correctly gets the length of the text previous to the cursor and also accounts for this when the selection is not collapsed, i.e start !== end.
I am aware this is because of differences in the window.getSelection() API and the properties available on each DOM element's object representation in TS, we can see this in the source code of the primitive where you'll notice special handling of the textarea and input element cases since those objects have the available selectionStart and selectionEnd properties which simplify the process of fetching these values, and for other cases the function goes on to fallback to the window.getSelection() API:
Now I suppose my question, or more accurately discussion topic, is what could be done about this in terms of a PR to improve this behavior, or if that should be done at all - for all I know this is the preferred or best possible solution, so I am opening it up to discussion, I suppose.
I spent a good couple hours fiddling around with a fork of the primitive and tried to handle it by introducing a special case for contentEditable divs where I would walk the DOM and check for linebreak
<br/>Thoughts?
GitHub
A library of high-quality primitives that extend SolidJS reactivity. - solidjs-community/solid-primitives
