Bug 20738

Summary: compareBoundaryPoints gives incorrect results
Product: WebKit Reporter: Ryan Anderson <rda>
Component: DOMAssignee: Alexey Proskuryakov <ap>
Status: RESOLVED FIXED    
Severity: Major CC: ap, ojan
Priority: P2    
Version: 525.x (Safari 3.1)   
Hardware: All   
OS: All   
URL: http://www.h4x0r5.com/~ryan/bug/bug.html
Attachments:
Description Flags
An example of code that uses compareBoundaryPoints and gets different behavior than Firefox.
none
further reduced test case
none
proposed fix mjs: review+

Ryan Anderson
Reported 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.
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+
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Ryan Anderson
Comment 1 2008-09-08 19:25:56 PDT
Created attachment 23286 [details] An example of code that uses compareBoundaryPoints and gets different behavior than Firefox.
Alexey Proskuryakov
Comment 2 2008-09-13 10:04:34 PDT
Created attachment 23396 [details] further reduced test case Yes, looks like WebKit is wrong here.
Alexey Proskuryakov
Comment 3 2008-09-14 09:32:44 PDT
Created attachment 23411 [details] proposed fix
Maciej Stachowiak
Comment 4 2008-09-14 19:17:02 PDT
Comment on attachment 23411 [details] proposed fix r=me
Alexey Proskuryakov
Comment 5 2008-09-14 21:53:46 PDT
Committed in <http://trac.webkit.org/changeset/36423>.
Note You need to log in before you can comment on or make changes to this bug.