The purpose of safe mode is primarily to give users something which is known to work... this allows them to take corrective action, such as disabling extensions or plugins or downloading a new version of the browser. I think we should disable anything which is optional and could potentially cause crashes. Given the general track record of JITs, I think it's likely there may continue to be odd crasher bugs, or more seriously non-crash bugs that render the browser useless but may not cause session restore to kick in properly. Figuring out which extension is the cause of a crash or hang is IMO a secondary concern, and we should keep disabling additional things in safe mode, perhaps including all content JS.
The safemode should use the basic browser with everything optional disabled. Only the support needs to be updated about what gets disabled,
In my experience, the common case is to use safe mode to see if a user's problem is caused by an extension or theme. It's theoretically a quick and simple way to separate out 3rd party code from the rest, making it act like it did before the user started installing add-ons. (though, plugins should be included here too, but that's another bug) Adding JIT to safe mode complicates things a bit. Might I suggest not toggling JIT like this and just adding a new command line option instead? Something simple like adding a -no-jit switch would let you quickly test with/without JIT in safe or normal mode.
(In reply to comment #1) > I think we should disable anything which is optional and could potentially > cause crashes. That list is very large. I think increasing the differences between safe mode and normal mode hurts rather than helps debugging, since it's harder to narrow down what is actually causing the problem. We already have a specific way to only disable JIT (the pref), so it's not like this change provided functionality that wasn't already there. > Given the general track record of JITs, I think it's likely there may continue > to be odd crasher bugs, or more seriously non-crash bugs that render the > browser useless but may not cause session restore to kick in properly. Given that we don't JIT chrome by default, that seems rather unlikely. If we're going to be shipping with the JIT enabled by default, then I don't think it's unreasonable to expect that requiring the use of about:config to troubleshoot issues with it is tolerable.
I agree with Gavin; we haven't had any other such features (chrome prototype cache, fastload, xpcom component data cache, etc.) in safe mode, and I don't see why the JIT is any different. (I'm a little surprised that the JIT-off-in-safe-mode bug was moved forward without asking for comment from the JS team, I admit.)
(In reply to comment #5) > I agree with Gavin; we haven't had any other such features (chrome prototype > cache, fastload, xpcom component data cache, etc.) in safe mode Haven't had such features *disabled* in safe mode, obviously.
The original bug was filed and fixed at jorendorff's request.
This isn't critical for 1.9.2.
Flags: blocking1.9.2? → blocking1.9.2-
Maybe this is not critical for 1.9.2 but IMHO it should be documented in the Firefox Support Knowledge Base.
Component: DOM → DOM: Core & HTML
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.