|Node| should grab constants on nsIDOM3Node

RESOLVED FIXED

Status

()

Core
DOM: Core & HTML
RESOLVED FIXED
15 years ago
7 years ago

People

(Reporter: Christopher Aillon (sabbatical, not receiving bugmail), Assigned: Christopher Aillon (sabbatical, not receiving bugmail))

Tracking

({fixed1.4.1})

Trunk
fixed1.4.1
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

Currently, we have some DOM Level 3 Node constants which exist in nsIDOMNode
because constants placed in nsIDOM3Node aren't available to JS via |Node.FOO|.

We should fix things to work properly, and move the constants to nsIDOM3Node
where they belong.  I have a patch for this which I will attach sometime tonight.
Comment on attachment 125486 [details] [diff] [review]
Patch

sr=jst
Attachment #125486 - Flags: superreview+

Comment 3

15 years ago
Comment on attachment 125486 [details] [diff] [review]
Patch

your checkin might want to note that some of the values for the constants
changed :)
Attachment #125486 - Flags: review+
Comment on attachment 125486 [details] [diff] [review]
Patch

Landed on the trunk.  Seeking 1.4 approval:

There has been a long standing issue in Mozilla where constants added to
nsIDOM3Node weren't available to script.  Because of this issue, when I
implemented some methods in the DOM3 spec that required constants, jst had me
add those constants to nsIDOMNode, even though it was frozen at the time
because it wouldn't affect backwards compatibility.  With (for example)
aaronl's work on the SDK, I think we need to fix that oddity sooner rather than
later, and move those constants out of nsIDOMNode and into nsIDOM3Node where
they really belong since its possible that they may change (the spec is not
finalized yet).  The patch attached to the bug does that, and fixes it so that
a node in script has these constants available which was the only reason that
the constants were "mis-placed" in the first place...  Therefore, jst and I
think it would be nice to have this for 1.4 since it helps "future proof" us.

The relevant changes are in nsDOMClassInfo.cpp, which is very low risk, and
nsIDOMNode.idl and nsIDOM3Node.idl -- the other changes are just updating
callers in our tree to reference nsIDOM3Node instead of nsIDOMNode.  Again,
very low risk.
Attachment #125486 - Flags: approval1.4?
IMO we should take this on the branch, it makes our interfaces across releases
more consistent from here on, and I don't see any risk in taking this fix on the
branch.

Comment 6

15 years ago
Comment on attachment 125486 [details] [diff] [review]
Patch

moving approval request forward.
Attachment #125486 - Flags: approval1.4? → approval1.4.x?
Fixed on trunk a while ago.

/me wishes this would get approval though for the 1.4 branch if anyone still
cares about that....
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED

Comment 8

15 years ago
How will we go about testing this if we take it on the branch? If you can
construct a reasonable plan for testing it and can get it together pretty
quickly then we may be able to take it. 
If it compiles, and the following test passes, it should be good.

javascript:alert(Node.DOCUMENT_POSITION_CONTAINED_BY==0x10?"pass":"fail");

Comment 10

15 years ago
Comment on attachment 125486 [details] [diff] [review]
Patch

a=asa (on behalf of drivers) for checkin to the 1.4 branch.
Attachment #125486 - Flags: approval1.4.x? → approval1.4.x+
Comment on attachment 125486 [details] [diff] [review]
Patch

Landed on the branch just now.

Updated

15 years ago
Keywords: fixed1.4.1

Updated

15 years ago
Blocks: 224532

Updated

10 years ago
Component: DOM: Core → DOM: Core & HTML
QA Contact: desale → general
You need to log in before you can comment on or make changes to this bug.