Enter key at end of paragraph splits tracking nodes about ice HOT 9 CLOSED

Let me know when you have something working. My branch currently works, but once your stuff is ready, it should be a cleaner way of doing it and I will replace it with that.

@delambo I hope we can merge the two branches again completely once this is all done.

from ice.

I can get the basic case where the cursor/range is at the end of a paragraph (with an ugly hack for webkit). For example:

<p><insert>text{A}</insert>{B}</p>

Move the cursor from (A) to (B) to avoid browser splitting the insert into the next paragraph, which will result in the following after the browser handles the enter key:

<p><insert>text</insert></p>
<p>{A}</p>

But I cannot resolve the case where the cursor is in the middle of an insert. For example:

<p><insert>te{A}xt</insert></p>

Since we can't move the cursor (A) on enter, the following is the result after the browser handles the enter keypress:

<p><insert>te</insert></p>
<p><insert>{A}xt</insert></p>

In this case we will not avoid a nested insert, which I think is your biggest concern. When we designed ice, we stuck with nested user inserts because it is the easiest solution. The other solution, splitting nodes, is very hairy and complex with ranges, especially with webkit since it tends to force/normalize the range into the nearest textnode, often undoing work that might have been done to move after the node.

@johanneswilm - What conditions/use cases do you think satisfy this issue?

from ice.

I think the second case is fine, as the second paragraph has contents by the previous user and whatis going to be added now will be dependent on the first insert.

However, how about if it the cursor is at the start, like this:

<p><insert>{A}text</insert></p> 

What if the user hits Enter now? Have you coverd that case? I noticed in my testing there was a big differnce between me hitting the Enter key (creating an empty paragraph) and me hitting the Enter key, writing a few letters, and removing them again. Even if I made the DOM look the same, the browser behaved differently.

from ice.

Ugh, it looks like the very problems I am having with webkit have been reported (a very long time ago!):

https://bugs.webkit.org/show_bug.cgi?id=15256
https://bugs.webkit.org/show_bug.cgi?id=23189

from ice.

Yes, contentEditable in webkit seems like an area that has been given up a while back. The official version is that it's very hard to deal with. This is te feedback I received on a bug I recently filed concerning webkit (had to do some extra work to actually get them to take a look at it): https://bugs.webkit.org/show_bug.cgi?id=105323

from ice.

I'm thinking about introducing a hack into ice for webkit to solve some of these range problems but I don't want to introduce a big hack just for this issue because it isn't an urgent bug. In what other use cases or bugs have you come across the mentioned webkit range bugs?

The hack I'm thinking about is creating a zero-width space character (text node) and moving it to the position we where we want the range, then move the range into the zero-width textnode. That would involve adding code in insert and deleteContents that would have to recognize that we are in one of the hack ranges to properly clean the zero-width character after they take their action.

from ice.

I have just come a lot of contentEditable bugs, I don't know about that one in specific, and there seems to be a reason why Google Docs decided not to go with contentEditable and Google relying heavily on Webkit. Most (but not all) things seem to be somehow doable, you just have to try out everything.

Your hack sounds good. Good luck trying it out!

from ice.

@delambo Here I have done something similar, insert an empty text node and putting the caret inside of it:

johanneswilm@2a7d0dc

from ice.

Closing this as I think it is fixed, right?

from ice.