347365 - There should be UI for setting dom.max_script_run_time

Status: RESOLVED WONTFIX

(Firefox :: Settings UI, enhancement)

Description

[Tony Mechelynck [:tonymec]]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.6) Gecko/20060804 Firefox/1.5.0.6
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.6) Gecko/20060804 Firefox/1.5.0.6

Details: see below.

Reproducible: Always

Steps to Reproduce:
1. Open "Edit -> Preferences" (or "Tools -> Options") menu
2. Open the various tabs and submenus, looking for the timeout delay before a script is declared "unresponsive".

Actual Results:  
Preference in question is nowhere to be found.

Expected Results:  
Preference should be found somewhere among the "Preferences", not only as a "needle in the haystack" under about:config


Additional information:
The time delay before a script is declared "unresponsive" and causes a popup message is currently fixed at 5 seconds, and can only be modified by means of about:config (or user.js). This 5-second delay is in many cases too short: after noticing that, in most cases, clicking "Continue" allowed (in Firefox) the page to open normally, or (in Thunderbird) the compose window for the "reply to all" email to open normally, with no adverse effects, I went on a hunt for where that timeout was defined. After a little trial-and-error, I have set dom.max_script_run_time to 30 seconds in Firefox and to 15 in Thunderbird; the result is much more satisfactory for me, with my kind of browsing and my set of installed extensions.

I realise that the ideal value cannot be determined once and for all, for all users of Firefox, Thunderbird, Camino and the Mozilla Suite; therefore I believe that users should be able to set this timeout easily to whatever value they prefer, without having to resort to a needle-in-the-haystack search in about:config.

This is all the more needed because, if and when the popup opens, the corresponding tab becomes focused, which can be annoying if the user was in the process of clicking on a link or a button.

Comment 1

[Steve England [:stevee]]

See bug 335058. (Landed for firefox 2.0)
dom.max_script_run_time has been bumped to 10 seconds.
dom.max_chrome_script_run_time has been introduced and set to 20 seconds.

This bug is about adding UI to the pref panel tho, which I doubt will happen, but isn't for me to say.

Comment 2

[Adam Guthrie]

I've got $5 saying there's not a chance in hell this is happening.

Comment 3

[Tony Mechelynck [:tonymec]]

Adam:
1. Note that I noticed this on Fx 1.5.0.6 (Mozilla 1.8.0.6 equivalent), not "2.0 Branch". I hesitated to put this bug into the category corresponding to Fx "1.5.0.x Branch" and left it "unspecified" because I thought it was more general.
2. Since you've restricted this to Firefox, I suppose I should file the same report with a different bug number for Thunderbird? I'm not enough of a guru to know for sure that this doesn't apply to "Toolkit" but originally I had tried to put it into a category that wasn't restricted to a single executable program. Maybe I goofed.
3. I'm not in hell yet, and I can always hope, can't I? I really believe that this "enhancement", as you call it, would make Firefox (and Thunderbird) better -- more user-friendly.

Steve: My whole point is that the ideal timeout value is probably different for different people so (IMHO) the setting ought to be easy to find, which means in the "Preferences" panel and not only in about:config and user.js . I use a different setting in Tb than in Fx myself, but neither of them is the default.

Upping the default timeout without making it easily accessible isn't IMHO the cure-all either: it will than take all that much longer to detect when a script is "really" hung. (How often that will happen may depend on the script -- I don't experience it often but YMMV.)

Comment 4

[Phil Ringnalda (:philor)]

(In reply to comment #3)
> 2. Since you've restricted this to Firefox, I suppose I should file the same
> report with a different bug number for Thunderbird? I'm not enough of a guru to
> know for sure that this doesn't apply to "Toolkit" but originally I had tried
> to put it into a category that wasn't restricted to a single executable
> program. Maybe I goofed.

Toolkit:Prefs is for the shared UI - the prefs window itself and some stuff that makes it easier to write content for prefs panels. Which actual preferences are exposed in that UI is a per-app decision.

Comment 5

[Tony Mechelynck [:tonymec]]

(In reply to comment #4)
[...]
> Toolkit:Prefs is for the shared UI - the prefs window itself and some stuff
> that makes it easier to write content for prefs panels. Which actual
> preferences are exposed in that UI is a per-app decision.

Ah, I see. Thanks for the explanation.

Comment 6

[Tracy Walker [:tracy]]

my $5 is with Adams.  I imagine the vast majority of users don't know about (nor care about) this timeout.  For those interested in it, about:config should suffice. Cluttering the visible prefs panels with obscure options probably isn't going to happen.

see bug 343464 for what may be a different way of handling the script timeout for long running scripts.

Comment 7

[Mike Connor [:mconnor]]

This is not something that's really useful to enough people to bother with it.

Comment 8

[Elomir]

I got the same issue in Thunderbird 24.3.0. 
About "This is not something that's really useful to enough people to bother with it.": 

1. http://lmgtfy.com/?q=Thunderbird+Script+Time+out

2. If ignoring users becomes the standard reaction for Firefox and Thunderbird (Bug ID: 248718, 296191, 434319, 492237, 582946, 632092, 68796, 347365, 578948, 77811, 332529; tabs back on bottom!!!), it really might be better for me to move to SeaMonkey.