Bug 20738 – compareBoundaryPoints gives incorrect results

• Status: RESOLVED
• Resolution: FIXED
• Component: DOM

[Ryan Anderson]

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.

[Ryan Anderson]

Created attachment 23286 [details]
An example of code that uses compareBoundaryPoints and gets different behavior than Firefox.

[Alexey Proskuryakov]

Created attachment 23396 [details]
further reduced test case

Yes, looks like WebKit is wrong here.

[Alexey Proskuryakov]

Created attachment 23411 [details]
proposed fix

[Maciej Stachowiak]

Comment on attachment 23411 [details]
proposed fix

r=me

[Alexey Proskuryakov]

Committed in <http://trac.webkit.org/changeset/36423>.