Bug 20738 - compareBoundaryPoints gives incorrect results
Summary: compareBoundaryPoints gives incorrect results
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: 525.x (Safari 3.1)
Hardware: All All
: P2 Major
Assignee: Alexey Proskuryakov
URL: http://www.h4x0r5.com/~ryan/bug/bug.html
Keywords:
Depends on:
Blocks:
 
Reported: 2008-09-08 19:24 PDT by Ryan Anderson
Modified: 2008-09-14 21:53 PDT (History)
2 users (show)

See Also:


Attachments
An example of code that uses compareBoundaryPoints and gets different behavior than Firefox. (2.20 KB, text/html)
2008-09-08 19:25 PDT, Ryan Anderson
no flags Details
further reduced test case (1.69 KB, text/html)
2008-09-13 10:04 PDT, Alexey Proskuryakov
no flags Details
proposed fix (6.65 KB, patch)
2008-09-14 09:32 PDT, Alexey Proskuryakov
mjs: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ryan Anderson 2008-09-08 19:24:47 PDT
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.
Comment 1 Ryan Anderson 2008-09-08 19:25:56 PDT
Created attachment 23286 [details]
An example of code that uses compareBoundaryPoints and gets different behavior than Firefox.
Comment 2 Alexey Proskuryakov 2008-09-13 10:04:34 PDT
Created attachment 23396 [details]
further reduced test case

Yes, looks like WebKit is wrong here.
Comment 3 Alexey Proskuryakov 2008-09-14 09:32:44 PDT
Created attachment 23411 [details]
proposed fix
Comment 4 Maciej Stachowiak 2008-09-14 19:17:02 PDT
Comment on attachment 23411 [details]
proposed fix

r=me
Comment 5 Alexey Proskuryakov 2008-09-14 21:53:46 PDT
Committed in <http://trac.webkit.org/changeset/36423>.