163837 - XUL Fastload fails when .css are missing from theme file

Status: NEW

(Core :: XUL, defect)

Description

[Alfred Kayser]

See bug 162891, bug 161226:
The problem caused above bugs is that Mozilla
(and especially fastload) has a problem with missing .css files
in themes. This makes theme development horrible, and
make it almost impossible to extend mozilla without
breaking things.
This is happening with XUL cache enabled and using fastload (XUL.mfl).

In short when mozilla components (like messenger) are extended use additional
.css files from the theme, mozilla will crash (or stop working) when using a
theme without those extra files. In the bugs above, this is about some extra
empty .css templates (for OEM's), so mozilla should be able to work without
the real precense of them in the theme file.

Comment 1

[Tim]

Confirming.

Comment 2

[Brendan Eich [:brendan]]

Ben, any ideas?

/be

Comment 3

[Rob North]

Why not use file from one of the built-in themes as a fallback, when the files
are not present in the 3rd part theme?

Ideally the user could choose the fallback theme, but I'd be happy to
see any theme used as a fallback.

In a sense, I'm suggesting that there should be a concept a bit like a path
variable, describing where to look for theme files.

Of course, if the files will always be empty, then the soloution can be simpler.

Comment 4

[Brendan Eich [:brendan]]

How about some stack backtraces for the crashes?  Maybe we could add some
bulletproofing easily.

/be

Comment 5

[John Morrison]

Maybe look at http://bugzilla.mozilla.org/show_bug.cgi?id=121057#c6 which 
was a similar problem where a xul dialog contained a bogus stylesheet 
reference. The dialog would load the first time, but fail the second time (when 
coming out of the xul cache).

The (partial) stack in that case was:

nsXULDocument::AddPrototypeSheets(nsXULDocument * const 0x03477538) line 6445
nsXULDocument::StartDocumentLoad(nsXULDocument * const 0x03477538, const char * 
0x018d45b4 `string', nsIChannel * 0x0354eeb0, nsILoadGroup * 0x00000001, 
nsISupports * 0x032ed65c, nsIStreamListener * * 0x0012fd18, int 0x00000001, 
nsIContentSink * 0x00000000) line 780
nsContentDLF::CreateRDFDocument(nsContentDLF * const 0x03477538, const char * 
0x018d45b4 `string', nsIChannel * 0x00000000, nsILoadGroup * 0x02657e80, const 
char * 0x0012fc88, nsISupports * 0x032ed65c, nsISupports * 0x034e8718, 
nsIStreamListener * * 0x0012fd18, nsIContentViewer * * 0x0012fc00) line 527 + 
26 bytes
nsContentDLF::CreateInstance(nsContentDLF * const 0x034e3768, const char * 
0x018d45b4 `string', nsIChannel * 0x034e1798, nsILoadGroup * 0x02657e80, const 
char * 0x0012fc88, nsISupports * 0x032ed65c, nsISupports * 0x00000000, 
nsIStreamListener * * 0x0012fd18, nsIContentViewer * * 0x0012fc00) line 276 + 
30 bytes

and you can still hit that failure if you add
  <?xml-stylesheet href="chrome://navigator/skin/newfoo.css" type="text/css"?> 
to navigator.xul.

I don't know if that directly covers this bug, but is likely close, if not 
exactly the same.

Comment 6

[John Morrison]

> and you can still hit that failure if you add
>  <?xml-stylesheet href="chrome://navigator/skin/newfoo.css" type="text/css"?> 
> to navigator.xul.

I should probably add some more detail here. If I do the above in a current 
trunk build, first the nav window appears as only a 100px wide titlebar with
no content area whatsoever, and then the 'unknown content handler' dialog 
appears for type 'mozilla.application/cached-xul'.

However, breaking at that point just shows me waiting in the event loop for 
that dialog to be dismissed.

But, if I set a breakpoint in nsXULDocument::AddPrototypeSheets() I believe
that I can see it fail at that point and that a different bit of error handling 
might let it work better (or perhaps the bug is really that the bogus .css 
should never have been put in xul cache). But I say "I believe" since I'm in an 
optimized build and I can't see some things that have been optimized away from 
the source code.