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.
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
Assignee: general → general
Status: UNCONFIRMED → NEW
Ever confirmed: true
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
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
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
attached testcase worksforme with linux trunk 20040617 and 1.7rc3 (pops up dialog after ~30 seconds with pref set)
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
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
minor note, the preference is not dynamic. i bet if you change all.js it'll work. please report back either way.
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!
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
This was fixed by the checkin for bug 230909.
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
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?
You need to log in before you can comment on or make changes to this bug.