428781 - NetError.xhtml broken

Status: VERIFIED FIXED

(Camino Graveyard :: General, defect)

Description

[philippe (part-time)]

XML Parsing Error: 
Location: jar:resource:///chrome/embed.jar!/content/global/netError.xhtml
Line Number 60, Column 99:    <link rel="stylesheet" href="chrome://global/skin/netError.css" type="text/css" media="all" />

works: 20080412-00 build
fails: 20080413-01 build

Home made build cvs checkout @ 20080412, ~17:00 PDT fails

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-04-12+00%3A00%3A00&maxdate=2008-04-12+17%3A00%3A00&cvsroot=%2Fcvsroot

bug 292789 ?

Comment 1

[philippe (part-time)]

Right from the error console:
8:40 PM: Security Error: Content at about:neterror?e=dnsNotFound&u=http%3A//phiw.phiw.phiw/&c=UTF-8&d=phiw.phiw.phiw%20could%20not%20be%20found.%20Please%20check%20the%20name%20and%20try%20again. may not load or link to chrome://global/skin/netError.css.

--> sure is  bug 292789, adding Benjamin to the cc

Like Phil says  (bug 292789  comment 101)
> Oh, don't worry about us, we'll find out when you break us, same as always.

Comment 2

[philippe (part-time)]

BTW, FTP dir. listings also suffer from this: not able to load a stylesheet with chrome:// url
In this case, the file is loaded as text/html and you can actually see the page.

e.g
ftp://ftp.mozilla.org/pub/mozilla.org/camino/

Security Error: Content at ftp://ftp.mozilla.org/pub/mozilla.org/camino/ may not load or link to chrome://global/skin/dirListing/dirListing.css.

not sure if it is worth a separate bug.

Comment 3

[Serge Gautherie (:sgautherie)]

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9pre) Gecko/2008041302 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4)

I was not able to reproduce, neither the netError nor the Ftp cases.
Are these issues Camino specific ?

Comment 4

[Phil Ringnalda (:philor)]

xpfe-chrome-registration-only, which I guess means Camino-only these days, and no, it's not worth a separate bug: you have a single bug, that Camino's global chrome package needs a chrome:contentAccessible="true" attribute in the contents.rdf, and nsChromeRegistry.cpp needs to be taught about contentAccessible. http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&file=nsChromeRegistry.cpp&subdir=/mozilla/rdf/chrome/src&command=DIFF_FRAMESET&rev1=1.321&rev2=1.322 which taught it about xpcNativeWrappers="true" ought to work as an example of how.

Comment 5

[philippe (part-time)]

What does surprise me a little is that a missing or non-existent stylesheet triggers an XML parsing error. I thought bug 418391 had taken care of this.

Comment 6

[Philip Chee]

bug 428747 Comment 3 and bug 428747 Comment 4 might be the simplest change and should fix any and all regressions from the fallout.

Comment 7

[Serge Gautherie (:sgautherie)]

(In reply to comment #5)
> What does surprise me a little is that a missing or non-existent stylesheet
> triggers an XML parsing error.

It surprised me too.
Venkman (in SeaMonkey (v2)) has the "XML parsing error" issue too: bug 428848.

Comment 8

[Damon Sicore (:damons)]

-'ing this as this appears to be something that needs to be worked around in Camino.  I there is a core code issue here, please re-nom and specify what the issue is.

Comment 9

[Samuel Sidler (old account; do not CC)]

(In reply to comment #8)
> -'ing this as this appears to be something that needs to be worked around in
> Camino.  I there is a core code issue here, please re-nom and specify what the
> issue is.

Bug 428747 comment 3 (and 4) indicate this should probably be fixed in rdf/chrome. That's core code, so renominating.

Comment 10

[philippe (part-time)]

The XML parsing error is pretty much the same as what Martijn found in bug 428847 (and I guess the same applies to Venkman): the href URI in the PI contains a ':'.

Comment 11

[Damon Sicore (:damons)]

Can you please explain why we can't take this in a dot release?  Should this hold back everything else if it were the last bug?

Comment 12

[Mike Beltzner [:beltzner, not reading bugmail]]

Minusing, if you have an answer to comment 11, renom.

Comment 13

[Stuart Morgan]

The consensus in bug 428747 seems to be that this should be changed in core; if that's the case, then Camino 2 is blocked on that change. If you are asking for the opinion of a Camino developer as to whether something that prevents Camino from using Gecko 1.9 should be a stopship bug, then the answer is yes.

As for whether or not it could reasonably go in a dot release, without any idea of what the schedule for such a release would be I can't offer an opinion one way or the other.

Comment 14

[Benjamin Smedberg]

Executive decision: rdf/chrome is camino-specific code. It's no longer core, because only camino builds or uses it. I think Camino should take charge of maintaining that code since nobody else uses it, and this bug does not need to block the 1.9 release.

Comment 15

[Stuart Morgan]

Sounds reasonable; removing blocking request.

Comment 16

[Stuart Morgan]

Attachment: fix

Switch to allow-all, per discussion in bug 428747.

Comment 17

[Mike Pinkerton (not reading bugmail)]

Comment on attachment 316287 [details] [diff] [review]
fix

sr=pink

Comment 18

[Stuart Morgan]

Landed on trunk.

Comment 19

[Serge Gautherie (:sgautherie)]

(In reply to comment #10)
> The XML parsing error is pretty much the same as what Martijn found in bug
> 428847 (and I guess the same applies to Venkman): the href URI in the PI
> contains a ':'.

Thanks for the hint.

Comment 20

[philippe (part-time)]

verified with
Version 2.0a1pre (1.9pre 2008041717)