See testcase: - Open this testcase twice in two tabs or windows They both should act the same, but for me the second one opened doesn't animate. There seems to be heavy interference from the earlier opened testcase. I'm seeing more strange behavior. When opening a new window (of Firefox), my toolbar bookmarks menu is not expanded, when I have the testcase still open. That seems like another symptom of this timer related issue. As I write this,I still get this behavior after I closed the tab of the testcase and my cpu is still 100%. I suspect this has got something to do with the issues mentioned bug 277762, comment 10. Because when I use 10 instead of 15 moving points, I get the jerky/not smooth behavior when switching tabs between the two identical testcases.

I'm not seeing the bug in: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021212 But I'm seeing the bug in: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210

Bug 194994 related, perhaps?

I can't reproduce this -- I just loaded this in 7 or 8 tabs, and it all worked fine...

Indeed, I tried it now also in Linux, but the problem doesn't exist there. So probably a Windows only problem.

Over to widgetry... sounds like an event loop issue?

I backed out the fix from bug 183604 (with a minor adjustment, I had to add nsresult rv, otherwise it would not compile), and I can't see the bug with this backed out build. I haven't tested this build yet without this back out (that's something I'll do shortly).

Hmm, false alarm. After using a normal nsGlobalWindow.cpp I still can't see the bug with my own build (or should I rebuild everything, not just the dom directory?).

you also need to build layout/build when changing dom/

I see no problem in either my current Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050125 Firefox/1.0+ build, or in a downloaded nightly 20040204 Windows Firefox build. All windows simultaneously open animate equally well, though CPU usage does climb with additional windows just this bug report open, idle 0% 1 testcase window 20% 1 testcase + wave mouse around 40% 2 testcase windows 45% 3 75% 4 100% and animation quality degrades in all windows as the CPU strains harder. Martijn, I hope that two year old build you were testing with in comment 1 is only an attempt to track down when the problem first appeared.

Oops. It was a 20050204 build in the previous comment; today's.

mmm timers. Brendan, jst, any idea what's up here? Note that each object being animated has its own interval timer in this testcase. Could we be processing things slowly enough that we get past the point where the interval timer should have fired and then fail to fire it? Keep in mind that Martijn is using pretty slow hardware.

Ok, I've had a new Firefox non-debug build that showed this bug (I checked it) and then I applied the "What I backed out" 'patch'. After that I rebuilt dom/ and layout/build/ and after that the Firefox build didn't show this bug anymore. So I think the fix from bug bug 183604 definitely has got something to do with this bug. I'm testing this on a 800MHz Duron/128MB memory/Win2000. (In reply to comment #9) > Martijn, I hope that two year old build you were testing with in comment 1 is > only an attempt to track down when the problem first appeared. Yes, exactly. Unfortunately there are no builds available inbetween at archive.mozilla.org, otherwise I could give a more narrow regression range. What I backed out was just a wild guess (but seems to be a lucky shot).

I know it's a long shot since it's been broken since 1.3, but it'd be good to sort this timer issue out for 1.8...

Agreed, let's try to get this solved for b1 or b2.

Brendan, JST, BZ, any chance something's gonna happen here in the next few days? If not, can we push this out to 1.8b3 and hope for some work on it then.

I'm not going to be able to do anything with this; being unable to reproduce (no Windows) doesn't help. :(

Pav, can you take a look at this and see if you can help?

Johnny, any chance you can look into this? I suspect you're not the right person, but I'm desperate ;-)

I doubt I'll have any time for this for 1.8, nor do I see it absolutely necessary to fix it for 1.8

Well, when I have two tabs of the testcase open, the url bar does update itself when switching tabs or opening a new url only very occassionally (after 20s or more), so I'm seeing the wrong url in the url bar when switching tabs.

When clicking on the "open paypal" button I can see htpp://www.paypal.com in the url bar, but I see the text "This is content that doesn't come from paypal".

Is this just a symptom of but 291386?

(In reply to comment #22) > Is this just a symptom of but 291386? at least a side effect according to Brendan's setting of the dependency

Darin, you may be interested in this, since you seem to be working on bug 291386. The testcase might be useful to you or the "What I backed out patch", maybe (otherwise sorry to cc you).

This is working a lot better with the build Darin provided in bug 326273.

This is working almost perfect now! Both testcases are fixed. With the first testcase I notice a little sluggishness with the ui (basically what I mentioned in the first part of bug 326273, comment 9) when I have approximately 10 tabs of the first testcase open. But that's something I certainly can live with.