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;

reassigning to kin

I seem to remember anthonyd having a bug like this on his plate, which I thought he fixed?

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

This was fixed long ago by the checkin for bug 161166.