Closed
Bug 335058
Opened 19 years ago
Closed 18 years ago
script timeout too small in firefox
Categories
(Core :: DOM: Core & HTML, enhancement)
Tracking
()
RESOLVED
FIXED
People
(Reporter: ratan.work, Assigned: jst)
References
Details
(Keywords: dev-doc-complete, fixed1.8.0.7, fixed1.8.1)
Attachments
(5 files)
4.17 KB,
patch
|
bzbarsky
:
review+
brendan
:
superreview+
dbaron
:
approval1.8.1+
|
Details | Diff | Splinter Review |
4.17 KB,
patch
|
jst
:
review+
jst
:
superreview+
|
Details | Diff | Splinter Review |
7.10 KB,
patch
|
Details | Diff | Splinter Review | |
1.07 KB,
patch
|
brendan
:
review+
|
Details | Diff | Splinter Review |
623 bytes,
patch
|
brendan
:
review+
dveditz
:
approval1.8.0.7+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.2) Gecko/20060409 Firefox/1.5.0.2 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.2) Gecko/20060409 Firefox/1.5.0.2 We have been seeing "Warning: Unresponsive Script" dialog box a lot in yahoo mail beta and it happens a lot when some cpu intensive application is running on users box and they tries to check mail. The value of dom.max_script_run_time in FF 1.5.0.2 is 5 second. It seems to be too low compare to what IE offers. Even though user can change it in about:config but it is too hard to tell millions of users to do so. To compare it with IE: IE timesout after executing 5,000,000 statements on current page. http://support.microsoft.com/?kbid=175500 Wouldn't it be a good idea to set dom.max_script_run_time to 60 sec or something like that in FF by default (I mean something reasonably high)? The value of 5 sec seems to be too low. Some of the bugs already filed on it are: https://bugzilla.mozilla.org/show_bug.cgi?id=250841 https://bugzilla.mozilla.org/show_bug.cgi?id=330293 https://bugzilla.mozilla.org/show_bug.cgi?id=308205 https://bugzilla.mozilla.org/show_bug.cgi?id=320409 https://bugzilla.mozilla.org/show_bug.cgi?id=320020 https://bugzilla.mozilla.org/show_bug.cgi?id=320409 Reproducible: Sometimes
Reporter | ||
Comment 1•19 years ago
|
||
Some what related bug: https://bugzilla.mozilla.org/show_bug.cgi?id=311994
Comment 3•19 years ago
|
||
we bumped this up in minimo due to slower processors on mobile devices, and it seems to be working well there. might be worth considering for firefox 2.0 as well due to more use of intensive Ajax apps on the web.
Assignee: nobody → jst
Flags: blocking1.9a1?
Flags: blocking1.8.0.4?
Flags: blocking-firefox2?
Comment 4•19 years ago
|
||
mrbkap, brendan: what do you think?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 5•19 years ago
|
||
I have mine set to 1800 and don't see problems on public web sites. Of course that is too high, but 60 seems reasonable.
Comment 6•19 years ago
|
||
IE is not comparable, because as far as I know, it uses COM apartment threading to avoid problems hanging the whole app due to a runaway or rogue script. Locking up our UI for 60 seconds, without the Stop button even being live, is a bad idea. Even 10 seconds is long. This bug's reporter has heard it before: for cross-browser best results, break up long computations via setTimeout. This sucks in known ways for the few and elite hackers who write such long-running JS. It does not suck for the millions of end users, and they're the audience to optimize for, given the current browsers. Things will get better as we evolve JS and our execution model a bit, so don't get me wrong: we should be and are working on making things better for JS hackers. But I do not believe jacking up the limit, given the whole app locks up with no UI responsiveness, is the right answer. /be
Reporter | ||
Comment 7•19 years ago
|
||
Brendan, The problem with the time based script timeout is that if users' computer is running some CPU intensive task at the same time as Firefox then they will see the "unresponsive script dialog" too often if they are browsing around. We have done optimizations using setTimeout to avoid it and even though we see it at times when CPU intensive tasks like virus scan, backup is running on windows box. If time based script timeout is hard to fix then can we move FF script timeout to IE modal i.e. timeout based on number of statements executed and that way we can avoid FF script timeout dependency on other tasks in the system. Correct me if Iη₯ wrong on the dependency of CPU intensive task and firefox as that is what we have observed. Thanks for your response. Ratan Yahoo Mail Team
Comment 8•19 years ago
|
||
(In reply to comment #7) > Brendan, > The problem with the time based script timeout is that if users' computer is > running some CPU intensive task at the same time as Firefox then they will see > the "unresponsive script dialog" too often if they are browsing around. We have > done optimizations using setTimeout to avoid it and even though we see it at > times when CPU intensive tasks like virus scan, backup is running on windows > box. Sounds like the OS is starving Firefox, but let's say that happens and we have to work around it. > If time based script timeout is hard to fix then can we move FF script timeout > to IE modal i.e. timeout based on number of statements executed and that way we > can avoid FF script timeout dependency on other tasks in the system. We don't count statements. We used to monitor backward branches and returns in the bytecoded JS VM, but that was fixed using wall-clock time, because counting backward branches does not really count time at all, and the UI is locked up the whole while. That is, you could have 256K backward branches that run in < 1sec, or take > 60sec, depending on what goes on between the branches. > Correct me if Iη₯ wrong on the dependency of CPU intensive task and firefox as > that is what we have observed. How much computation are you doing between setTimeouts? If it's still a lot, any way to use a smaller quantum? /be
Reporter | ||
Comment 9•19 years ago
|
||
>How much computation are you doing between setTimeouts? If it's still a lot,
>any way to use a smaller quantum?
We have done the changes already to accommodate FF. Even though we continue to see the dialog and keep getting user complains. If users have to change the script timeout value to avoid "unresponsive script dialog" to get better web surfing experience then I think it defeats the purpose of keeping it too low.
I was wandering if it is possible to:
1. Log something in JavaScript console about the script that is causing this problem? This will help engineers.
2. In 'unresponsive script dialog', display users a preference to change this value. This will help web surfing users and they can make their own decision.
3. Worst case, allow javascript to hear this event from FF. This way we can display users an appropriate messsage as how to fix it.
e.g.
window.onunresponsiveScript = userAlertAboutPref;
4. Worst case, allow javascript to change this value for a browser session ( for that domain or all domain in that session)
window.max_script_run_time = 20000; //20 second, should be greater than default
Thanks
Ratan
Updated•19 years ago
|
Component: General → DOM
Flags: blocking-firefox2?
Product: Firefox → Core
Version: unspecified → Trunk
Updated•19 years ago
|
QA Contact: general → ian
Comment 10•19 years ago
|
||
Too late to test the implications and fall-out in 1.5.0.4, unblocking for this release.
Flags: blocking1.8.0.4? → blocking1.8.0.4-
Comment 13•18 years ago
|
||
Just my 2 cents. The timeout happens only when Firefox is opened. I have no problems once the program is loaded. I believe that's when Firefox checks for updates, and here lies what I think could be the problem: the dns lookup for mozilla takes about 20 seconds to be found. I counted the time connecting to the web site several times. So could that be what is really timing out.
Reporter | ||
Comment 14•18 years ago
|
||
comment #13 Timeouts happens even after Firefox is opened as I have seen it myself and have user reports of seeing it in Yahoo Mail Beta. Let me know if you guys need more info. Any plan to fix it in the next release as it was taken out of 1.5.0.4 release.
Comment 16•18 years ago
|
||
The script watchdog barking at our own lengthy extension-manager JS is a problem, I agree. Separate bug, arguably. That is, we could disable the watchdog during EM startup, and still leave this bug for later. Cc'ing Rob Strong and Mike Connor. /be
Flags: blocking1.8.1?
![]() |
||
Comment 17•18 years ago
|
||
Does this actually happen with the extension-manager JS? I haven't seen it in quite some time and have tested operations with 100+ extensions being installed, etc. without experiencing this.
Comment 18•18 years ago
|
||
(In reply to comment #17) > Does this actually happen with the extension-manager JS? I haven't seen it in > quite some time and have tested operations with 100+ extensions being > installed, etc. without experiencing this. Depends on OS and what all is running, competing for time slices and VM. It's possible to give Firefox too little real time and have the watchdog bark. Unless we think we'll save someone from an iloop but in EM or similar, we should disable the watchdog during startup, I think. /be
Comment 19•18 years ago
|
||
The default max_script_run_time is definitely too low. As you can see in bug #345493 it's triggered by simply reading a Slashdot page such as: http://yro.slashdot.org/article.pl?sid=06/07/21/0448225 I've had it happen on other legit websites too but I forgot to report the problem. Vital stats: Firefox-1.5.0.4, Linux Fedora Core 5, P4 2.4GHz - so this system is clearly not too slow. CPU idle is typically around 95...99% except when Firefox starts chewing that page.
Could we leave it 5 seconds for content and make it larger (30 or 60 seconds) for chrome JS?
Updated•18 years ago
|
Flags: blocking1.8.1? → blocking1.8.1+
Comment 21•18 years ago
|
||
Ideas, easy ones for 1.8.1 star'ed: - Bump to 10 seconds for all, or (see below) for content (*) - Split chrome and content as dbaron proposed (*) - Use process-virtual time, not real time (?) - Put up some modal UI that's polled from the branch callback often enough to seem responsive - Poll the Stop button /be
![]() |
||
Comment 22•18 years ago
|
||
> it's triggered by simply reading a Slashdot page
Er... in a vanilla no-extensions install? I see no slow script dialog on that page, with a MUCH slower machine (p3-733).
Assignee | ||
Comment 23•18 years ago
|
||
This makes us differentiate between chrome and content code (at the top of the JS stack) and gives us different prefs to controll the two limits. I set the default limit for chrome to 20, which is really high but hey, chrome code shouldn't iloop (or call content code that could iloop) to begin with. I don't know that these are the defaults we want, but I picked those numbers as defaults to have a starting point at least.
Attachment #230677 -
Flags: superreview?(brendan)
Attachment #230677 -
Flags: review?(bzbarsky)
![]() |
||
Comment 24•18 years ago
|
||
Comment on attachment 230677 [details] [diff] [review] Set different time limits for chrome and content, and bump content limit to 10 seconds. r=bzbarsky, but I think we should leave the non-chrome pref at 5 seconds unless that 5 is being a _really_ major problem. 10 seconds is a _very_ long time for which to freeze up the browser....
Attachment #230677 -
Flags: review?(bzbarsky) → review+
Comment 25•18 years ago
|
||
(In reply to comment #24) > (From update of attachment 230677 [details] [diff] [review] [edit]) > r=bzbarsky, but I think we should leave the non-chrome pref at 5 seconds unless > that 5 is being a _really_ major problem. 10 seconds is a _very_ long time for > which to freeze up the browser.... Problem reports from the field suggest our use of real time is a bug. If we used process-virtual time, we would be better off. Given this flaw, even 10 seconds on an overloaded system, with Firefox deprioritized for VM reasons, may not be enough wall time. Not sure we can get process-virtual time easily on all platforms. Cc'ing wtc, hope he is not too busy still and can give some advice. Thanks, /be
Comment 26•18 years ago
|
||
Comment on attachment 230677 [details] [diff] [review] Set different time limits for chrome and content, and bump content limit to 10 seconds. The patch is fine given the real-time design. Not sure we can do better for Fx2. /be
Attachment #230677 -
Flags: superreview?(brendan) → superreview+
Comment 27•18 years ago
|
||
Comment on attachment 230677 [details] [diff] [review] Set different time limits for chrome and content, and bump content limit to 10 seconds. >- sMaxScriptRunTime = LL_INIT(0x40000000, 0); >+ t = LL_INIT(0x40000000, 0); >+ } else { >+ t = time * PR_USEC_PER_SEC; >+ } One nit: given the righteous removal of LL_* elsewhere, do we still need LL_INIT, or would 0x4000000000000000LL not work on all platforms? /be
Comment 28•18 years ago
|
||
Brendan, I'm not sure if we can get process-virtual time on all platforms. I believe we can get process-virtual time on Unix (including Mac OS X and Linux) and Windows. The LL_INIT macro is actually intended for initializers. But that limitation only applies when PRInt64/PRUint64 is a struct. So it is fine now to use LL_INIT anywhere to construct a PRInt64/PRUint64 constant, even though the "INIT" in the name looks strange. Older versions of MSVC (such as 6.0) use i64/ui64 as the suffix for PRInt64/PRUint64 constants. I believe they are the only compilers that don't support the LL/ULL suffix.
Assignee | ||
Comment 30•18 years ago
|
||
Comment on attachment 231009 [details] [diff] [review] Patch that was checked in. This was checked in on the trunk, but I'll leave the bug open in case we want to explore alternative fixes for the trunk. Requesting 1.8.1 approval for this change.
Attachment #231009 -
Flags: superreview+
Attachment #231009 -
Flags: review+
Attachment #231009 -
Flags: approval1.8.1?
Comment 31•18 years ago
|
||
Comment on attachment 231009 [details] [diff] [review] Patch that was checked in. Johnny, >- sMaxScriptRunTime = LL_INIT(0x40000000, 0); >+ t = 0x4000000000000000LL; Have you tested this code under MSVC 6.0? It doesn't support the long long type and the LL suffix. You need to use the __int64 type and the i64 suffix with MSVC 6.0.
Assignee | ||
Comment 32•18 years ago
|
||
(In reply to comment #31) > Have you tested this code under MSVC 6.0? It doesn't > support the long long type and the LL suffix. You need > to use the __int64 type and the i64 suffix with MSVC 6.0. No, I have not, but Mozilla doesn't build with MSVC 6.0 any more for other reasons either, so I don't think we really care any more. If we do, I'm happy to revert that change tho.
Comment 33•18 years ago
|
||
(In reply to comment #32) > No, I have not, but Mozilla doesn't build with MSVC 6.0 any more for other > reasons either If this patch is going in on the 1.8 branch, I believe that we still use MSVC 6.0 there.
Assignee | ||
Comment 34•18 years ago
|
||
0x400..00LL turned tinderbox red too, so I had to undo that change on the trunk as well.
Assignee | ||
Updated•18 years ago
|
Attachment #231009 -
Flags: approval1.8.1?
Assignee | ||
Updated•18 years ago
|
Attachment #230677 -
Flags: approval1.8.1?
Comment on attachment 230677 [details] [diff] [review] Set different time limits for chrome and content, and bump content limit to 10 seconds. a=dbaron on behalf of drivers. Please check in to MOZILLA_1_8_BRANCH
Attachment #230677 -
Flags: approval1.8.1? → approval1.8.1+
Reporter | ||
Comment 36•18 years ago
|
||
FYI we are getting more reports of script timeout (unresponsive script) on Yahoo Mail Beta and I was wandering if anything got changed in FF 1.5.0.5 that can make it worse in new release. I will keep an eye on it and update the thread again.
Assignee | ||
Comment 37•18 years ago
|
||
Comment 39•18 years ago
|
||
Doing my regular "nightly" build with MSVC7.1, I get the following build error on the branch with the patch that was checked in: -nologo -W3 -Gy -FdnsJSEnvironment.pdb -DNDEBUG -DTRIMMED -O2p -Ob2 -GATF7 -GL -arch:SSE2 -MD -DX_DISPLAY_MISSING=1 -DMOZILLA_VERSION=\"1.8.1b1\" -DMOZILLA_VERSION_U=1.8.1b1 -DHAVE_SNPRINTF=1 -D_WINDOWS=1 -D_WIN32=1 -DWIN32=1 -DXP_WIN=1 -DXP_WIN32=1 -DHW_THREADS=1 -DWINVER=0x400 -D_WIN32_WINNT=0x400 -DSTDC_HEADERS=1 -DWIN32_LEAN_AND_MEAN=1 -DNO_X11=1 -D_X86_=1 -DD_INO=d_ino -DMOZ_DEFAULT_TOOLKIT=\"windows\" -DMOZ_PHOENIX=1 -DMOZ_BUILD_APP=browser -DMOZ_XUL_APP=1 -DMOZ_ENABLE_CANVAS=1 -DMOZ_DISTRIBUTION_ID=\"org.mozilla\" -DOJI=1 -DIBMBIDI=1 -DMOZ_VIEW_SOURCE=1 -DMOZ_XPINSTALL=1 -DMOZ_JSLOADER=1 -DNS_PRINTING=1 -DNS_PRINT_PREVIEW=1 -DMOZ_XTF=1 -DMOZ_MATHML=1 -DMOZ_SVG=1 -DMOZ_SVG_RENDERER_CAIRO=1 -DMOZ_UPDATE_CHANNEL=default -DMOZ_FEEDS=1 -DMOZ_STORAGE=1 -DMOZ_SAFE_BROWSING=1 -DMOZ_URL_CLASSIFIER=1 -DMOZ_LOGGING=1 -DMOZ_USER_DIR=\"Mozilla\" -DHAVE_UINT64_T=1 -DMOZ_XUL=1 -DMOZ_PROFILELOCKING=1 -DMOZ_MORK=1 -DMOZ_DLL_SUFFIX=\".dll\" -DJS_THREADSAFE=1 -DMOZILLA_1_8_BRANCH=1 -DMOZILLA_LOCALE_VERSION=\"1.8b5\" -DMOZILLA_REGION_VERSION=\"1.8b5\" -DMOZILLA_SKIN_VERSION=\"1.8\" -D_MOZILLA_CONFIG_H_ -DMOZILLA_CLIENT /cygdrive/i/Mozilla/mozilla/dom/src/base/nsJSEnvironment.cpp nsJSEnvironment.cpp i:/Mozilla\mozilla\dom\src\base\nsJSEnvironment.cpp(516) : error C2039: 'JS_IsSystemObject' : is not a member of 'operator``global namespace''' i:/Mozilla\mozilla\dom\src\base\nsJSEnvironment.cpp(516) : error C3861: 'JS_IsSystemObject': identifier not found, even with argument-dependent lookup make[5]: *** [nsJSEnvironment.obj] Error 2 make[5]: Leaving directory `/cygdrive/i/mozilla/objdir/dom/src/base' make[4]: *** [libs] Error 2 make[4]: Leaving directory `/cygdrive/i/mozilla/objdir/dom/src' make[3]: *** [libs] Error 2 make[3]: Leaving directory `/cygdrive/i/mozilla/objdir/dom' make[2]: *** [tier_9] Error 2 make[2]: Leaving directory `/cygdrive/i/mozilla/objdir' make[1]: *** [default] Error 2 make[1]: Leaving directory `/cygdrive/i/mozilla/objdir' make: *** [build] Error 2 Compile finished at The current time is: 18:54:46.48 Build failed Any help?
Comment 40•18 years ago
|
||
I suspect that this checkin also broke the 1.8 Camino builds: http://tinderbox.mozilla.org/Camino/
Comment 41•18 years ago
|
||
Comment on attachment 231177 [details] [diff] [review] Branch patch that was checked in. This patch has caused bustage in Camino for the 1.8 Branch.
Comment 42•18 years ago
|
||
It seems that removing the "ac_add_options --disable-jsd" option from the camino mozconfig fixes the bustage. Perhaps there is a better dependency work around (maybe an |#ifdef|)?
Status: RESOLVED → VERIFIED
Comment 43•18 years ago
|
||
It seems that removing the "ac_add_options --disable-jsd" option from the camino mozconfig fixes the bustage. Perhaps there is a better dependency work around (maybe an |#ifdef|)?
Comment 44•18 years ago
|
||
Oops sorry mouse caught the radio button.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Updated•18 years ago
|
Status: REOPENED → RESOLVED
Closed: 18 years ago → 18 years ago
Resolution: --- → FIXED
Comment 45•18 years ago
|
||
FWIW, this is the change I did to fix my 1.8 branch debug build on Linux...
Comment 46•18 years ago
|
||
(In reply to comment #45) > Created an attachment (id=231295) [edit] > FWIW, this should fix the 1.8 bustage... > > FWIW, this is the change I did to fix my 1.8 branch debug build on Linux... > This patch fixes the Camino 1.8 branch bustage as well.
Comment 47•18 years ago
|
||
(In reply to comment #45) > Created an attachment (id=231295) [edit] > FWIW, this should fix the 1.8 bustage... > > FWIW, this is the change I did to fix my 1.8 branch debug build on Linux... > I can also confirm that this fixes the problem on my local build (MSVC7.1) on WinXP.
Comment 48•18 years ago
|
||
I'm not familiar with this code, but if the function in question is now being used for things that aren't related to JS debugging, then it probably needs to be moved to a non-JS-debugging header, rather than bringing the debug header into a core JS file.
Comment 49•18 years ago
|
||
Mats, you should probably ask for review and get this patch in the tree...
Comment 50•18 years ago
|
||
(In reply to comment #48) > I'm not familiar with this code, but if the function in question is now being > used for things that aren't related to JS debugging, That's not relevant -- JS_IsSystemObject was always part of jsdbgapi.h. The bug that bit Camino was a latent one, a dependency on nested header includes. Since nsJSEnvironment.cpp directly calls JS_IsSystemObject, it must directly include "jsdbgapi.h". > then it probably needs to > be moved to a non-JS-debugging header, rather than bringing the debug header > into a core JS file. nsJSEnvironment.cpp is a core DOM file, rather -- but the main point is that "dbg" or not, JS_IsSystemObject and other reflection or non-main-API exports have been and will continue to be provided via jsdbgapi.h. That's not the bug, since that organization, however distasteful, has not changed. What changed was the direct dependency on JS_IsSystemObject from nsJSEnvironment.cpp being added without the necessary #include. I'll + the bustage fix -- mats, please check in ASAP. /be
Updated•18 years ago
|
Attachment #231295 -
Flags: review+
Attachment #231295 -
Flags: approval1.8.1?
![]() |
||
Comment 51•18 years ago
|
||
Removing the fixed keyword so we don't lose track of that patch...
Flags: blocking1.9a1?
Keywords: fixed1.8.1
Comment 52•18 years ago
|
||
Comment on attachment 231295 [details] [diff] [review] FWIW, this should fix the 1.8 bustage... Looks like dougt just checked this into the 1.8 branch (without approval!).
Attachment #231295 -
Flags: approval1.8.1?
Updated•18 years ago
|
Keywords: fixed1.8.1
Comment 53•18 years ago
|
||
It would be nice if the timeout prompt had a checkbox saying "don't ask again during this session" or something like that. It can be _very_ annoying to click on the pop-up 30 times just to complete the rendering of a page. I'd like the browser to just remember my last decision and apply it automatically.
Comment 54•18 years ago
|
||
(In reply to comment #53) > It would be nice if the timeout prompt had a checkbox saying "don't ask again > during this session" or something like that. > It can be _very_ annoying to click on the pop-up 30 times just to complete the > rendering of a page. I'd like the browser to just remember my last decision and > apply it automatically. > See bug 347365 for a different-but-complementary approach to solving this same problem.
Comment 55•18 years ago
|
||
(In reply to comment #0) [...] > Some of the bugs already filed on it are: > https://bugzilla.mozilla.org/show_bug.cgi?id=250841 > https://bugzilla.mozilla.org/show_bug.cgi?id=330293 > https://bugzilla.mozilla.org/show_bug.cgi?id=308205 > https://bugzilla.mozilla.org/show_bug.cgi?id=320409 > https://bugzilla.mozilla.org/show_bug.cgi?id=320020 > https://bugzilla.mozilla.org/show_bug.cgi?id=320409 [...] After reading the descriptions, it seems to me that most of the above are dupes of each other.
Comment 57•18 years ago
|
||
(In reply to comment #56) > Is this safe enough for the 1.8.0.x branch? > I don't know how to define "safe enough", but I do know that there have been requests by Fx/Tb 1.5.0.x users (me among them) to make the preference easier to find, because that same popup was so annoying. See for instance bug 347365 (Fx) and bug 347476 (Tb), which are not dupes of this one but relate to the same topic. I don't like bugspamming any more than anyone else, I just hope that some fix will be found for the 1.8.0.x/1.5.0.x branch before it becomes obsolete. Keep up the good work, you guys. :-)
Comment 58•18 years ago
|
||
We don't want this code change in 1.5.0.x, but if you want to increase the default pref (only) to 10 to accomodate popular sites that seems safe enough and we'd consider approving that. Would that be good enough?
Flags: blocking1.8.0.7? → blocking1.8.0.7-
Comment 59•18 years ago
|
||
(In reply to comment #58) > We don't want this code change in 1.5.0.x, but if you want to increase the > default pref (only) to 10 to accomodate popular sites that seems safe enough > and we'd consider approving that. > > Would that be good enough? Anything's better than the current situation.
Reporter | ||
Comment 60•18 years ago
|
||
Default max_script_run_time increase in 1.8.0.x/1.5.0.x branch will be appreciated as I saw it twice today on Firefox/1.5.0.6 I'm assuming FF 2.0 (1.8.1.x branch) will set it to following default as fix seems to be marked as 1.8.1 blocker. dom.max_chrome_script_run_time = 20 sec; dom.max_script_run_time = 10 sec I can see the warning dialog appearing everywhere if I throttle cpu on my box using slow or winThrottle
Reporter | ||
Comment 61•18 years ago
|
||
I have verified in nightly build that (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b1) Gecko/20060817 BonEcho/2.0b1) chrome script and content script run time are set to new values: dom.max_chrome_script_run_time = 20 sec; dom.max_script_run_time = 10 sec if possible then please increase content script timeout to 10 sec in FF 1.5.0.7.
Comment 62•18 years ago
|
||
Brendan: are you OK with just the time-limit change for the 1.8.0 branch?
Attachment #234346 -
Flags: review?(brendan)
Updated•18 years ago
|
Attachment #234346 -
Flags: approval1.8.0.7?
Comment 63•18 years ago
|
||
Comment on attachment 234346 [details] [diff] [review] 1.8.0 branch patch (just the pref change) Sure, in practice it's not going to cause hardship to wait another 5 seconds, and it sounds like it will help in some hard cases. /be
Attachment #234346 -
Flags: review?(brendan) → review+
Comment 65•18 years ago
|
||
Comment on attachment 234346 [details] [diff] [review] 1.8.0 branch patch (just the pref change) approved for 1.8.0 branch, a=dveditz for drivers
Attachment #234346 -
Flags: approval1.8.0.7? → approval1.8.0.7+
Assignee | ||
Comment 66•18 years ago
|
||
Pref-only change landed on the 1.8.0 branch.
Keywords: fixed1.8.0.7
Comment 68•14 years ago
|
||
There is no documentation on MDN yet for the introduced 'dom.max_chrome_script_run_time' pref by this bug.
Keywords: dev-doc-needed
Comment 69•14 years ago
|
||
Documented here: https://developer.mozilla.org/en/Preferences/Mozilla_preferences_for_uber-geeks#DOM_preferences
Keywords: dev-doc-needed → dev-doc-complete
Updated•6 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•