When a Kernel bundle download fails or is cancelled, the current behavior is to simply continue running, allowing the appropriate error to be thrown in response (e.g. NoClassDefFoundError).  This seemed reasonable in theory, but it is proving inadequate in practice.

Programs do not expect to encounter NoClassDefFoundError on system classes.  They generally handle it badly, popping up a variety of misleading error messages.  JNI code, including much of the JRE's own code, often doesn't bother checking error codes for system classes (which are "known" to be present), causing an outright crash.  This happens in the plug-in as well, which crashes in response to failed bundle downloads -- but because it's running in the browser's process, the whole browser dies with it.

Clearly, we cannot rely on arbitrary programs to react properly to missing system classes, or users to understand the bizarre error messages and other problems that can occur when they cancel a bundle download.  The right approach is probably to pop up a dialog explaining that the current program will have to be shut down, and then gracefully kill it before it has a chance to display strange error messages or crash.  This will pose some special challenges in the plug-in, where we cannot call System.exit() without taking the whole browser out with us.