Comment 291 for bug 125970

Created an attachment (id=354574)
testcase from real-world intranet with just one fixed div

No, this issue is NOT fixed with FF3.1b2 -- just checked.

Test system: Just upgraded my laptop to openSuSE 11.1 (kernel 2.6.27.7-9-default, xorg-x11-server-7.4-17.3, gnome-desktop-2.24.1-2.16, ATI Mobility Radeon 9600 M10 RV350 with open source driver xorg-x11-driver-video-radeonhd-1.2.3_081202_ed532a7-1.1 (closed source does not work)).

First checked with FF3.0.5, then after reading the updates here with FF3.1b2: Same results.

See attached testcase for our simplified intranet support ticket form. The fixed div in reality contains common text modules for our customer support.

I intentionally left the scrolling content "complex" (table with form elements) to retain a measurable difference:

FF3.0.5 and FF3.1b2:
 Scrolling top-bottom: 7 seconds
 ...with fixed div outside visible window area: 3 seconds

FF2.0.0.20:
 3 seconds, no matter if the div is visible or not

You may say 7 seconds over 3 is not that much a difference, but a) it feels much worse when scrolling by mouse wheel and b) it adds if you're working on lots of tickets a day. I let two of our support staff members check the FF3 test setup and both said it's unacceptably slow.

Just a thought about all these WFM messages in the bug history: I'd say this is a clue where to seek the bug. It seems to me this bug occurs only with certain graphics drivers. So if the FF3 rendering engine uses other low level functions for scrolling than FF2, i'd suggest testing if these functions perform well with all graphics drivers. Maybe one of these low level functions is rarely used from other applications and thus poorly optimized with some graphics drivers.