Closed Bug 111982 Opened 18 years ago Closed 17 years ago
Timeout() method fails without error with 2 embed tags (containing swfs) are present
720 bytes, text/html
1.04 KB, text/html
20.73 KB, text/html
5.31 KB, text/html
9.23 KB, text/html
6.40 KB, text/html
I think this is invalid. ".layers" is not supported in Mozilla.
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.
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
Completed installation of NS 6.2 (build 20011022) on Mac OS 9. Results: 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 Mac
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 developer). Just wondering...
Status: UNCONFIRMED → NEW
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 work. 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?
Status: NEW → ASSIGNED
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.
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: pref("plugin.enable_double_buffer","true");
I'm nominating nsbeta1 based on the nomination criteria -- this is important for Warner Bros.
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 controls. 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....
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
Status: ASSIGNED → NEW
attachment (id=80634) works fine in my current Mozilla and Chimera builds, although it is a bit jerky in Chimera. Marking WORKSFORME.
Status: NEW → RESOLVED
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.