If I have a fragment like this:
<p>This is some text that won't show up.</p>
<p>Here is some text</p>
<p>And some more</p>
And two ranges, one set to exactly the node with id = 'text' (called text_range), and the other with a selection contained inside it (say, a text range containing "some more", called selection), and we call:
selection.compareBoundaryPoints(Range.START_TO_END, text_range) gives -1 instead of 1, which appears to be incorrect. (At the very least, it conflicts with how Firefox returns this. The w3c documentation appears to define START_TO_END as "the start of text_range compared to the end of selection", but, then the return value reverses the *order* of the two (e.g, selection's end vs text_range's start), and I think webkit has merely confused START_TO_END vs END_TO_START's definition.
Created attachment 23286 [details]
An example of code that uses compareBoundaryPoints and gets different behavior than Firefox.
Created attachment 23396 [details]
further reduced test case
Yes, looks like WebKit is wrong here.
Created attachment 23411 [details]
Comment on attachment 23411 [details]
Committed in <http://trac.webkit.org/changeset/36423>.