Closed Bug 121552 Opened 18 years ago Closed 16 years ago

Event handling becomes sluggish at


(Core :: Plug-ins, defect, P2)






(Reporter: erick, Assigned: peterl-bugs)




(Keywords: perf, Whiteboard: [PL2:NA])


(1 file)

When is loaded in any window or tab, keyboard and mouse
handling becomes dramatically slower (say, a factor of 5) with an obvious lag
after typing or clicking.  This doesn't seem to occur on other pages on Apple's
site, including those with lots of embedded QuickTime.  My prime suspect would
therefore be the convoluted JavaScript and VBScript code Apple uses on its front
page to work around IE6 disabling Netscape plug-ins.

When more than one copy of is loaded, the effect is magnified!  On a
B&W G3/300 with 448M of RAM, I timed the speed of typing in the URL bar.  Under
normal conditions the typed letters appear instantaneously.  When one copy of is loaded, the throughput slows down to about 3 cps.  With a second
copy of loaded, the throughput becomes 0.5 cps.  That was painful
enough to preclude me trying three copies :).
Confirming issue on Mac OS X Jan 23rd build. Typing in url field seems to lag
behind user's typing. QT Movie appears to be created so that it plays in a
continous loop.
Ever confirmed: true
Type in URL field when movie plays.
Problem occurs on two machines (Dual G4 800 and iBook 500) This is more
noticeable on my iBook (500MHZ, 384 RAM, OS 10.1.2) rather than my Dual G4.
This may have to do with sending idel events to plugins and our timer priority...

If peter is correct the patch in bug 111982 should improve this. Also creating
only one timer instance as beard suggests in bug 106397 would eliminate the
magnification of the effect.
I tested this with a few other browsers (Opera Mac, Opera Windows, Netscape 4
Windows, K-Meleon), and all suffered performance drops to varying extents.  The
least affected seemed to be Opera Mac, which paused every half second, but let 6
or 7 characters through between pauses.

The problem seems to be specific to this particular QT movie, which uses sprite
tracks to perform the animation, so this may be an issue with Apple's QT plug-in
(the effect is not noticeable when the same movie is loaded in the standalone
QuickTime Player).
Keywords: perf
Target Milestone: --- → mozilla1.1
Assignee: attinasi → peterl
Component: Layout → Plug-ins
Depends on: 111982
Priority: -- → P2
QA Contact: petersen → shrir
Target Milestone: mozilla1.1 → mozilla1.0
Moving Netscape owned 0.9.9 and 1.0 bugs that don't have an nsbeta1, nsbeta1+,
topembed, topembed+, Mozilla0.9.9+ or Mozilla1.0+ keyword.  Please send any
questions or feedback about this to  You can search for
"Moving bugs not scheduled for a project" to quickly delete this bugmail.
Target Milestone: mozilla1.0 → mozilla1.2
Severity: major → normal
Whiteboard: [PL2:NA]
Target Milestone: mozilla1.2alpha → mozilla1.0.2
Target Milestone: mozilla1.0.2 → Future
1 year later... testing testing 1 2 3. I've got open and not seeing
any slowdowns. top says Mozilla is using 1.3% of my CPU time.

This must have been specific to a particular scripted movie.
OS: Mac System 9.x → MacOS X
In latest builds (20040420) is fine. However the QT movie attached
to this bug will cause URL bar typing to become very slllooooowwwwwww.
Upon further investigation, I believe this bug should be marked INVALID. The
problem has nothing to do with Apple's home page, and nothing to do with
Mozilla's QuickTime plugin.

Here's the deal: sprite-based QuickTime animations apparently suck up all
available CPU time. Download the bug attachment and open it in QuickTime Player.
Any process monitor will verify that your % idle immediately drops to zero.

Other movie types do not exhibit this behavior. Unless there is some specific
defect in Mozilla's keyboard-polling that is exacerbated by this bug, I think it
should be punted to Apple.
QuickTime problem.
Closed: 16 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.