Closed Bug 110795 Opened 23 years ago Closed 23 years ago

Freeze core DOM interfaces....

Categories

(Core :: DOM: Core & HTML, defect)

x86
All
defect
Not set
normal

Tracking

()

VERIFIED FIXED

People

(Reporter: chak, Assigned: chak)

References

Details

Attachments

(1 file)

Freeze the following core DOM interfaces:

  nsIDOMAttr
  nsIDOMCDATASection
  nsIDOMCharacterData
  nsIDOMComment
  nsIDOMDOMException
  nsIDOMDOMImplementation
  nsIDOMDocument
  nsIDOMDocumentFragment
  nsIDOMDocumentType
  nsIDOMElement
  nsIDOMEntity
  nsIDOMEntityReference
  nsIDOMNamedNodeMap
  nsIDOMNode 
  nsIDOMNodeList
  nsIDOMNotation
  nsIDOMProcessingInstruction
  nsIDOMText
I've already verified that these interfaces conform to the W3C's DOM2 spec.

Patch forthcoming....
what's up with the DOM3 parts?
http://www.mozilla.org/projects/embedding/EmbedInterfaceFreeze.html says only
the one frozen interface should be part of the idl file.
The only idl file which had more than one interface(and a DOM3 part) was
|nsIDOMNode|

We need to move out |nsIDOM3Node| to a different file(out of nsIDOMNode.idl)

Are there any others which i missed....Thanks
Blocks: 105444
Yeah, nsIDOM3Node should be moved into nsIDOM3Node.idl (which should *not* be
frozen), there shouldn't be any other nsIDOM3* interfaces yet. Thanks Chak for
going through these interfaces!
The only interface for which i could not come up with a description is for
nsIDOMEntityReference. I'd appreciate if some one can please provide that to
me...Thanks
Looks good to me. As for the description of nsIDOMEntityReference we could say
something like this:

"nsIDOMEntityReference is an interface to a node that represents a reference to
one of the entities defined in the document."

We actually don't support nSIDOMEntityReference yet in mozilla, but some day we
will...

sr=jst
Comment on attachment 59214 [details] [diff] [review]
Patch to freeze the DOM core interfaces...

What about moving nsIDOM3Node out of nsIDOMNode?
Yes, that needs to be done, and I can do that if you don't want to, Chak, that's
a matter of moving code into a new file (could even be done post freeze since it
doesn't change any API's in any way).
Sorry, i completely missed moving the nsIDOM3Node to it's own file part.
I'll file a new bug and assign it to Johnny - since i'm on vacation the rest of
the week :-)
Fix is in....
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Isn't freezing these interfaces pretty much meaningless until nsAString is
frozen?  Is freezing these interfaces a goal for Mozilla 1.0?  If C++ binary
compatibility for the DOM interfaces is a goal for Mozilla 1.0 (if so, why?),
then somebody better let the string folks know about it.
David, we froze the DOM IDL files only (which have practically been frozen for
ages, since the DOM 2 became a recommendation). 

The C++ interfaces are still open for discussion (nobody has requested we freeze
them as far as I know) and obviously depends on string freeze.
marking verified
Status: RESOLVED → VERIFIED
Component: DOM: Core → DOM: Core & HTML
QA Contact: stummala → general
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: