Last Comment Bug 247225 - dom.max_script_run_time parameter doesn't work as expected
: dom.max_script_run_time parameter doesn't work as expected
: fixed1.8
Product: Core
Classification: Components
Component: DOM (show other bugs)
: Trunk
: x86 Linux
-- major with 1 vote (vote)
: ---
Assigned To: general
: Phil Schwartau
: Andrew Overholt [:overholt]
Depends on:
  Show dependency treegraph
Reported: 2004-06-16 19:53 PDT by William J. Edney
Modified: 2011-08-05 22:37 PDT (History)
10 users (show)
asa: blocking1.7-
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

A testcase that pops the dialog box way too soon (375 bytes, text/html)
2004-06-16 19:54 PDT, William J. Edney
no flags Details

Description User image William J. Edney 2004-06-16 19:53:49 PDT
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040514
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040514

It seems that, given the combination of code in the attached testcase, that no
matter what the setting of the dom.max_script_run_time parameter is, the 'Script
Warning' dialog box will pop up about 5-8 seconds later anyway.

Reproducible: Always
Steps to Reproduce:
1. Use 'about:config' in a Mozilla 1.7 browser to set 'dom.max_script_run_time'
to some large number, say 30 seconds.
2. Run attached test case.

Actual Results:  
Dialog box still popped after 5-8 seconds.

Expected Results:  
Should have waited 30 seconds (or whatever you set it to) before popping the
dialog box.

I'm gonna mark this as major as it seems that, given the default time of 5
seconds, Mozilla 1.7 (and Firefox 0.9) pops this dialog box a lot more often
than previous releases. This is adversely affecting our product.
Comment 1 User image William J. Edney 2004-06-16 19:54:51 PDT
Created attachment 150998 [details]
A testcase that pops the dialog box way too soon
Comment 2 User image Brendan Eich [:brendan] 2004-06-16 20:30:13 PDT
Please use the right component when reporting bugs (any bug about a dom.* pref
ain't a JS engine bug ;-).

jst, anyone: this is the second report lately of the new time-based script iloop
/ recursive divergence watchdog barking prematurely.  Who will own this bug for
1.8a2, the 1.7 branch, and the aviary branch?

Comment 3 User image William J. Edney 2004-06-17 07:42:35 PDT
Brendan -

Oops (sheepishly).

All -

Here's a further hint for this bug. If you remove the inner 'JS-only' loop and
crank up the number of nodes that get added (to make just the DOM adding piece
take longer), the 30 second timeout seems to work. It seems that its some
interaction between doing JS work and doing DOM work, almost like its not
keeping track of the total time that work is being done between various pieces
of the system.


- Bill
Comment 4 User image Brendan Eich [:brendan] 2004-06-17 15:21:10 PDT
Bill: How do you run JS?  Always from script tags?  From event handlers written
in HTML (onclick, e.g.)?  From DOM event listeners added procedurally?  From
timeouts or intervals?

A reduced testcase, fast, would be awesome.

Comment 5 User image William J. Edney 2004-06-17 16:37:24 PDT
Brendan -

Well, for us it really depends.

The TIBET boot system, when in 'developer mode', creates 'script' nodes
on-the-fly and sets their '.src' attribute dynamically in order to get code to
load. When in 'production mode', it concats a big file together and makes
several large 'script' nodes where the script text is sandwiched between the
script tags themselves.

We tend to run a lot of JS from event handlers (i.e. event handlers being the
starting point), almost always added as event listeners using addEventListener.

The test case I attached last night shows the behavior and is about as far down
as I could reduce it. Not sure what you want here, but let me know and I'll do
my best.


- Bill
Comment 6 User image Andrew Schultz 2004-06-17 20:35:19 PDT
attached testcase worksforme with linux trunk 20040617 and 1.7rc3 (pops up
dialog after ~30 seconds with pref set)
Comment 7 User image William J. Edney 2004-06-17 22:01:13 PDT
Hmmm... testcase still pops dialog box for me after 5 or so seconds in Mozilla
1.7 final (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616).

Something fishy here. I checked my prefs.js file, but this wasn't even in there
(I've been setting it using about:config). I've checked it and double checked it
using that. Of course, I don't understand how the preference files work, so that
may be part of the problem :-).


- Bill
Comment 8 User image William J. Edney 2004-08-18 18:47:41 PDT
Anyone -

Anyone else still having this problem?

I just ran the test case up on Mozilla 1.7.2 and, even though I had
dom.max_script_run_time set to 30 seconds, I still got a dialog after 5 seconds.

If I could get someone here to take another look, I'd really appreciate it. This
is causing difficulties with our product.

Thanks a lot!!


- Bill
Comment 9 User image timeless 2004-08-18 20:16:26 PDT
minor note, the preference is not dynamic. i bet if you change all.js it'll work.

please report back either way.
Comment 10 User image William J. Edney 2004-08-18 20:36:13 PDT
Yep. That's it. Thanks a lot for the tip!

So, with that little piece of information, I'm changing this bug to:

"dom.max_script_run_time" parameter does not pay attention to its setting in the
user's local 'prefs.js' file (or when edited using 'about:config'). It only pays
attention to its value in 'all.js'. Note that I'm using Moz 1.7.2 on RedHat Linux 9.

Is there a reason why this *wouldn't* be a bug? Comments?

Thanks again timeless!
Comment 11 User image William J. Edney 2004-10-15 10:52:19 PDT
So I downloaded and tried Firefox 0.10.1 on both Windows and Linux and this bug
was not occurring for me in this browser.

OTOH, this bug is still exhibited in Mozilla 1.8a3.

It seems to me that this bug is preferences related and has little or nothing to
do with the actual machinery used inside of the JS engine / DOM code to track
maximum script running time. Of course, this opinion is from the peanut gallery ;-).


- Bill
Comment 12 User image Boris Zbarsky [:bz] (still a bit busy) 2005-10-07 07:30:57 PDT
This was fixed by the checkin for bug 230909.
Comment 13 User image timeless 2005-10-14 11:10:02 PDT
sorry for not responding, yes that was absolutely a bug. if this bug is fixed on
the 1.8 branch, since we're using it to half track this problem, could you
please add fixed1.8 to the keywords, thanks?

Note You need to log in before you can comment on or make changes to this bug.