Mozilla becomes choppy after scrolling an IFrame within a frameset

VERIFIED FIXED in mozilla1.2beta



16 years ago
2 months ago


(Reporter: bugzilla, Assigned: kmcclusk)


(Blocks: 1 bug, {perf, regression})

perf, regression

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [ADT1], URL)


(2 attachments, 1 obsolete attachment)



16 years ago
(Under Win 98, Dell PII-350, 64MB Ram ATI Rage Pro Graphics)
When I scroll an iframe within a web page I get really choppy scrolling, this is
a new problem since they scroll fine in Mozilla 1.1 and IE. The first build to
exhibit this problem is : 
Mozilla 1.2b
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2b) Gecko/20020920
Nightly Build Folder: 2002-09-20-04

Can't work out which check-in would be most likely to have caused this problem
and haven't seen many other people complain about this yet..

Comment 1

16 years ago
You have any url or testcase to show this?

Comment 2

16 years ago
As it turns out, while trying to come up with a testcase I've found that the
scrolling performance of an iframe if fine, it's when that iframe is within
another frameset that things get sticky. Attachment coming up..
Summary: Choppy IFrame Scrolling → Choppy IFrame Scrolling (Within frameset)

Comment 3

16 years ago
Created attachment 100722 [details]
zip containing an example frameset and iframe

Extract these files and open the file index.html in mozilla, try scrolling the
iframe.. pretty bad on my machine..

Comment 4

16 years ago
Seing this also on Windows XP, build 20020924. Scrolling was smooth a while ago,
now its really choppy.
Keywords: regression
Assignee: attinasi → jkeiser
Component: Layout → HTMLFrames
QA Contact: petersen → amar

Comment 6

16 years ago
I'm not sure if this should be considered a Frames only bug (although it's
certainly most easily spotted using frames)- there's a general increase in
sluggish-ness in the whole UI compared to 1.1 (which I would say started with
nightly 2002-09-20-04)- any thoughts?


16 years ago
Ever confirmed: true
Keywords: mozilla1.2
OS: Windows 98 → All
Hardware: PC → All

Comment 7

16 years ago
Serously folks, things are really going pear shaped here, I'm surprised more
people aren't having problems- on the nightly phoenix build I'm getting ~0.5
second delays between any user input and a response by the browser (even on
pages without frames) - can anyone point me too another bug? Menus, links,
scrolling everything has gone to pot speed wise, is no-one else having this
problem? could it be graphics card specific?


16 years ago
Keywords: perf

Comment 8

16 years ago
Changing summary since this not only affects the actual scrolling but slows down
the whole browser.
Summary: Choppy IFrame Scrolling (Within frameset) → Mozilla becomes choppy after scrolling an IFrame within a frameset

Comment 9

16 years ago
*** Bug 171580 has been marked as a duplicate of this bug. ***


16 years ago
Blocks: 100951

Comment 10

16 years ago
WFM: Using 2002092904 trunk Mozilla build on WinXP on 750Mhz AMD. The example
scrolls smoothly. The url in Bug 171580 also scrolls smoothly.

Comment 11

16 years ago
WFM with trunk build : 2002-09-20-08-trunk on WIN2K. Marking wfm.
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME

Comment 12

16 years ago
I see this with Win 98, Build: ID 2002-09-28-08, but not with Build 2002-09-21,
also with an ATI Rage Graphics Card.
Mozilla will become unusable for me when visiting such a site.
Resolution: WORKSFORME → ---

Comment 13

16 years ago
This may be a Win 98/Ati graphics only problem (so quite common then..). Any
chance of someone looking at the checkins for the first build (nightly
2002-09-20-04) that went wrong to see if anything obvious changed?

Comment 14

16 years ago
This is not an ATI Graphics problem, I see this and I don't have a ATI-card.
Has anyone seen this on Mac?

Comment 15

16 years ago
I see this too. It should be noted that it isn't as much of a problem with the
scrollwheel, but it a serious problem with the manual controls. 

Win 98 - Nvidia Video Card

Comment 16

16 years ago
The best way to find out about this is to simply scroll anything on this page:

I have a NVIDIA graphic card with the latest drivers.

Comment 17

16 years ago
Hey, this is interesting.. If I'm using phoenix 0.2 (and I would expect in
mozilla as well), things are ok, scrolling is a little choppy on big pages like
slashdot's front page. If I then open a tab with my testcase frameset the
performance of the *WHOLE BROWSER* degrades, menus, links, scrolling, typing
-everything. If I close that tab again then things return more or less back to
normal. is each further frame sucking up processor time? Is their a change to
the way mozilla is listening for and processing event for each consecutive frame
within the frameset, resulting in slower performance with each set of frames
added to the frameset? Performance does not seem to degrade much with each new
document tab, just when more frames are present within a given document.
Note: there is no point marking WFM if your testing on a fast machine with
Win2k/XP - this may be Win98 only and is certainly more apparent on slow
machines (PII-350) - testing with a 750Mhz AMD and WinXP? come on guys... the
faster you can go the less you'll see a problem..

Randomly CC'ing folk who made checkin's to the first affected build.
nothing i did.

Comment 19

16 years ago
Also, one other thing,
scrolling anything on Mozillas Frame example (#9) makes CPU Usage go up to 100%.

Testing on 2000 and XP.

Comment 20

16 years ago
" testing with a 750Mhz AMD and WinXP? come on guys..."

Christopher: It is perfectly valid to put WFM: with any given configuration in a
bug for informational purposes. You'll notice, I did *not* close out the bug
after I put in that notation.

Comment 21

16 years ago
Sorry Kevin, I guess I felt that the chorus of WFM coming from netscape perhaps
sounded dismissive of the bug. I realise that's not the case.

Comment 22

16 years ago
Scrolling the iframe test is choppy for me under Windows ME using the
2002-10-02-08 trunk build. Tested with true color video(32 -bit) setting at 1152
x 864 resolution. 

Comment 23

16 years ago
According to Sebastian's comment #12 the regression happened  between 
2002-09-21 and  2002-09-28-08.  But Chrisopher indicates that the regression
appears on a 2002-09-20-04 build?  

Sebastian are you sure about it working correctly on the 2002-9-21 date?

Can others seeing this problem confirm that the regression is not present on a
2002-9-19 build, but it is present on a 2002-09-20 build to confirm the
timeframe for the regression?

Comment 24

16 years ago
Kevin: I'm not sure this was build 2002-09-21 (this was maybe build 09-20). I
cant make regression test, because has a 30GB HD (this is
ridiculous), and so is offering me only build since (including)
build 2002-09-24. 
(No I dont have resources to build from CVS)

Comment 25

16 years ago
I've re-tested the builds I have and for me the issue does make it's first
appearance in the 2002092004 build and continues to occur in 2002092104 (don't
have any later builds for that day)- the files in the first affected build have
the creation time of 2002-09-20 06:11 if thats any help.

Comment 26

16 years ago
Taking bug for further investigation. 
Assignee: jkeiser → kmcclusk

Comment 27

16 years ago
Created attachment 101779 [details] [diff] [review]
Fix enumeration of childwindows when dispatching pending paint events

Comment 28

16 years ago
I was able to reproduce the problem by increasing the number of iframes in
Christopher's original test case to 6 iframes. 

The patch I attached fixes the problem by correcting an error in the enumeration
of child windows which is performed to dispatch paint events after a mouse or
key event.

The current code incorrectly assumes that ::EnumChildWindows will process only
the direct descendants (its children). Instead ::EnumChildWindows processes all
of the descendants.

This causes a performance problem because nsWindow::DispatchStarvedPaints(HWND
aWnd, LPARAM aMsg) was calling ::EnumChildWindows which meant that the child
windows were being enumerated way too much. 

Comment 29

16 years ago
Created attachment 101782 [details] [diff] [review]
same as last patch with corrected comments.
Attachment #101779 - Attachment is obsolete: true

Comment 30

16 years ago
nsbeta1+, [ADT1]
Keywords: nsbeta1+
Priority: -- → P1
Whiteboard: [ADT1]
Target Milestone: --- → mozilla1.2beta

Comment 31

16 years ago
Comment on attachment 101782 [details] [diff] [review]
same as last patch with corrected comments.

Attachment #101782 - Flags: review+

Comment 32

16 years ago
Comment on attachment 101782 [details] [diff] [review]
same as last patch with corrected comments.
Attachment #101782 - Flags: superreview+

Comment 33

16 years ago
Fix checked into the trunk.
Last Resolved: 16 years ago16 years ago
Resolution: --- → FIXED

Comment 34

16 years ago
That done the trick, fantastic work! Thanks for that.

Comment 35

16 years ago
verified on branch 2003-06-03-05-1.4 winXP


2 months ago
Product: Core → Core Graveyard
Component: Layout: HTML Frames → Layout: Images
Product: Core Graveyard → Core
You need to log in before you can comment on or make changes to this bug.