247225 - dom.max_script_run_time parameter doesn't work as expected

Status: RESOLVED FIXED

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

Description

[William J. Edney]

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

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

[William J. Edney]

Attachment: A testcase that pops the dialog box way too soon

Comment 2

[Brendan Eich [:brendan]]

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?

/be

Comment 3

[William J. Edney]

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.

Cheers,

- Bill

Comment 4

[Brendan Eich [:brendan]]

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.

/be

Comment 5

[William J. Edney]

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.

Cheers,

- Bill

Comment 6

[Andrew Schultz]

attached testcase worksforme with linux trunk 20040617 and 1.7rc3 (pops up
dialog after ~30 seconds with pref set)

Comment 7

[William J. Edney]

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

Cheers,

- Bill

Comment 8

[William J. Edney]

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!!

Cheers,

- Bill

Comment 9

[timeless]

minor note, the preference is not dynamic. i bet if you change all.js it'll work.

please report back either way.

Comment 10

[William J. Edney]

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

[William J. Edney]

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

Cheers

- Bill

Comment 12

[Boris Zbarsky [:bzbarsky]]

This was fixed by the checkin for bug 230909.

Comment 13

[timeless]

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?