Open Bug 335080 Opened 15 years ago Updated 2 years ago

Zimbra demo doesn't work anymore, part 2

Categories

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

x86
Windows XP
defect

Tracking

()

REOPENED
mozilla1.9alpha8

People

(Reporter: martijn.martijn, Unassigned)

References

()

Details

(Keywords: regression)

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:
No mail web application, error in the js console:
Error: ex.getErrorMsg is not a function
Source File: http://demo3.zimbra.com/zimbra/js/ZimbraMail_all.js.zgz?v=060216141132
Line: 1373

This regressed between 2006-02-02 and 2006-02-03:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-02-02+12&maxdate=2006-02-03+07&cvsroot=%2Fcvsroot
Maybe a regression from bug 324600, I have no idea.
But maybe this is also a case where the fault somehow lies witht the zimbra application?

Also note bug 335071, which prevents the mail web application from appearing also.
Does that error not appear in a build that doesn't show the error?  Given the source they send I can't see how it can fail to appear...  Do the two builds get the same JS?
Flags: blocking1.9a1?
Specifically:

     function (xml) {
    2         var xmlDoc = AjxXmlDoc.create();
 -  3         xmlDoc.loadFromString(xml);
 -  4         return xmlDoc;
 -  5     }

is called.  And then we have:

     function (str) {
    2         var doc = this._doc;
 -  3         doc.loadXML(str);
 -  4         if (AjxEnv.isIE) {
 -  5             if (doc.parseError.errorCode != 0) {
 -  6                 throw new AjxException(doc.parseError.reason, AjxException.INVALID_PARAM, "AjxXmlDoc.loadFromString");
 -  7             }
    8         }
    9     }

which throws since loadXML is not a function in Gecko (it is in IE)... and the exception handler expects the exception to be a AjxException, which it isn't of course.
Hmm.  It looks like the responseXML is coming out null for some reason... I'll dig into that.  No need to retest in the older build.
The reason it's null is that the data has a content-type of "text/html" as far as I can tell.

I don't see any changes to XMLHttpRequest in the range in question; did something change in necko to maybe affect this?
not sure what kind of necko change could cause the document to be null. I don't see a necko change in comment 0 anyway (other than as part of my UCS2 -> UTF16 patch)
So in fact we return null from GetResponseXML in a build in which this stuff "works" too.  But in that build zimbra shows a "A Parsing Error Occurred" message, at least for me.  I guess I'll try to narrow down stuff some more...
OK, it looks like the problem here on that day was that some nodes were ending up with the wrong (null, to be exact) principals, so stuff failed.  That's been fixed since then -- it's now impossible to have null principals.  Nevertheless, something's failing; I'm not sure what.  I'll revisit once I fix bug 332840, I guess.  :(
Depends on: 332840
But note that I'm no longer seeing security checks failing here, so my best guess is that comment 2 is correct and this is a bug in the page.  I have no idea why this bug didn't bite them in the older build....
Oh, I see.  The site sets Document.prototype.loadXML.  So it's not clear to me why the loadXML call throws, really.
So here's the historical behavior I see:

1)  We have bug 335071.  Zimbra reports a parsing error.
2)  Bug 324600 lands.  We stop reporting errors altogether because of security
    stuff.
3)  Bug 324601 lands and fixes security stuff.  Zimbra starts reporting an
    "unknown document" error; I don't know what might have changed in the 3
    weeks  in between to change what error they're reporting; this report comes
    from the  server, not the client code.  I'll look into this.
4)  Something changed in the range
     http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-04-10+08&maxdate=2006-04-11+08&cvsroot=%2Fcvsroot
    to cause the current situation (where Document.prototype is ending up
    different in some cases).  I'd suspect bug 326497 here.
Blocks: 326497
Depends on: 324600
OK, I can verify that backing out bug 326497 gets us back to the "step 3" state where we're putting up a "Wrong Document" alert.

Blake, did that change just make us actually throw the exception from trying to call loadXML?  Or something else?
Blocks: 324600
No longer depends on: 324600
Er... ccing people too.  See commment 12.
Depends on: 333983
So we switched from the namespace thing to the wrong document thing somewhere in http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-02-17+07&maxdate=2006-02-20+07&cvsroot=%2Fcvsroot

My initial guess is on bug 326994 there (which fixed a real XML compliance issue; perhaps bug 335071 is simply a duplicate of that one?).  But all that would mean is that with that bug fixed we run into some other error; no idea when that was introduced.  In any case, checking on things now.
OK, confirmed that bug 326994 fixes the xmlns issue Zimbra was having.  So now the question is what's up with the "wrong document error" thing.
OK.  So a build from before bug 324600 landed, with the patch for bug 326994 applied shows the "wrong document" thing.  So bug 324600 is not to blame, at least.  ;)
No longer blocks: 324600
So the initial issue here was definitely a bug in Zimbra.  Leaving this bug for the XPConnect thing.
Blocks: 301260
Blocks: 314987
Flags: blocking1.9a1? → blocking1.9+
bz: what XPConnect thing are you referring to in the previous comment? If this is purely a zimbra issue we should remove the blocking status and turn this into an evangelism bug.

Minusing for now, please renominate if there is a real regression here (rather than just us fixing bugs)
Flags: blocking1.9+ → blocking1.9-
> bz: what XPConnect thing are you referring to in the previous comment?

See comment 11 item #4.  We changed _something_ in XPConnect that's causing the scripts in question to be very confused.

Renominating.

Although perhaps we just want to spin that off into a separate, clearer, bug.
Flags: blocking1.9- → blocking1.9?
It'd be good to know if this is an actually regression or a desired behavior in change. Though I suspect it's the former.

Could we contact someone from the zimbra team to figure out exactly which line is failing?
Assignee: general → mrbkap
Flags: blocking1.9? → blocking1.9+
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a6pre) Gecko/20070613 Minefield/3.0a6pre

Works for me - same for MConnor on Mac.   Demo seems to go off without a hitch - no error in JS Error console.   Lots of folks here also use Zimbra on a daily basis so if it were still broken I'm guessing we'd know.

So closing works for me...
Status: NEW → RESOLVED
Closed: 14 years ago
Flags: blocking1.9+
Resolution: --- → WORKSFORME
Sorry, reopening.  Chances are, zimbra just worked around this bug, unless we're sure they didn't change anything in the demo...  Of course if they didn't change anything, it's possible that this fixed itself.  But I rather doubt it.
Status: RESOLVED → REOPENED
Flags: blocking1.9+
Resolution: WORKSFORME → ---
Targeting to B1 per conversation with Blake.
Target Milestone: --- → mozilla1.9beta1
This is all complicated by the fact that we don't actually know what changed in what timeframe (and by this point, we're talking about bugs that were checked in a year ago). bug 326497 can cause things to fail which normally wouldn't have failed before -- if, in a postcreate hook, somebody threw an exception, we'd simply ignore it before, whereas now, we allow it to propagate out.

That being said, I don't see any codepath today that causes a "wrong document error" from a postcreate hook. On the demo site, document.prototype.loadXML uses importNode today (though sicking notes they should probably be using adoptNode), which makes me wonder if that was the cause for the original exceptions that Boris was seeing.

I'm cc'ing Roland Schemers from bug 335071, hoping he can help shed light on what happened here.
Given that we don't know what caused this and that no other reports of this problem has come in I'm removing the blocking flag on this bug. Sure, it'd be great to find out what happened here, so I'm leaving this bug open, but we're not blocking the release on that. We've got way bigger fish to fry...
Flags: blocking1.9+ → blocking1.9-
The Zimbra demo has been upgraded many times since this happened.  So looking at the current code won't give us clues.  We did make some related changed to get bug 335071 solved so I suspect this may have fixed (avoided) this issue as well.
Assignee: mrbkap → nobody
QA Contact: ian → general
Whiteboard: p=0
No longer blocks: fxdesktopbacklog
Flags: firefox-backlog+
Flags: firefox-backlog+ → firefox-backlog-
Whiteboard: p=0
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.