335071 - Zimbra demo doesn't work anymore

Status: RESOLVED FIXED

(Tech Evangelism Graveyard :: English US, defect)

Description

[Martijn Wargers (dead)]

To reproduce:
- Press "Skip Registration, Go to Demo" button
- fill in the word as designated and press the "Continue" button

Expected result:
The demo of the Zimbra mail web application.

Actual result:
Zumbra gives an error dialog:
msg - Csfe service error
code - service.PARSE_ERROR
method - ZmCsfeCommand.prototype.invoke
detail - parse error: Error on line 1 of document  : The value of the attribute "prefix="xmlns",localpart="a0",rawname="xmlns:a0"" is invalid. Prefixed namespace bindings may not be empty. Nested exception: The value of the attribute "prefix="xmlns",localpart="a0",rawname="xmlns:a0"" is invalid. Prefixed namespace bindings may not be empty.

And the mail application doesn't show up.

I'm not sure whether this is a bug in Firefox or the Zimbra application.
I've also filed this in Zimbra's bugzilla application:
http://bugzilla.zimbra.com/show_bug.cgi?id=7308

Note that current trunk builds fail at a different point when trying the demo. They don't even show up the Zimbra error dialog.
This might be some other issue, which I'll investigate and file a bug for, when necessary.

Comment 1

[Peter Van der Beken [:peterv]]

I'm assuming that the message 'Prefixed namespace bindings may not be empty.' comes from Zimbra code. Prefixed namespace bindings are allowed to be empty, that is how one undeclares a namespace. See the last paragraph of http://www.w3.org/TR/xml-names11/#scoping

Comment 2

[Martijn Wargers (dead)]

I guess this is invalid then, or a tech evangelism issue.
I filed bug 335080 for the issue I'm seeing in current trunk builds.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Yeah, evang.

Comment 4

[Boris Zbarsky [:bzbarsky]]

This may be a duplicate of bug 326994, not evang or invalid.

Comment 5

[Boris Zbarsky [:bzbarsky]]

So actually, there _is_ a Zimbra issue here.  Zimbra initially breaks with the checkin for bug 301260.  Before that checkin, we're serializing the following string:

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"><soap:Header><context xmlns="urn:zimbra">
...

After that checkin we're serializing:

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"><soap:Header><context>

Note the missing xmlns="urn:zimbra".  But when I look at the actual DOM they pass to the DOMSerializer:

(gdb)  p *((class nsStaticAtomWrapper*) $ctx->Tag())->mStaticAtom
$23 = {mString = 0xb781c2c3 "context", mAtom = 0xb78fa880}
(gdb) p *$ctx->NodeInfo()
$24 = {<nsISupports> = {_vptr.nsISupports = 0xb78afd88}, mInner = {mName = 0x80b85a8, 
    mPrefix = 0x0, mNamespaceID = 0}, mIDAttributeAtom = {mRawPtr = 0x0}, 
  mOwnerManager = 0x87604a8}

So that <context> node is in the null namespace, and the old serialization is just completely bogus!

Also:

(gdb) p $ctx->GetAttrNameAt(0)->IsAtom()
$25 = 1
(gdb) p *((class nsStaticAtomWrapper*)$ctx->GetAttrNameAt(0)->Atom())->mStaticAtom
$27 = {mString = 0xb781d869 "xmlns", mAtom = 0xb78fb1e8}

So the "xmlns" attribute is also in the null namespace, which is bogus.  It should be in the XMLNS namespace.

So Zimbra really needs to use some of the *NS DOM methods here if it's going to work in Gecko 1.9.

Comment 6

[Roland Schemers]

Hi. We'd be happy to fix our code. Can someone point me at the correct way to set the default namespace for an element?

We have SOAP that looks like:

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
  <soap:Header>
    <context xmlns="urn:zimbra">
     ...
    </context>
  </soap:Header>
  <soap:Body>
   <SearchRequest xlmns="urn:zimbraMail">
     ...
   </SearchRequest>
  </soap:Body>
</soap:Envelope>

Where <context> should have a default namespace of "urn:zimbra", and <SearchRequest> should have a default namespace of "urn:zimbraMail".

We have been using (incorrectly, it sounds like) the following:

  context.setAttribute("xmlns", "urn:zimbra");

As when we wrote this code (over two years ago), we didn't see an obvious way of setting the default namespace on an element, tried the above, and it worked.

Switching away from using a default namespace would be somewhat painful at this point, and I'd like to isolate the code changes two the *Request element and the Context element in the header if at all possible.

thanks.

Comment 7

[Boris Zbarsky [:bzbarsky]]

> Can someone point me at the correct way to set the default namespace for an
> element?

The namespace of an element is effectively immutable in DOM2.  You can create elements in the namespace you want using createElementNS when you're constructing the DOM, of course.

Comment 8

[Roland Schemers]

thanks. It looks like createElementNS("urn:zimbra", "context") does the trick, and sets the default namespace.

Comment 9

[Roland Schemers]

I've fixed this in our main branch (bug 7308 in our db). Not sure when it will get pushed to our hosted demo site.

Comment 10

[Martijn Wargers (dead)]

I'm now getting this error:
Error: [Exception... "Node cannot be used in a document other than the one in which it was created"  code: "4" nsresult: "0x80530004 (NS_ERROR_DOM_WRONG_DOCUMENT_ERR)"  location: "http://demo2.zimbra.com/zimbra/js/Ajax_all.js.zgz?v=061016143950 Line: 20764"]
Source File: http://demo2.zimbra.com/zimbra/js/Ajax_all.js.zgz?v=061016143950
Line: 20764

I guess the zimbra demo now suffers from the fix of bug 47903.

Comment 12

[Martijn Wargers (dead)]

Ok, the demo at the site is now working fine.
I guess this could be called worksforme now.
However, I guess any site that has Zimbra 4.0.5 installed, still suffers from this.

Comment 13

[Jeremy Baron]

This is long fixed for the app in question and the demo site linked is now fixed too.  We can't possibly expect nor should we find every instance that uses a version that has this bug and evangelize them to upgrade.

File new bugs for individual sites if they warrant attention individually and mark them blocking this bug.