See testcase, I'm getting an xml parsing error in current trunk build with the testcase. This seems to have regressed between 2008-02-26 and 2008-02-27: 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=2008-02-26+04&maxdate=2008-02-27+09&cvsroot=%2Fcvsroot Regression from bug 416534, somehow?

Ok, apparently, the testcase shows the xml parsing error only locally.

Ok, testcase2 shows the xml parsing error online.

Might or might not be interesting to know the first testcase claims a "network error" happened when it's loaded, Firefox 2; second testcase does the right thing. So the first was fixed at some point and then broke again, while the second went from okay to bad.

Are we simply dealing with an error the wrong way here, i.e. we should ignore the stylesheet since it's cross-origin, but we show a parse error? Or can you get a testcase that should be working fully to fail? If the latter this is probably a blocker.

Testcase 3 works fine.

That might be the same problem that puzzled me in bug 428781 (Camino's 'missing' stylesheet for netError.xhtml causing a parsing error).

Perhaps bug 427779 is also related.

Still need an answer to comment 5 in order to triage this.

Jonas, can we get some sorta resolution on this?

I don't get what's wrong here. AFAIK, and Jonas agrees, this is working as expected. The testcase (first one) links to a non-existing XSLT file (using an invalid URL), and you get an error message about us not being able to parse the XSLT stylesheet. And that's not a regression AFAICT, Firefox 2.0.0.13 does that too. Closing this as INVALID, but if there's more to this than I've seen so far, please reopen this bug and explain what's unexpected here. Also clearing blocker nomination as I don't see how this could possibly block the release, given what we know about this so far.

With testcase2, I get an xml parsing error. I guess some kind of error is expected now that cross site xslt isn't allowed anymore, but I would certainly not expect an xml parsing error. The first testcase also shows an xml parsing error when you view it locally on your computer (see comment 1).

As mentioned in tuesdays meeting, please renominate if you think a bug was moved off the blocker list in error. Otherwise there's a huge risk it'll get lost in the flood of bugmail. Does FF2 not show a parsing error for testcase2? If the PI is simply ignored we might want to make sure to do that for FF3 too. If so, please renomintae.

I don't think this bug was moved off the blocker list in error. I don't really have an opinion of whether this should block or not. It seems to me, xslt isn't used a lot on the web, so this problem would not appear a lot. So I guess this should not block. The PI is ignored in FF2, but you get a security error in the error console. The security error is also shown in FF3 in the error console, but you get additionally the XML parsing error shown.

Ok, I think we should fix this then since there might be pages with bogus PIs out there that would break over this, and the fix is likely easy.

Probably regression from 401613 then, see also bug 404419 and bug 418391 for similar issues.

Comment on attachment 316114 [details] [diff] [review] Fix, with tests. Safe regression fix that helps XHTML users. Not a *huge* deal, but given how safe this is I see no reason not to take this.

Comment on attachment 316114 [details] [diff] [review] Fix, with tests. a1.9=beltzner

Fixed.

(In reply to comment #9) > That might be the same problem that puzzled me in bug 428781 (Camino's > 'missing' stylesheet for netError.xhtml causing a parsing error). As you pointed out in bug 428781 comment 10, this might be what is (badly) worsening bug 428848 too.

(In reply to comment #23) > (In reply to comment #9) > > That might be the same problem that puzzled me in bug 428781 (Camino's > > 'missing' stylesheet for netError.xhtml causing a parsing error). > > As you pointed out in bug 428781 comment 10, > this might be what is (badly) worsening bug 428848 too. [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9pre) Gecko/2008041723 SeaMonkey/2.0a1pre] (SEA-WIN32-TBOX-trunk) (W2Ksp4) [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9pre) Gecko/2008041801 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4) Johnny, eventually, this patch did not help bug 428848 :-/ (The "Security Error" is expected, for the time being; but) Could you have a look at why we're (still) getting an "XML Parsing Error" ? philippe, Would it be possible for you to test if this improved bug 428781 ? (By locally backing out the patch there.) Thanks.

Bug 428848 looks totally unrelated to this bug