Bug 19555 - Node.getDocumentPosition should return 0x23 or 0x25 for disconnected nodes, not 0x01
Summary: Node.getDocumentPosition should return 0x23 or 0x25 for disconnected nodes, n...
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: DOM (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Anne
QA Contact: public-webapps-bugzilla
Depends on:
Blocks: 13044
  Show dependency treegraph
Reported: 2012-10-16 15:21 UTC by Aryeh Gregor
Modified: 2012-11-10 19:04 UTC (History)
4 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Aryeh Gregor 2012-10-16 15:21:06 UTC
See discussion here:


IE, Firefox, and Opera all implement the DOM Level 3 Core spec.  That means that for any two given disconnected nodes, they'll return either




consistently, as long as each one's root node has no parent.  (In practice, Gecko does a pointer comparison between pointers to the root nodes, where the pointer used is unique and stable for any given node.  Probably IE/Opera are similar.)

This is meant to be used for sorting arbitrary lists of nodes uniquely.  In fact, jQuery exposes a function that does exactly that.  But the current spec says to just return 0x01, which very well might break jQuery.  jQuery relies on the sort being a total order because it passes a function based on it to JS' .sort() method, which has undefined behavior for bogus sort functions.

In practice, the method is horrible enough (bitfields in JS!) that I don't think it's worth making it prettier.  I say we should just spec it like DOM Level 3 Core.  People can use .contains(), and we could add .isBefore()/.isAfter() methods to round it out if we want.
Comment 1 Aryeh Gregor 2012-10-28 12:25:56 UTC
Anne and I discussed on IRC.  Result:

<annevk> I have to pack a few more things and go, maybe add a pointer to the bug about this discussion and just go with the DOM3 behavior for now
<annevk> it's evil, but I can't think of anything better
Comment 2 Anne 2012-10-28 13:13:42 UTC
So what about pure JavaScript implementations of the DOM? There was some vague plan to eventually move in that direction...
Comment 3 Boris Zbarsky 2012-10-29 01:22:07 UTC
I don't think there's a problem for pure-JS impls per se, apart from the general difficulties of returning something consistent when you can't use the pointer value.  Which is not specific to JS: it's a problem for any implementation that moves nodes in memory (e.g. might well be a problem for Servo)...

I really wish I had better ideas here.
Comment 4 Aryeh Gregor 2012-10-30 12:08:57 UTC
It's always possible to implement this feature by picking a random result when needed and then remembering it for future calls.  In JS, you could do this for nodeA.compareDocumentPosition(nodeB):

  var rootA = nodeA;
  while (rootA.parentNode) {
    rootA = rootA.parentNode;
  var rootB = nodeB;
  while (rootB.parentNode) {
    rootB = rootB.parentNode;
  if (rootA != rootB) {
    if (rootA.randomValue === undefined) {
      rootA.randomValue = Math.random();
    if (rootB.randomValue === undefined) {
      rootB.randomValue = Math.random();
           (rootA.randomValue < rootB.randomValue ?
  // Same-root case, not relevant here

This would in practice probably not be impractically expensive, and I believe it meets the spec (unless Math.random() returns the same value twice).
Comment 6 Aryeh Gregor 2012-11-10 19:04:13 UTC
Updated test:


It doesn't yet try to test for consistency.  That should maybe be a separate test file.

(In reply to comment #5)
> https://github.com/whatwg/dom/tree/75f3a2e8cb623eed07765716671904405a5814e4

Did you mean:


Blech, non-truncated commit id's . . .