HOW TO REPRODUCE: Rename ua.css. Start Raptor. WHAT HAPPENS: Program starts, then exits without warning. OR: Program crashes. WHAT SHOULD HAPPEN: Removing support files should result in a graceful shutdown. An informational dialog should be brought up, suggesting things such as a reinstall or a restore from backups. The system should certainly not crash or die without warning or explanation. NOTES I first spotted this problem because after a crash due to something totally different (a forms thing in viewer.exe), restarting Raptor would not work. It was complaining about a load error with ua.css (sorry, I never got enough time to copy the error message: Raptor immediately quit or crashed).

The layout dependency on ua.css has been fixed. We should no longer crash without it. (All HTML tags just don't get their default style, it basically acts like an XML document...) There is still the general problem of missing resources that the app should gracefully notify the user about as Ian suggests. The layout engine should not do this.

Worry about this later ...

Crash is back. Using 11/2 Apprunner, renamed ua.css to xua.css. Crashed with following details: MOZILLA caused an invalid page fault in module GKHTML.DLL at 014f:60250c0e. Registers: EAX=00bf192c CS=014f EIP=60250c0e EFLGS=00010202 EBX=00bf343c SS=0157 ESP=0063e3c4 EBP=0063e460 ECX=00bf343c DS=0157 ESI=00bf192c FS=0f5f EDX=601f1484 ES=0157 EDI=0063e4e4 GS=0000 Bytes at CS:EIP: 1f 60 ab 3b 20 60 ab 3b 20 60 3c 5b 1f 60 76 e7 Stack dump: 0063e4e4 00bf3444 00bf1960 009ea730 0063e45c 60249534 0063e400 60197c30 00be5b00 00000000 0063e438 601916a4 00be5b00 00000000 009ea730 0063e488 Rename xua.css back to ua.css - no crash.

Peter, sorry that this is such an old bug. It's basically saying we need better error handling in the toolkit. It's not really an ZPApps-specific issue until we present the error dialog. Which we can't do yet ...

reassigning to hyatt for triage

Giving to rickg's group. Minor bug.

marc -- an easy kill for you. We need to make sure we continue to operate adequately in the absence of the us.css file. Perhaps a backstop can be hard-code into the style system in case of emergency.

Probably want to create a synthetic sheet from a resource (or hard-coded): look at CSSLoaderImpl::LoadAgentSheet for starters. However, creating a synthetic ua.css is probably not enough, since it imports html.css and xul.css. I'm guessing we need to handle the case where those are missing too.

We don't need a backstop really -- just make sure we don't crash. In fact, we probably want to refuse to load the engine altogether if we can't find the ua.css file or any files it imports. (Just like if the main chrome is missing, we should complain and not start.)

FUTURE. The workaround is simple--don't blow away/rename ua.css in the first place, or if you do and this happens, put it back! Not a requirement for rtm.

Netscape's standard compliance QA team reorganised itself once again, so taking remaining non-tables style bugs. Sorry about the spam. I tried to get this done directly at the database level, but apparently that is "not easy because of the shadow db", "plus it screws up the audit trail", so no can do...

I'm not seeing a crash, but all pages are blank (but so what). Marking worksforme.

verified