296921 - createElement() looks broken for XML documents

Status: RESOLVED INVALID

(Core :: XML, defect)

Description

[alexander :surkov (:asurkov)]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; ru-RU; rv:1.7.8) Gecko/20050511 Firefox/1.0.4 (ax)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b) Gecko/20050217

I have xml document with DTD. Root of document has default namespace (xmlns
attribute). When I create new element by createElement() method then I can't get
new element by getElementById() attribute. If I create new element by
createElementNS() method then getElementById() works fine. Most likely
createElement() method doesn't specify namespace for new element.

Reproducible: Always

Comment 1

[alexander :surkov (:asurkov)]

Attachment: dtd for xml document

save it on local disc and place it under 'chrome://' protocol

Comment 2

[alexander :surkov (:asurkov)]

Attachment: xml file

save on root of local disc 'c:/' and change url of external DTD

Comment 3

[alexander :surkov (:asurkov)]

Attachment: test case

save on local disc with xml and dtd files

Comment 4

[Peter Van der Beken [:peterv]]

Elements created with the DOM Level 1 methods don't get namespaces in
conformance with the spec. We implemented two exceptions for XHTML and XUL, see
bug 280692.

Comment 5

[alexander :surkov (:asurkov)]

Are you really sure that getElementById() returns null because createElement()
doesn't set namespace? If is true, I belive this behaviour is not very
comfortably. As I can understand from bug 280692 nobody knows why such behaviour
was offered in spec. What difference between XUL, XHTML and arbitrary XML? Why
createElement() should have another behaviour for XML documents?

Comment 6

[Boris Zbarsky [:bzbarsky]]

> Are you really sure that getElementById() returns null because createElement()
> doesn't set namespace?

Yes, in this case (since the id-attribute in the DTD ends up tied to that
particular namespace, which could be considered a bug in itself -- note that if
there were no <class> elements in the document then even the createElementNS()
case wouldn't work here; we have a bug on that).  DTDs are a parse-time-only
issue in Mozilla (since we're a non-validating parser); they don't really affect
DOM interaction except through sharing of nodeinfos (which is what makes the
createElementNS() case work here).

> As I can understand from bug 280692 nobody knows why such behaviour
> was offered in spec.

Because there is no sane behavior that makes sense in a mixed-namespace document
otherwise.

> What difference between XUL, XHTML and arbitrary XML?

XUL and XHTML have specific MIME types (application/xhtml+xml and
application/vnd.mozilla.xul+xml).  Those are what affect the behavior of
createElement; the namespace on the root element does not.  Also, XHTML has this
little problem of needing to be somewhat compatible with HTML if it's to be
adopted at all.  And XUL is what Mozilla defines it to be.  That's why it makes
sense to mess with createElement for those cases.

> Why createElement() should have another behaviour for XML documents?

For a text/xml document there is simply no reasonable behavior for createElement
past creating a node in the null namespace.

Comment 7

[alexander :surkov (:asurkov)]

(In reply to comment #6)

> Yes, in this case (since the id-attribute in the DTD ends up tied to that
> particular namespace, which could be considered a bug in itself 

Is there instruction of DTD to specify namespace for witch DTD will work? What
namespace will be choosed by DTD in current realization if xml document has a
multiple namespaces? Will DTD be applied for elements of all namespaces or
default only? How it works in current realization?


> -- note that if
> there were no <class> elements in the document then even the createElementNS()
> case wouldn't work here; we have a bug on that).  

Can you say me number of this bug?

> Because there is no sane behavior that makes sense in a mixed-namespace document
> otherwise.

Why the next behaviour is not sane: createElement() should create element with
default namespace of document?

Comment 8

[Boris Zbarsky [:bzbarsky]]

> Is there instruction of DTD to specify namespace for witch DTD will work?

Not that I know of.

> What namespace will be choosed by DTD

It'll apply to all of them.  The "tying" I talked about is happening because of
bug 252774.

> Can you say me number of this bug?

Bug 252774.

> create element with default namespace of document?

There is no such concept (that is, a document has no default namespace).  If you
mean the default namespace of the document's documentElement (if any), that can
change quite easily, and I think createElement returning different things during
a document's lifetime is pretty wrong.

In any case, marking dependent on bug 280692; once that gets resolved there may
be something to discuss here or might not be.

Comment 9

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 10

[alexander :surkov (:asurkov)]

still presented

Comment 11

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Actually, this bug is invalid. The current behaviour is according to spec.