[Webkit-unassigned] [Bug 62092] setting innerText to an empty string on editable div loses focus

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Aug 30 09:37:07 PDT 2011


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





--- Comment #47 from Aryeh Gregor <ayg at aryeh.name>  2011-08-30 09:37:06 PST ---
Standards-wise, http://html5.org/specs/dom-range.html#range-behavior-under-document-mutation is the right place to look.  The behavior largely matches DOM 2 Range, but is more precise and differs in some cases.  There's a fairly extensive test suite here:

http://aryeh.name/spec/dom-range/test/Range-mutations.html

Currently all the Selection-related tests fail in WebKit because getRangeAt() returns a copy instead of the original range assigned to it.  The behavior should be the same for selections and ranges: whatever happens to a range when you delete the nodes in it should also happen to a selection.  Generally this means any boundary point in a removed node will be moved to the removed node's former parent.

(In reply to comment #41)
> One thing in the spec that is little strange is 
> 
> >> 
> Note that when content is inserted at a boundary-point, it is ambiguous as to where the boundary-point should be repositioned if its relative position is to be maintained. There are two possibilities: at the start or at the end of the newly inserted content. We have chosen that in this case neither the container nor offset of the boundary-point is changed. As a result, the boundary-point will be positioned at the start of the newly inserted content.
> >>
> 
> I understood this as: If we insert at the beginning of the selection, selection will expand to include the inserted content, but if we insert at the end boundary point, since offset is not supposed to change, new selection will NOT include the inserted content. The difference seems a little strange...

Yes, that's correct.  It is a little strange, but it's hard to think of anything better.  Anyway, it's how all browsers behave for Ranges, so we can't change it.  The newer spec puts it like this:

"""
For each boundary point whose node is the new parent of the affected node and whose offset is greater than the new index of the affected node, add one to the boundary point's offset.
"""
http://html5.org/specs/dom-range.html#range-behavior-under-document-mutation

If you insert at the beginning of the selection, the offset of the selection start is not greater than the new index of the affected node, it's equal, so the start remains in place -- before the new node, so it's included.  If you insert at the end, the offset of the end is also not greater than the new index of the affected node, so the end remains in place -- still before the new node, so it's not included.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list