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 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 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
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.
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+
You need to log in before you can comment on or make changes to this bug.