Closed Bug 111982 Opened 18 years ago Closed 17 years ago

setTimeout() method fails without error with 2 embed tags (containing swfs) are present


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

Mac System 9.x
Not set





(Reporter: davep626, Assigned: saari)




(Keywords: topembed+)


(6 files, 1 obsolete file)

From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Q312461)
BuildID:    20010726

The window.setTimeout() method fails without error when 2 embed tags are 
present on an HTML page.  Embed tags can contain no data and the problem still 
exists.  On the URL you should be able to scroll through the content on the 
page (setTimeout() method moves a layer up 7 px while the mouse is over the 
arrow).  But the method will not catch because there are 2 embed tags on the 

Reproducible: Always
Steps to Reproduce:
1.Create an HTML page with a simple setTimout()(increment a variable every X 
ms) method and 2 blank embed tags
2.View the page with Netscape 6.x on Mac

Actual Results:  Function fails without error.

Expected Results:  setTimeout() method should execute as designed

The following will demonstrate the problem:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

<script language="JavaScript" type="text/javascript">
var d = document;
var i = 1;

function simple() {
	if (i > 0) {
		setTimeout("simple()", 500);
		writeToLyr('aLayer', i);

function writeToLyr(lyrId, message) {
	var lyr = (d.layers)?d[lyrId]:d.all?d.all[lyrId]:d.getElementById
	if (d.layers) {
	} else {


<style type="text/css">
#aLayer {position:absolute; top:10; left:100;}

<body onLoad="simple()">
<div id="aLayer">

I think this is invalid. ".layers" is not supported in Mozilla.
Correct, ".layers" is not supported by Mozilla, but d.getElementById is, and 
that is what is accessed in the WriteToLyr function.  Neither have anything to 
do with the bug reported.

To test without the layer change the javascript to the following:
<script language="JavaScript" type="text/javascript">
var d = document;
var i = 1;

function simple() {
    if (i > 0) {
        setTimeout("simple()", 500);
        window.status = i;

David, if you would, please try to reduce your testcase to the barest possible
example---remove absolutely everything not needed to cause the problem---and
attach it hereon. 
You got it!

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

<script language="JavaScript" type="text/javascript">
var d = document;
var i = 1;

function simple() {
	if (i > 0) {
		setTimeout("simple()", 500);
		window.status = i;



<body onLoad="simple()">

Are you sure this is a setTimeout() problem? I know there are bugs about
window.status="..."; isn't always working in mozilla at the moment.
Greg, stop demanding simpler testcases when there's a perfectly good simple
testcase already.

David, I can't reproduce this problem with Linux build 2001-11-23-08.  It could
be that this is a Macintosh-only problem, but more likely it has just been fixed
since Netscape 6.01 (which you seem to be using based on the build date).  Could
you please retest with a recent build or at least with Netscape 6.2?
Oh, and I used the _first_ testcase because that does not use window.status so
avoids the problems jst mentions
I've tested on 2 different systems using NS 6.1.  I'm pretty sure this is Mac 
specific as it doesn't occur on any of my other systems.

Installing NS 6.2 now
Attached file 2nd test case
Completed installation of NS 6.2 (build 20011022) on Mac OS 9.

1st test cast works

When I tested the simple function with 2 blank <embed></embed> tags the 
function worked.

When I put data in the embed tags function failed.

See 2nd test case
Summary: setTimeout() method fails without error with 2 embed tags present → setTimeout() method fails without error with 2 embed tags (containing swfs) are present
second testcase also worksforme in a 2001-11-26 linux build
Can anyone duplicate this issue on Mac?
Johnny, I'm sure this isn't a window.status bug, as that was a simple function 
I created for a test.
Problem also exists on Mozilla 0.9.6, build 20011201, I just tested this on my 
Simon, could you have a look at this mac only bug? Let me know if you need help.
Assignee: jst → sfraser
Could the timer we use to send null events be interfearing? I don't see how, but
I'm not that familiar with it.
I doubt it's the timer specifically. The purpose of the timer is to send "null"
events to the plug-in so it "gets time"... this shouldn't interfere with normal
event processing.

My guess is more along the lines of... either the swf plugin or the
nsObjectFrame itself is eating (or not passing on) idle time events to the DOM.
My money's on nsObjectFrame. If you hold the mouse button down on either the
supplied url or test case 2 it works. This tells me that if we think something
might be happening (i.e. mousedown tracking) the event is passed...otherwise
it's not.
Beard has messed with nsObjectFrame events, iirc. Over to him.
Assignee: sfraser → beard
Being unfamiliar to this process, may I ask why this bug is still considered 
unconfirmed?  Brian, you seemed to have duplicated this bug, and I've indicated 
that I was able to duplicate it on several systems (although I am not a 

Just wondering...
Ever confirmed: true
This is a very strange bug. On Mac OS X in NS 6.2, the first test case 
works, but the second test case apparently stops working. However, if I 
hold the mouse down in the URL text field, or anywhere in another 
process, such as a window in the Finder, or one of the system menus, 
such as the volume control in 10.1, then the setTimeout() method does 

This is likely something wrong with our idle event handling code. Simon's 
really the one to look into this.
Assignee: beard → sfraser
This appears to be a Mac timer bug. The timer used to generate idle events in
nsObjectFrame is primed to fire every 1020 / 60 (=17) ms, and this appears to
starve other timers from firing, so the timers used to fire setTimeout in
nsGlobalWindow never fire.

Hopefully pavlov's new timer code will fix this.
cc'ing pav perhaps for comment on if his timer rewrite will address this
So I'm wrong and Simon is right (big surprise there :)). It is the timer, which
I verified by disabling, that is the problem here.

This basically seems to be a dupe of bug 88936 which Peter fixed by slowing down
the timer firing interval... The magic number in this case appears to be 50 ms.
More frequently than that and it fails.

The question is, assuming we continue to use timers for this task, how much is
idle time is too much (or not enough) for a plugin to receive?
This patch fixes the problem for me, and doesn't appear to starve the plugin
for idle time, but some additional testing might be in order.
The patch seems to do much more than increase the timer interval. Did you mean to 
include all the other changes? Or maybe you need to diff -uw
I changed some code that was using nsIPref to nsIPrefService. Not really part of
the patch per se, but something that should be done.

The other stuff was just a adding #define to limit mistakes.

I don't really even know if we want to go this route... see bug 106397.
Assignee: sfraser → bnesse
Happy new years everyone, any progress?
So, pav's timer re-write did not fix this... The question now is, do we like the
solution I have posted, or is there another tact we should take as beard
suggests in bug 106397 (which really only will fix the carbon build.)
I'd like to get some traction on this bug so let's take a different tact. Does
anyone think that increasing the timer interval is the wrong approach?
Target Milestone: --- → mozilla0.9.9
I'd like to understand *WHY* we're starving the setTimeout/setInterval timer.
Should we be instead considering raising the priority of those timers so they
can't be starved?
I don't understand how timers would get starved.  They get posted as PLEvents to
the thread's event queue... so unless the plugin is causing the mac not to
thread switch to the timer thread, things should be ok.
Blocks: 121552
Mac threads only switch if:

1) PR_Poll() gets called explicitly.
2) NSPR I/O primitives are used.
3) NSPR locking primitives are used.

That is to say, they are software threads. It's quite easy to starve threads if
you're not careful.
I will be helping Warner folks to find a workaround for this case (since the WB
web site is pretty important for us ;) If you guys have ideas please send e-mail
to me. 
I went to WB's site and looked at this today, and the scrolling now works.

Unfortunately it flashes quite badly, and once you start scrolling, it doesn't
stop. To release the "focus" on the scroll control, you have to click somewhere
in the window. This causes the scroll button to "release".

Marcio, do you know if WB did anything to this page, or is this a change in the
Mozilla code?
Works in what, Moz?  And we have not updated the code...will dl 0.9.8 if it's 
scrolling at all must have been a code change...
Confirmed on Mac os 9 build 20020405 first scroller is working with flashing 
area, second scroller the event keeps going until you click on the page.  Did 
you guys fix it???
The flashing may be caused by not double buffering on pages with plugins.
Although it may break other stuff, does setting this pref in all.js help:
I'm nominating nsbeta1 based on the nomination criteria -- this is important for
Warner Bros.
Keywords: nsbeta1
Target Milestone: mozilla0.9.9 → mozilla1.1
Keywords: nsbeta1nsbeta1+, topembed+
This bug has morphed into something else. The first 2 testcases appear to both
work correctly now. The WB page, however, still exhibits problems with scroll

It appears that the MouseOver, and more specifically the MouseOut, events are
not happening correctly. The scrolling starts as expected when the MouseOver
happens, but the MouseOut never (or rarely) seems to be generated.

cc'ing joki and saari as they may already be working on a dupe of this issue.
Attaching a severely reduced version of the WB test case... all plugins, etc.
have been stripped, only the text and scroll rectangles remain.
Attachment #60855 - Attachment is obsolete: true
Hmmmmm, the original issue concerned plugins directly (comment #11) setTimeout
() functions fine without plugins present....
Right-o. As per comment #36 that is no longer the case. As noted above, both of
the test cases attached previously now appear to work correctly.
Ahhhhhh, my bad, confirming Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.9.9) 
Gecko/20020311.  Although I was not able to reproduce the 'release' step, when 
I click on the window it keeps on going....
Attached file very simple test case
the last test case contains a lot of code for generating content on the LT
page.  This one is just scroller and text, seems to perform well too! (minus
the mouseout issue)
David, using today's build, your testcase works for me. The test case I posted,
however, still does not.

Assuming you can verify these findings... this would seem to indicate that
somebody checked in something that fixed part of the problem anyway. Now we just
need to identify the relevant differences between the testcases.
This one isolates the scroll code in the previous reduced WB testcase... The
only differenct between this one and testcase #79350 is the code, #79350 is
more Object Orientated.  The only other difference we would be the extra code
you originally carried over in testcase #79346.
Wow. Ok, the "reduced reduced" test case still fails "correctly". And I finally
noticed something... When you start the process of scrolling downward, the
window's vertical scrollbar thumb grows longer with each scroll, until it
eventually fills the scrollbar. At which point the scrollbar goes away.
Scrolling upwards reverses the process... Something is really confused here...
Another discovery. If I take the "very simple testcase" (attachment 79350 [details]) and
double the text... it breaks and starts to exhibit the same issues seen
previously (i.e. non stop scrolling and wierd scrollbar effects.)

Not sure what this means... yet.
It appears that we have come full circle on this bug. It is a timer issue.
Specifically the timer used in setTimeout(). We are, apparently, spending so
much time servicing the "timeout" timer that we are starving all other event
processing (in this case the DOM events that handle the mouseOut notifications.)

I completely eliminated the problem on the WB page by increasing the timeout
duration to 200 ms. This did not have any apparent effect on the scrolling speed
as we are already servicing the timer as fast as we can.

Hacking a fix into nsGlobalWindow that put a 200 ms floor on timer intervals
also fixes this... it also fixes bug 134451, an XP bug where the browser wedges.
Obviously this is not a good fix, but it does point us toward needing to insure
that events other than timer callbacks are being processed.
Changing QA contact
QA Contact: amar → desale
<topembed+ triage> Chris, can you re-assign this (one of Brian's old bugs) and
minus it if it is really just OS9?
Assignee: bnesse → saari
attachment (id=80634) works fine in my current Mozilla and Chimera builds,
although it is a bit jerky in Chimera. Marking WORKSFORME.
Closed: 17 years ago
Resolution: --- → WORKSFORME
#79350 and #80364 are still broken under OS9 using today's build 2003010712.
You need to log in before you can comment on or make changes to this bug.