Range "CompareHow" constant discrepancies with W3C

RESOLVED FIXED in Future

Status

()

Core
DOM: Core & HTML
P3
normal
RESOLVED FIXED
17 years ago
4 years ago

People

(Reporter: dannyg, Assigned: kinmoz)

Tracking

Trunk
Future
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

17 years ago
Values for constants Range.END_TO_END and Range.END_TO_START are different in
Moz vs. the W3C rec. The Moz sequence is more logical in a way, but it doesn't
jive with the published rec. This discrepancy also means that 
Range.compareBoundaryPoints(how, sourceRange) is performing incorrect boundary
comparisons for 'how' values 2 and 3 (but they're OK if you use the constants). 

For your delectation:

http://lxr.mozilla.org/seamonkey/source/dom/public/idl/range/nsIDOMRange.idl

interface nsIDOMRange : nsISupports
{
/**
  * CompareHow group
  * Passed as a parameter to the compareBoundaryPoints method.
  */
   const unsigned short START_TO_START = 0;// Compare start boundary-point of
sourceRange to start boundary-point of Range on which compareBoundaryPoints is
invoked
   const unsigned short START_TO_END = 1;  // Compare start boundary-point of
sourceRange to end boundary-point of Range on which compareBoundaryPoints is invoked
   const unsigned short END_TO_START = 2;  // Compare end boundary-point of
sourceRange to start boundary-point of Range on which compareBoundaryPoints is
invoked
   const unsigned short END_TO_END = 3;    // Compare end boundary-point of
sourceRange to end boundary-point of Range on which compareBoundaryPoints is invoked


http://www.w3.org/TR/DOM-Level-2-Traversal-Range/ranges.html#Level-2-Range-idl

 // CompareHow
  const unsigned short      START_TO_START                 = 0;
  const unsigned short      START_TO_END                   = 1;
  const unsigned short      END_TO_END                     = 2;
  const unsigned short      END_TO_START                   = 3;

Comment 1

16 years ago
reassigning to kin
Assignee: anthonyd → kin
(Assignee)

Comment 2

16 years ago
I seem to remember anthonyd having a bug like this on his plate, which I thought 
he fixed?
Blocks: 30838
OS: Mac System 9.x → All
Priority: -- → P3
Hardware: Macintosh → All
Target Milestone: --- → mozilla1.0.1

Comment 3

16 years ago
yeah I did. I'm not sure if screwed this up, or if it was already assigned these 
values and I just ran with them. Do you want me to fix it? I can, it wont take 
much ;-)

anthonyd - confirming

Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Updated

16 years ago
Target Milestone: mozilla1.0.1 → Future

Comment 4

13 years ago
This was fixed long ago by the checkin for bug 161166.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
Component: DOM: Traversal-Range → DOM: Core & HTML
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.