If I have a fragment like this: <div id='nonselected'> <p>This is some text that won't show up.</p> </div> <div id='text'> <p>Here is some text</p> <p>And some more</p> </div> 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] proposed fix
Comment on attachment 23411 [details] proposed fix r=me
Committed in <http://trac.webkit.org/changeset/36423>.