You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At the moment, detecting if you are at the end of the block is incomplete. The existing approach of using textContent only really works when the current node is a text node. It is difficult to get non-text nodes in the content at the moment, so this issue hasn't been very visible.
A text node has valid cursor positions at 0 all the way of up to its textContent.length (or nodeValue.length)
An element has valid cursor positions from 0 all the way up to the number of children (childNodes.length). Its textContent is largely irrelevant for cursor position.
There are also a few extra considerations just to make things fun :)
tags like <img> have a 0 for their start, and a 1 for their end
editors tend to use zero width characters etc. to allow cursor positions that content editable doesn't respect. You may start finding yourself needing to filter these out when checking the real 'length' of a text node. The inline link boundaries will be using these characters
if unusual node types like comment tags appear in your nodes, this might also affect your offsets.
Typically, you'll often get a text node, so it won't matter most of the time. But if someone puts an element at the end of their block (e.g. image), then the last cursor position in that block is going to be (<p>, n) or (<img>, 1). Therefore, textContent won't help you identify that you're at the edge.
Steps to Reproduce (for bugs)
Open a block that has an image at the end (may be difficult ... I just injected it)
Go to the end of the block and try and move to the block underneath it with
Possible Solution
The solution is to create a few more methods in dom.js that determine what the end of a particular node is (or the start), and use those methods when doing edge detection.
@iseulde , I'll have a PR on this shortly. Let me know what your thoughts are. I don't expect this to cover all of the edge cases, but it will be a start.
Seems like we can close this. Regardless of implementation, writing flow has come a long way. There are certainly micro-optimizations to be had, to be addressed in focused issues.
Issue Overview
At the moment, detecting if you are at the end of the block is incomplete. The existing approach of using textContent only really works when the current node is a text node. It is difficult to get non-text nodes in the content at the moment, so this issue hasn't been very visible.
A text node has valid cursor positions at 0 all the way of up to its
textContent.length
(ornodeValue.length
)An element has valid cursor positions from 0 all the way up to the number of children (
childNodes.length
). ItstextContent
is largely irrelevant for cursor position.See the Range API section of this blog post I helped with earlier this year for details: https://go.tinymce.com/blog/a-quick-guide-to-browser-selection-models/
There are also a few extra considerations just to make things fun :)
Typically, you'll often get a text node, so it won't matter most of the time. But if someone puts an element at the end of their block (e.g. image), then the last cursor position in that block is going to be (<p>, n) or (<img>, 1). Therefore, textContent won't help you identify that you're at the edge.
Steps to Reproduce (for bugs)
Possible Solution
The solution is to create a few more methods in
dom.js
that determine what the end of a particular node is (or the start), and use those methods when doing edge detection.@iseulde , I'll have a PR on this shortly. Let me know what your thoughts are. I don't expect this to cover all of the edge cases, but it will be a start.
PR: #3015
The text was updated successfully, but these errors were encountered: