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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Ben, any ideas? /be
Assignee: hyatt → ben
QA Contact: shrir → jrgm
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.
How about some stack backtraces for the crashes? Maybe we could add some bulletproofing easily. /be
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.
> 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.
Assignee: bugs → nobody
QA Contact: jrgmorrison → xptoolkit.xul
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: xptoolkit.xul → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.