User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20031007 Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20031007 From bug 206358 comment 42. Use of a -chrome with a standard Mozilla release on Windows does not shutdown the instance if an error occurs. If an error occurs, the whole instance should be shut down, so that the next use4 of -chrome can proceed reliably. All Windows versions. Reproducible: Always Steps to Reproduce: Turn off quick launch and other caching effects, and act like an app developer: Shut down Mozilla totally. From a Windows DOS/Command Box (my test box: PIII 800/128, Moz 1.6b, Win98se + fixes): cd "Program Files" (or Winnt etc) cd mozilla mozilla -chrome chrome://foo/content/bar.xul Since bar.xul doesn't exist, an error results. Close the error window. Check with Task Manager (Ctrl+Alt+Del). Mozilla still runs. Why? It is counter-intuitive and non-obvious why. Now load any valid XUL file using -chrome from the Dos Box. Probably it won't display at all. That is at face value very mysterious, not to mention problematic. Kill Mozilla from Task Manager. Try your valid XUL file again. It works. That XUL file is processed reliably at one time and not at another. Now make the XUL ill-formed XML. Repeat the whole thing. The ill-formed XUL does not even report a normal XUL syntax error window.

CC'ing folk recommended for this bug.

Can this be updated to status new? It's trivial to confirm.

confirmed Firefox 0.8 and 1.7rc1.

> From bug 206358 comment 42. Use of a -chrome with a > Steps to Reproduce: > Turn off quick launch and other caching effects, and act like an > app developer: No need to turn off the XUL cache or have some dev environment: this is ALWAYS reproducible, even with the default Firefox "factory configurations". Firefox starts but does not display if a chrome URI is opened via a JavaScript window.open method, or via a -chrome command line, whenever the chrome URI refers to an inexistent XUL file. A Firefox process sits back and cannot be closed, since we don't see it and don't guess that it's there (especially when this happens via a hyperlink or some package inclusion). This keeps Firefox from terminating "normally" (when the user clicks the top-right-corner "X", or via the File/Close menu command). Reproducible: ------------- Always Steps to Reproduce: ------------------- Example 1: Enter this exactly as shown at the command line (or menu Start/Run under Windows): "C:\Program Files\Mozilla Firefox\firefox.exe" -chrome chrome://whatever007/content/whatever007.xul Actually you could provide whatever name for the XUL file, as long as it does not exist. Example 2: Launch a new browser window window opening a chrome URI with an inexistant XUL file, via the window.open JavaScript function Impact: ------- Thus, the end user, being unaware that an instance of Firefox is actually running, could close then start Firefox again, try to configure/modify preferences, but notice that in the end none of his modifications took place (like if it was always showing the "previous" prefs.js for instance, which hasn't actually changed since it is being used by the hidden process). Of course, the current way to get around this is to open the Windows Task Manager (I use Windows, for other OS there should exist some "kill process" facility)... But this is unacceptable, as it suggests to assume that "John Doe end-user" knows about Firefox writing configuration stuff to this file and that file (ie when closing). And that the presence of the file parent.lock indicates a running instance, which can be killed via the Windows task manager (other OS have their own way for killing a running process/progrem) so that Firefox can close and then reload correctly. How can such a user "guess" about looking for the presence of a hidden process when they are unaware of the later or of its implication in regards to configuring preferences? There should be a way to make as such that Firefox detect such events, *before* letting the browser instance try to load an inexistent chrome... That's where it seems to hang, and if there is some mean like a return value to verify that, it certainly should get exploited.

(In reply to comment #4) I forgot to mention: - I am using Windows 2000 Pro (all patched) and Mozilla Firefox 1.0.4 latest release. - Opening an inexistant XUL file from the address bar of a browser window is ok : nothing happens, but Firefox terminates normally (as expected : no new window instance has been created to target the bad URL). - It looks like this one is a quite vicious bug, its existence going back to year 2000 (ref bugs 73893, 37743) REQUEST TO CHANGE OS - Since the root of that problem seems to have hadrepercussions since 2000 on Mac OSs, and all Windows, I propose to update the current OS for this bug to "ALL" (sorry, I am not aware of your vocabulary or ref nb. to write the correct one-liner.. ;) Note: If you need more human resource, I would be glad to provide mine, but understanding that I am currently learning the whole Mozilla platform...