478846 - Safe mode should not disable JIT

Status: NEW

(Core :: DOM: Core & HTML, defect, P5)

Description

[Dão Gottwald [:dao]]

bug 453642 comment 6:
> I don't understand why this is useful. If someone is crashing due to content
> JIT, there are easier and more obvious workarounds than "start in safe mode to
> disable it".

bug 453642 comment 10:
> > > By that rationale safe mode is pointless since there are specific ways to
> > > disable everything it disables.
> > 
> > That's not true - extensions and plugins can make the browser unusable enough
> > that disabling them is not possible (i.e. a crash on startup). Content JIT
> > crashes, on the other hand, can only be triggered by web pages that you visit,
> > and we have protection against pages continuously crashing you on startup due
> > to session restore (we avoid automatically restoring the session the second
> > time around).
> 
> Great point.  By that comment alone, that should be enough reason not to over
> code things needlessly.  Hell, we might as well just disable the whole
> javascript engine in safe mode if we are worried about crashes on webpages. 
> This bug just seems like a bandaid in that it is believed users are going to
> experience a load of crashes with JIT.  If that is the case, set JIT to FALSE
> until it is felt the code is stable enough for the default to be TRUE.

bug 453642 comment 14:
> This also makes it harder to figure out if there's a problem with an extension
> and whether or not it involves chrome jit. I.e. you can't use safe mode to
> quickly disable all add-ons -- the problem might be gone because jit is
> disabled, because an extension is disabled, or both.
> 
> For example, see the confusion in
> http://forums.mozillazine.org/viewtopic.php?p=5774025#p5774025 -- trying safe
> mode was entirely redundant there, as the problem was already known to be tied
> to javascript.options.jit.chrome=true. To see that there's no extension
> involved, the user had to manually disable all extensions.

Comment 1

[Benjamin Smedberg]

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.

Comment 2

[Matthias Versen [:Matti]]

The safemode should use the basic browser with everything optional disabled.

Only the support needs to be updated about what gets disabled,

Comment 3

[Dave Garrett]

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.

Comment 4

[:Gavin Sharp [email: [e-mail]]]

(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.

Comment 5

[Mike Shaver (:shaver emeritus)]

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.)

Comment 6

[Mike Shaver (:shaver emeritus)]

(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.

Comment 7

[Benjamin Smedberg]

The original bug was filed and fixed at jorendorff's request.

Comment 8

[Johnny Stenback (:jst)]

This isn't critical for 1.9.2.

Comment 9

[Underpass]

Maybe this is not critical for 1.9.2 but IMHO it should be documented in the Firefox Support Knowledge Base.