An instance with an empty default namespace inherits the namespace of the parent document.



Core Graveyard
9 years ago
a year ago


(Reporter: Swithun Crowe, Assigned: aaronr)



Firefox Tracking Flags

(Not tracked)




(2 attachments, 2 obsolete attachments)



9 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20080416 BonEcho/
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20080416 BonEcho/

The XHTML document has a default XHTML namespace. An inline instance has a non-default namespace and an empty default one. On submission, the instance's default namespace has become the XHTML one.

Reproducible: Always

Steps to Reproduce:
1. Load form like
2. Submit
3. Check output
Actual Results:  
The submitted instance is:

<?xml version="1.0" encoding="UTF-8"?>
<foo:Foo xmlns:foo="" xmlns="" 
xmlns:xf="" xmlns:ev="" xmlns:xlink="" xmlns:xsd="" xmlns:xsi=""/>

Expected Results:  
Ideally, you would get:

<?xml version="1.0" encoding="UTF-8"?>
<foo:Foo xmlns:foo=""/> 

Formsplayer produces the desired result. From what the W3C says about inheriting/overriding default namespaces (, I would say that the XForms plugin isn't handling this correctly.

Comment 1

9 years ago
Someone (Swithun Crowe) raised this issue also on the www-forms mailinglist of w3c, I informed him that it is a bug in the Mozilla XForms implementation.

Comment 2

9 years ago
Possibly related to #330557 

Comment 3

9 years ago
I believe the issue is serialization, not construction of the InfoSet.
The attached updated namespace2.xhtml shows that the the instance has child nodes of foo:Foo in the xmlns="" namespace.

Also, the attached example removes the Ubiquity script reference; it appeared to make no difference.

Comment 4

9 years ago
Created attachment 330075 [details]
Shows issue is not with namespace construction, but with serialization; removes Ubiquity script reference

Comment 5

9 years ago
Not really related to bug 330557.  The fact that we are serializing by hand and possibly missing namespaces from some ancestor elements is what bug 330557 is about.  If we can figure out how to serialize namespaces through mozilla and eliminate the need for serializing by hand, then we can get rid of the code that contains this bug.

Comment 6

9 years ago
Created attachment 330356 [details] [diff] [review]

added a parameter to AddNameSpaces to allow us to remember whether to ignore the default namespace as we search up our ancestor tree
Assignee: nobody → aaronr
Ever confirmed: true
Attachment #330356 - Flags: review?(Olli.Pettay)

Comment 7

9 years ago
Comment on attachment 330356 [details] [diff] [review]

>     nsAutoString XMLNSAttrValue;
>+    PRBool ignoreDefaultNS = PR_FALSE;
>     submDocElm->GetAttributeNS(kXMLNSNameSpaceURI, NS_LITERAL_STRING("xmlns"),
>                                XMLNSAttrValue);

Should we actually test HasAttributeNS? It is ok to have empty value.

>     if (XMLNSAttrValue.IsEmpty() && (!prefixHash ||
>         !prefixHash->Get(NS_LITERAL_STRING("#default"), nsnull))) {
>       submDocElm->RemoveAttributeNS(kXMLNSNameSpaceURI,
>                                     NS_LITERAL_STRING("xmlns"));
>+      ignoreDefaultNS = PR_TRUE;
>     }

Comment 8

9 years ago
On this thread,, the W3C said that it doesn't matter if we serialize an empty default namespace or not, but as of Friday morning things were leaning toward not serializing it as a preference.  More arguments have come up since then, though.

I'm fine with serializing the empty default namespace.  If you feel the same, then I'll just do it and we'll be done with it.

Comment 9

9 years ago
I think the default namespace should be serialized.

Comment 10

9 years ago
Created attachment 331441 [details] [diff] [review]

Changed per Olli to export the default namespace.  No real consensus on the W3C side whether it should be serialized or not, either, so I guess if the author bothered to put it there, we should serialize it.
Attachment #330356 - Attachment is obsolete: true
Attachment #331441 - Flags: review?(Olli.Pettay)
Attachment #330356 - Flags: review?(Olli.Pettay)

Comment 11

9 years ago
Created attachment 331442 [details]
testcase w/ diff echo server

same testcase as before but using the echo server (which seems to always be up and the other one doesn't)
Attachment #330075 - Attachment is obsolete: true


9 years ago
Attachment #331441 - Flags: review?(doronr)


9 years ago
Attachment #331441 - Flags: review?(doronr) → review+


9 years ago
Attachment #331441 - Flags: review?(Olli.Pettay) → review+

Comment 12

9 years ago
checked into cvs trunk
Last Resolved: 9 years ago
Resolution: --- → FIXED
Whiteboard: xf-to-branch

Comment 13

9 years ago
checked into 1.8 branch
Keywords: fixed1.8.1.17
Whiteboard: xf-to-branch
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.