MASTER - slow scroll with image as background-repeat

WFM Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4b) Gecko/20030408

Product should be PHOENIX

WFM Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4a) Gecko/20030408 Phoenix/0.5+
Athlon XP1600+ nForce

Well, I though it was a well-known problem, and I've seen it lots of times. I've
removed the fixed background on my website because of this. For me it's a dupe
of bug 90198.

WFM Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4b) Gecko/20030408
Celeron 333 MHz 96 MB Ram, SiS6326 Graphicscard (8 MB)

With this computer I see a difference in scroll speed, but speed is reasonable
fast in both cases. Both computers 800x600. But with both computers I had to
wait long, till all images from Phoenix Help were loaded.
On the w3.org testpage I didn´t see a remarkable effect, wouldn´t have noticed
slowness.

Actaully, for this particular page, it's a WFM (build 2003040910 on Mac OS X
10.2.4), even on my old 300 MHz iBook. The smooth-scrolling is the biggest
contributing factor. We've progressed immensily the last few months.

BTW: most of the urls in bug 90198 are about a fixed background. This bug is
about fixed positioning, and I think it's a dupe of another bug.

For reference:
Athlon 800Mhz (384MB PC100)
GeForce4 Ti 4400 (128MB DDR)

After seeing the WFM comments, I checked the pages again to see if I was crazy.
I got no significant slowdown, and couldn't figure out why. I think I'm getting
there, though. I've done some more testing, and am downloading a mozilla nightly
to see if this is phoenix-specific.

I am able to reproduce the problem by having certain other programs running
(though idle) at the same time as Phoenix. It seems to be a very binary thing;
either scrolling is seriously hampered, or it isn't. (And, well, yes--fixed
elements slow down a page even when this problem isn't present, but not by
nearly as much.) This reminds me of comments 18-22 or so in Bug 90198.

The program that causes the slowdown, on my machine, is a java-based text editor
(jEdit; http://www.jedit.org/). Any time it is open, the problem is present on
pages with fixed elements. Other pages seem unaffected, but that may be just
because of the inherent performance differences.

Additionally, (and this is strange) if I set the windows Task Manager to display
as 'always on top', and leave it over a page without fixed elements, that page
suffers from the same performance drop that pages with fixed elements do. This
seems to be less true of Winamp and the windows CD player, perhaps because they
take up less screen-space. That seems like it could be windows-specific; has
anyone encountered this in unix/linux?

Additionally, can anyone recommend some other java-based GUI programs to test
against?

just adding that I've confirmed I run into the problem in Mozilla as well as
Phoenix.

I see the choppy scrolling, but that happends with and without the menu being
fixed. Also blocking the images (remove background image) doesnt help. It gets
choppy in the top, where all the thumbnails are.

I've noticed that as well, but it's a different issue. If you are encountering
this, it'll be pretty drastic, and bad even down below the big image grid.

Marking NEW to get this somewhere. I couldn´t find a bug that explicitly deals
with fixed elements in general. I´m adding a dependency to bug 90198 which is
about fixed backgrounds.
Furthermore I believe this should block Bug 198964 ("Enable/disable smooth
scroll by default") since this bug is much worse when smooth scrolling is enabled.

Created an attachment (id=121395)
a testcase which let you choose 'fast scolling mode' and 'slow scrolling mode'
:)

I have discovered offscreen fixed div will make scrolling slow, however, if the
fixed div is in the document entirely, scolling speed is acceptable.

I hope this helps :)

On Firebird the fixed div will overpaint the scrollbar everytime the document is
scrolled, furthermore, I have tried to change it to offset to -10px to avoid
scrollbar repaint (which may account for scrolling slowness), but the scrolling
is still slow.

The slowdown is more apparent when you use 'up' or 'down' cursor key on your
keyboard to scroll :)

That is extremely helpful. Thanks!

roc+moz: I have just tested my testcase in (not so) nightly mozilla build on
Linux, and it seems that the problem is not as apparent, if there is any slow
downs at all, as my gtk2 phoenix build (which uses XP scrollbar...), so I
suspect my testcase is deomonstrating another problem other than general
slowness (or I have broken my source tree).

roc+moz: I have tried my testcase on Phoenix GTK2, Phoenix GTK nightly
(20030423) and Mozilla nightly (mentioned in prev. comment, 2003042307).

result:
1. my testcase
1a Phoenix GTK2: slows down (as exptected), red div overpaint on XP scrollbar.
1b Phoenix nightly (GTK): no slow down, however, red div still overpaint on GTK
scroll bar
1c Mozilla: no apperant scrolling slowdown, no red div overpaint, works perfectly.

2. texturizer theme page:
2a,b,c all three browser exhibits same problems:
1) it takes me a few clicks to get the menu locked.
2) mouse wheel is unable to scroll the page after the menu is locked (by 2+
clicks), until I have clicked empty area on document.
3) scrolling is slow, jerky, blah blah blah... after the menu has been locked.

-> Chu: Thanks so much for doing the heavy lifting here! I feel very bad about
abandoning the bug for two weeks...

Based on comment 15, I've downloaded mozilla 1.4a (Mozilla/5.0 (Windows; U;
Windows NT 5.1; en-US; rv:1.4a) Gecko/200304010) and tested the attachment in it
as well as phoenix:

On my system (was Win2k, now WinXP), /both/ Firebird and Navigator have /both/
the slowdown and the scrollbar overpaint. Perhaps this is a windows/linux
difference somewhere in the lower level stuff?

Created an attachment (id=121753)
similar patch isolating position:fixed from the scrollbar overdraw

Actually, now that I'm looking at this, there seem to be as many as three bugs here:

(1) Like in the bug's name, any pages with fixed elements scroll noticeably
slower than those without such elements. The second patch illustrates only this
bug. Additionally, on Windows2k/XP, I can duplicate this behavior on a page
without fixed elements (such as either attachment in 'fast' mode) by having an
'always on top' window overlapping the browser window. Can this be checked in linux?

(2) In the case that such a fixed element is displayed partially offscreen, two
things happen: (i) scrolling slows drastically, and (ii) the element can
overdraw the scrollbar.

(3) This is the bug I was initially encountering/reporting, and can no longer
reproduce. While running the program jEdit 4.01, mozilla/phoenix were scrolling
at speeds of around 5-6 px/second on pages with fixed elements. If I encounter
this again, I'll make a new, more specifically targeted (and better tested!) bug.

As it stands, I think it'd be best to focus on the first of these here, perhaps
make a new bug for the second if it's unrelated, and drop the third entirely.

Don't we already have a bug for point 2?!

just adding some comments based on my experience in the past few weeks.

In both Mozilla and Firebird, scrolling-speed is reduced on Windows platforms if
either of the following conditions exist:

1) The page contains a fixed element.
2) Another window (set in 'always on top') is partially or wholly on top of the
browser window. (Winamp, Task Manager, etc...)

The more fixed elements present (including windows 'on top' of the browser), the
more noticeable this slowdown is.

Other comments:

I'm still thinking this may be specific to windows, and perhaps how mozilla
paints itself under the OS. Can anyone cross-test this between windows/linux or
windows/OS X? I don't really have access to linux machines or non-uberfast OS X
machines.

I've tried to see how IE behaves, but can't get mine to display anything other
than backgrounds as fixed. Having windows on top of the IE window doesn't seem
to affect its scrolling speed at all, though.

Recent builds of Firebird slow down _much_ less than before. Neither test case
produces a noticeable slowdown at all on my Athlon 500. The texturizer page is
only barely choppy. What changed?

Just switched to the 25 August nightly of Firebird (from 6.1) and noticed that
things have slowed back down. A lot.

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030825 Mozilla
Firebird/0.6.1+
on Windows 2000
Athlon XP 2100

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5b) Gecko/20030825
Mozilla Firebird/0.6.1+/jtalkington-nightly
Power Mac G4
Dual processor system.

Anyway... this shows up both on Windows and OS X, so I'm betting Linux/Unix have
it too. Curiously, though, on Mac OS, having transparent or hovering windows
doesn't have much to do with it.

Created an attachment (id=133309)
shows various scrolling speeds/states

Per comment 19, I looked for other bugs for chu alan's test case and turned up
bug 186696 and bug 183495, but those both seem to focus on the scrollbar paint,
rather than the slowdown. I've made a new bug 222198 for this problem.

I'm adding an attachment to this bug allowing tests for scrolling normal,
fixed, and the above case where fixed elements are too big. Performance tests
for this page follow.

Created an attachment (id=133310)
shows performance differences for fixed/non-fixed scrolling

For this bug, I ran some performance tests to show better what I'm talking
about. While the slowdown on account of fixed elements (or a hovering window)
is hard to notice on my now fast machine, the difference in CPU use (and thus
for the user on slower machines) is very drastic! Other browsers do this much
more gracefully, so something's probably wrong.

Just downloaded Mozilla 1.5 and Firebird 0.7, and suddenly this is WFM -- CPU
use in all cases is below 10%, and scrolling's beautiful (apart from the
scrollbar overpaint).

The 1.5 Release notes said something about fixing windows GDI paint problems.
Maybe that's what this problem was? That'd make sense given the fact that having
a non-mozilla window hovering over the mozilla window caused the same problem.
What bug was that?

before closing this bug (and other related bugs), please have somebody check
other platforms as well

BTW from my distant memory, slow down occurs on GTK/Linux as well...

Definitely not WFM! Scrolling is still quite slow for me on pages with fixed
elements. The attachment (id=133309) (shows various scrolling speeds/states) is
no different between the "fixed menu" and "huge fixed menu" however.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031017
Firebird/0.7+ (aebrahim)

The testcase you mentiond is WFM with Mozilla/5.0 (Windows; U; Windows NT 5.1;
en-US; rv:1.6a) Gecko/20031028
Maybe this is due to graphic driver related problems too?

See Bug 222844 (a dupe i think), where reporter says position fixed is slower
with anti-aliased fonts.

To elaborate on comment #27: I suspect the graphics driver are relevant. I
recently replaced my Kyro-based card (Hercules Prophet 4000XT 32 MB TV-out) with
a GeForce2-based card (MX440; 64 MB) and page rendering generally appears to be
faster on some sites and this bug hardly appears anymore. The testcase scrolls
the same at both speeds. A site that used to be notoriously slow and has become
bearable, albeit still a bit slow, is djst's weblog:
http://weblogs.mozillazine.org/djst/
That page might still serve as a useful testcase.

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20031007

*** Bug 222844 has been marked as a duplicate of this bug. ***

http://www.lesproviders.com is very slow here. Firebird 0.7, Windows XP SP1,
PIII 1gh 256ram geforce2.

Perret, the page you mention does not have any element with position:fixed,
thats what this bug is about.

Both the testcases and the URL scrolls are WORKSFORME with Firebird 0.8 branch
build 20040120.

Also WFM with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031218
Firebird/0.7+

WFM
Mozilla 1.6
Win XP SP1
ATI Radeon 9700 TX
P4 2.53 Ghz

#32:
>Perret, the page you mention does not have any element with position:fixed,
>thats what this bug is about.

Actually, it does. Open
http://www.lesproviders.com/themes/L12_lesproviders/style.css and and you'll see:

<blockquote>background: White url(images/fond.jpg) no-repeat fixed top
left;</blockquote>

And to make things worst, it's a <a
href=http://bugzilla.mozilla.org/show_bug.cgi?id=90198>fixed background</a>.

I'm running "Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5)
Gecko/20031007 Firebird/0.7" and scrolling is painfully slow here too.

ps: btw, is the above CSS declaration a valid one? It isn't supposed to be a
"background-attachment: fixed;" somewhere?

I screwed big time in my previous post. Didn't know HTML wasn't supported.

Sorry!

Created an attachment (id=139911)
test demonstrating affect of multiple fixed elements

while working on a page design, i noticed that the number of position:fixed
elements affected the scroll speed, which led me to look up this bug. at first
it seemed like any number more than one would cause a serious slow down, but
after creating and playing with this test, i'm not so sure.

it's based off the previous attached tests, but has 5 elements that can be
locked and unlocked individually. there is a definite deterioration of
performance with multiple fixed elements. the most noticeable way i've found
to test it is to turn on smoothscroll, and use the keyboard arrows one line at
a time. with everything unlocked, it scrolls almost instantly. lock one box,
and it slows down noticeably, but not terribly. each additional locked box
seems to slow it down more. another way to test is to hold down the arrow key
then see how much it "coasts" after you release. with all unlocked it should
stop instantly.

tested in firebird 0.6.1 and 0.7 on windows 2000 sp3, pII 400mhz, 384mb ram,
16mb agp riva tnt. haven't touched a new build since 0.7, so i couldn't
comment on the recent WFMs. my computer is 5 years old now, and i wouldn't be
suprised if any newer computer with sufficient horsepower never saw these
problems.

while testing, i also uncovered another issue:
increasing the text size (CTRL +) with fixed boxes destroys performance even
more. oddly, decreasing it doesn't seem to have an effect. not sure if this
is a general thing or something unique to these testcases.

Can anyone reproduce this with a new build and a page that actually uses
position:fixed?

http://www.w3.org/Style/Examples/007/scrollbars.html - scrolls at about half the
speed of a page without fixed elements.

http://firefox.bric.de/index.php - pick the "fixed menu" stylesheet; scrolls
maybe 25% of normal speed.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040210
Firebird/0.8.0+

My system is fast enough at this point that I don't ever _notice_ encountering
this bug. Apparently I still do, though. On this page, and on the two Greg
mentioned, I tried measuring CPU load while scrolling by holding down the arrow
keys:

On this page, CPU use capped at ~10%
On both other pages, CPU use capped at ~80%

Both appear fine from my viewpoint, but obviously mozilla's working a lot harder
when fixed elements are involved.

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040206 Firefox/0.8

In reply to #38, yes this bug is still very noticable. If you go to
http://www.tweakers.net and scroll from the bottom up you'll see sluggish
scrolling at the top of the page. It uses many abs. positioned DIV's, some are
hidden some are not so the slow scrolling may be a combination of this bug and
bug 203439 - slow scrolling due to hidden, fixed-position elements, although the
latter probably depends on this one.

*** Bug 264630 has been marked as a duplicate of this bug. ***

I'm seeing this in Linux as well, I'm running Xorg 6.8.0 and dual monitors with
Xinerama.

Mozilla/5.0 (X11; U; Linux x86_64; rv:1.7.3) Gecko/20040929 Firefox/0.10.1

This is basically one of last major problems of the Gecko engine. Looking at
Opera 7.6 they seem to have fixed all their speed-related problems in Presto.
For me, this makes smooth scrolling not usable, which is quite sad I find.

(FYI: This page is the best (worst) example I've found showing the problem:
http://www.streeck.com/homepage.html )

Occurs in Win2k and WinME: Fx 0.10.1, Fx 1.0rc1, Moz 1.7.3, Moz 1.8a4

Oh boy, you don't want to see what it looks like when you position:fixed; a
flash or shockwave object; CPU usage goes out the window at over 50% on a P4C
clocked 3.09 GHz, 1 gig RAM, GeForce FX 5900. You'd think that my box could
handle this, but it's definitely a bug.

Demonstration of flash/whatever: http://www.bungie.net
At least they plan on changing the site when Halo 2 comes out, but this is still
an annoying bug.

this bug was opened 2003-04-09
whats so special about it that cant be fixed in more than a YEAR?

i have a P4 2.8, 512 DDR, ATI Radeon mobility (64 DDR) and scrolling is still
too slow!
btw, this bug isnt only for win2k.. i use xp

*** Bug 268683 has been marked as a duplicate of this bug. ***

http://www.warp2search.net/ also exhibits this problem. I've experienced the
issue with Windows XP SP1 & SP2 and Windows 98. This is an issue for more than
just Windows 2000.

This isn't just a Win2K bug, it's also evident on Windows XP and Linux. Not
sure about other platforms -- assuming they are also affected.

This is starting to become a very high profile bug, one that has turned off at
least one person I know from Firefox. I got him to switch with 1.0PR, but he's
into Halo 2 (as a huge number of my friends now). With the way Bungie.net is
designed (a very central part to Halo 2's multiplayer), it's painfully slow in
Firefox and fine in IE.

This might be a symptom of bug 124150. See my comment 66 in that bug.

*** Bug 271573 has been marked as a duplicate of this bug. ***

Those who play Halo 2 on Xbox Live usually go check their stats on Bungie.net
(http://www.bungie.net/stats/) and by "Those" I mean this:

Halo 2 - Xbox Live Statistics
(last 24 hrs)
Unique Players: 351,639
Matches Logged: 802,034
Players Online: 71,505

Hopes you guys can fix that soon, because it's getting pretty big now. Sorry
that I can't help. :/

*** Bug 249880 has been marked as a duplicate of this bug. ***

I am using the User Agent Switcher and set my agent string to Mozilla/4.0
(compatible; MSIE 6.0; Windows NT 5.1) and the bungie.net stats page scrolls
much better. I am using Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
rv:1.7.5) Gecko/20041107 Firefox/1.0. But the page is still slow, but now it is
useable now.

*** Bug 273064 has been marked as a duplicate of this bug. ***

seems to be fixed in 2005-01-08-07-trunk

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a6) Gecko/20050107
Firefox/1.0+

I tried this attachement
https://bugzilla.mozilla.org/attachment.cgi?id=139911

definitly NOT wfm

maybe it doesnt work for u because ur using yesterdays build, and it was only
fixed today. thats why i said it was fixed as of 2005-01-08-07-trunk. ur using
2005-01-07-?-trunk.

(In reply to comment #58)
> maybe it doesnt work for u because ur using yesterdays build, and it was only
> fixed today. thats why i said it was fixed as of 2005-01-08-07-trunk. ur using
> 2005-01-07-?-trunk.

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a6) Gecko/20050108
Firefox/1.0+

WFM

All testcases are fast

My stupidity,used the wrong build before

All checkins between 20050107 and 20050108 Win builds

bug 259126 [Firefox]-sites/exceptions list allows invalid hostnames [Win]
bug 187508 [Core]-Follow "full keyboard access" setting in System Preferences
for tabbing navigation [Mac]
bug 250276 [Core]-right-click, cut of BM inside folder inside PT crashes [@
nsMenuPopupFrame::SetCurrentMenuItem ] (aviary) [Lin]
bug 275828 [Toolkit]-#ifdef MOZ_THUNDERBIRD statements in Extensions Manager
hose Sunbird [All]

One of these must have fixed something...

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6) Gecko/20050108
Firefox/1.0+

I checked the testcases and they are close, but I still notice a subtle
slowdown. I recently upgraded my motherboard and processor and all the
fixed-element slowdowns got significantly better from the hardware upgrade.

Someone with an older/slower machine should test this since that's where the
slowdown is most noticeable.

Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:1.8a6) Gecko/20050108
Firefox/1.0+

I still have slowdown with the testcases. But it is faster then my
Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:1.8a5) Gecko/20041122

P2 450 Mhz

www.bungie.net is still slow for me, latest trunk build, Windows XP, Pentium 4,
3,2 ghz, ATI Radeon 9800XT

mine scrolls fine

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6) Gecko/20050109
Firefox/1.0+
Windows XP Home SP2
Pentium 4 2.53 GHz
80 GB HD
512 MB DDR Ram
ATI Radeon 9200 128 MB

About all the recent WFM comments:

1) If you're testing this with a relatively new machine, pull your task manager
up and check CPU usage. You may be surprised how much is going on, even if you
can't see it. See Comment 40.

2) Back when I was really trying to isolate this bug, it seemed like it only
started showing up after a certain something happened--fine up to a point, and
then suddenly slow--but I could never find out what that something was.

For what it's worth, the bungie site is still ridiculously slow for my machine
using Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a6) Gecko/20050107
Firefox/1.0+

Should we update the URL to http://www.bungie.net/, since the w3c scrollbar site
doesn't (visibly) show this bug on most people's machines?

Just noticed I was using the build you were complaining about, ColdFusion.
Unfortunately, I still get this even with today's build.

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a6) Gecko/20050109
Firefox/1.0+

Created an attachment (id=170761)
testcase with 100 fixed elements

Roughly the same testcase as before, just simpler, but with 100 fixed elements.

( after discussion what causes http://www.bungie.net/ to still be slow )

i have a fast computer, and on the regular test cases, it scrolls fine and the
cpu usage is at 2% (which a bunch of other programs running). the one with 100
fixed elements scrolls somewhat slower. barely noticable, and still only 2% cpu
usage. it seems that the new builds only minimize the affect of the fixed elements.

the tescase with 100 fixed elements scrolls notably slower on my pc (P4 1,6Ghz;
512MB DDR-RAM) with 20050110 Firefox/1.0+ . But if we look practicly
http://www.bungie.net/ is a site with over 30 fixed items, you can hardly call
that efficient coding. So you might wonder if the slow behavior of FF is not the
webdesigners fault

Created an attachment (id=170842)
transparent image for next testcase

Created an attachment (id=170843)
Testcase with 100 fixed transparent images

Wanna see slow.... ?

I see no noticeable difference between 1.0 and 20050110 on my 400MHz pII, 384MB
RAM, 16MB Nvidia TNT running at 1024x768x32.

For me the Bungie site is 2-3x slower than the "100 fixed transparent images"
test with either build, taking about 10 seconds per "scroll."

User Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5)
Gecko/20041107 Firefox/1.0

I'm noticing HORRIBLE performance in general with FireFox. I remember this back
in the Mozilla 1.6 days. It turned out to be a memory leak on that issue. When
running Horde (www.horde.org -- a web based mail client) the site refreshes
every 5 mintues. I'm just guessing here, but perhaps the meta refresh, or
javascript refresh, just isn't releasing the memory from the previous page.

After leaving my laptop (2.4 gHz w/ 1G memory) running for 24 hours, refreshing
away at my.yahoo.com and Horde, FireFox will gobble up almost 300M of memory.
Making it perform /really/ badly. On numerous occasions I've even had to just
kill the process.

I'm not sure how to provide debug information on what's being gobbled up, but
I'd happily perform some debug steps/logging for anyone whom needs it.

Cheers!

I visited a site today which pretty much brought my Firefox to it's knees
(20050117). I made a <a href="http://www.n3t.nl/mozbug/">minimal tescase</a> and
found something weird.

When I was making the testcase with Dreamweaver MX 2004 I found out the
scrolling speed improved. Closing Dreamweaver made it go slow again. Even after
I restarted my computer this behavior continued (having Dreamweaver open in the
background / minimized improved the scrolling speed of this page in Firefox).
Can anybody who has Dreamweaver MX 2004 confirm this?

Testcases are still slow here too.
Perhaps the bug 265610 is getting duped now by the widening of this bug
(transparant images).

*** Bug 280794 has been marked as a duplicate of this bug. ***

Alright, not only is there a significant rise in CPU usage [still], there is
most likely a memory leak along with it. If I recall correctly, multiple tabs
or subsequent viewings of pages such as bungie.net have an after-effect of
larger memory usage (and commit charge? it doesn't seem to use the memory it
creates, hinting at a leak). I'd recommend somebody make some memory dumps of
Firefox for scrolling on a normal page (like this one) and ones for pages with
massive amounts of overhead-inducing elements (such as bungie.net).

Also, if anyone could test this using a debug version of FF (enable/create the
debugs for any possible pages that include the code that may be inducing this)
and check back with us.

We should also try to find any other programs that improve or lag the
performance while doing so. This may seem like a bit of work to do (it is if
you're not used to debugging things...), but the fact that we haven't found what
is actually causing this bug yet after _almost_2_years_ calls for some major
hacking.

Primary areas to check: anything to do with page drawing, including the XUL bits
and CSS-related bits. Also, check the JavaScript core pages that include the
functions used to simulate position-fixed scrolling and the frameset-related
core bits as these two methods of pseudo position-fixed elements appear to work
in a more orderly and optimized manner.

~Matt

Also, would Mr. McCormick please add an alias to this bug, maybe
"position-fixed"? Thanks.

What about this page:
http://www.euronet.nl/users/frankvw/rants/microsoft/IhateMS_2.html

The scrolling is dead slow, in fact, it's unbearable.

(In reply to comment #78)
> What about this page:
> http://www.euronet.nl/users/frankvw/rants/microsoft/IhateMS_2.html
>
> The scrolling is dead slow, in fact, it's unbearable.

It is very smooth for me. Maybe cause I'm using more up-to-date version:
Gecko/20050326 Firefox/1.0+

The problem with declaring that a testcase works or not is that this effect is
resolution-dependent. The most recently mentioned testcase scrolls horribly for
me at 1600x1200, which I use normally, but if I resize the window to say,
800x600, it works fine. It's not a version issue since I'm using Gecko/20050404
Firefox/1.0+

(In reply to comment #78)
> What about this page:
> http://www.euronet.nl/users/frankvw/rants/microsoft/IhateMS_2.html
>
> The scrolling is dead slow, in fact, it's unbearable.

It works pretty fine with my version of FF (Mozilla/5.0 (Windows; U; Windows NT
5.1; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2).

I think the worse ever case is http://www.bungie.net and by far.

I have observed something interesting:
It only seems to happen for me if I have enabled ClearType font antialiasing.
With normal or disabled font antialiasing, scrolling speed is bad to normal,
same speed as with Internet Explorer.

Tested with FF 20050410 nightly trunk under Windows XP SP2.

(In reply to comment #79)
> (In reply to comment #78)
> > What about this page:
> > http://www.euronet.nl/users/frankvw/rants/microsoft/IhateMS_2.html
> >
> > The scrolling is dead slow, in fact, it's unbearable.
>
> It is very smooth for me. Maybe cause I'm using more up-to-date version:
> Gecko/20050326 Firefox/1.0+

In fact, you are using an outdated version.
I'm using:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050410
Firefox/1.0+

And that www.bungie.net site scrolls just as slow as the link I posted.

(In reply to comment #83)
> (In reply to comment #79)
> > (In reply to comment #78)
> > > What about this page:
> > > http://www.euronet.nl/users/frankvw/rants/microsoft/IhateMS_2.html
> > >
> > > The scrolling is dead slow, in fact, it's unbearable.
> >
> > It is very smooth for me. Maybe cause I'm using more up-to-date version:
> > Gecko/20050326 Firefox/1.0+
>
> In fact, you are using an outdated version.
> I'm using:
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050410
> Firefox/1.0+
>
> And that www.bungie.net site scrolls just as slow as the link I posted.

I confirm. I just installed the latest trunk release from Burning Edge (
Gecko/20050405 Firefox/1.0+) and there is an HUGE improvement in the scrolling
of bungie.net.

But FF 1.0.2 was very slow. There's still a little lag in the scrolling of
pages, but it's definitively smoother now. :)

(In reply to comment #84)
> I confirm. I just installed the latest trunk release from Burning Edge (
> Gecko/20050405 Firefox/1.0+) and there is an HUGE improvement in the scrolling
> of bungie.net.
>
> But FF 1.0.2 was very slow. There's still a little lag in the scrolling of
> pages, but it's definitively smoother now. :)

I can vouch for this as well. The scrolling on the pages referenced (bungie.net,
euronet.nl, testcases) is very smooth now, and better than comparable to IE6.
Using Gecko/20050413 Firefox/1.0+

Who knows why, but the last two comments are absolutely right!
Current trunk builds are displaying these much, much better than previous ones.
Bungie and the euronet.nl site both still consume 100% CPU on my machine, but
scroll (relatively) smoothly.

The original test cases all scroll beautifully, with negligible (~2%) CPU use. I
would probably have to consider this fixed :)

Oddly enough, though... I did some testing using variations of the 100-div test
case (11 divs, 22, 33, etc) and found that CPU use stays that low until about 25
fixed divs are present. After that, I get odd spikes, until at 30 I have pretty
much solid 50% or above usage. From there it rapidly hits 100%, but (as seen in
the bungie site) even with huge numbers of such elements, the 100% usage doesn't
translate to poor performance. Yay!

I wonder why CPU use is behaving so oddly... I'd have expected something more
linear. It feels like it's having to "clean up" after drawing a certain number
of frames, and as you increase the amount of drawing it has to keep track of,
that cleanup becomes less erratic and more constant. Then again, I have no idea
what I'm talking about. =P

In other news, I think the change comes from bug 205893, and after reading
through that one and bug 284978, I think I have an idea of what's going on in
the above two paragraphs, too. That's all I have time for tonight though. I
guess I would consider this resolved.

On the other side of the coin, the latest Mac builds of Firefox and Camino (the
20050413 builds) are still horrendously slow on these sites (this is a 700MHz G4
iMac with 10.3.8), so I wouldn't resolve this bug just yet. This could be
related to issues with Quickdraw; nevertheless, I think this bug deserves more
investigation. Even sites like Gamespot (http://www.gamespot.com/) lag a bit due
to all the multimedia (graphics, flash, etc.).

Is position:fixed is the same as background-attachment:fixed?

I only ask because www.warp2search.net is a scrolling nightmare (make sure you
are not blocking ads if you want to observe the poor scrolling). But on removing
background-attachment : fixed;
from body { ) definition in style.css - the page goes from scrolling nightmare
to fast & responsive.

That would be bug 90198. Since they've shown up (and not shown up!)
independently of each other, I think they're two entirely different problems.

Created an attachment (id=192468)
Testcase that shows how the fixed elements should act

I think this should stay open until fixed elements act the same as elements
objects with a scrolling element under it. This testcase will also work in IE
and shows that normal scrolling can happen with elements that don't move.

It is like the fixed elements are on a different paint event compaired to all
other elements. I don't know anything else that would cause fixed elements to
lag behind all other elements. I also would not write-off this bug just because
faster computers don't show this bug being that bad. Right now Microsoft is
writing-off all OSs under XP, we should not do the same.

We understand exactly what the issues are here. They're just not going to be
fixed for 1.8. 1.9 should be a lot better.

Seen using Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.4) Gecko/2007050903 Firefox/2.0.0.4. I have seen this before during testing on Vista as well.

1. Navigate to amazon.com front page
2. Scroll up and down and pay particular attention to the alignment of the text on the right hand side of the page.

As I scroll up and down, the text loses it alignment. When the scrolling stops, everything realigns fine.

I can't reproduce this with a branch build on Windows. Does this happen on the trunk?

I can't recall if I tried it on the trunk, but I will. It is a funny bug in that it is difficult to reproduce, but Gerv was actually standing over my shoulder the least time I reproduced it on Vista.

(In reply to comment #1)
> I can't reproduce this with a branch build on Windows. Does this happen on the
> trunk?
>

I am experiencing this problem, as seen on this screenshot:
http://img.photobucket.com/albums/v647/mu-lan/scrolling.png

It happens both in Firefox 2.0.4 and in the lastest trunk build of Firefox 3.0

It is very obvious on this page:
http://trainofthoughts.org/blog/2007/06/24/openpkg-apache2/

System: Windows XP SP2, Athlon XP 2600+, 1.5 GB RAM, ATI Radeon 9600 XT

Milan, I don't think this is the same bug. Actually, I think you're basically experiencing bug 201307.

Hi, I've been redirected from
https://bugzilla.mozilla.org/show_bug.cgi?id=380181

to this bug regarding a problem with text scrolling on a page with fixed background, where part of the text on the right side is aligned incorrectly in the vertical direction while scrolling and after stopping the scrolling, it gets back to the correct position as seen on the screenshot:
https://bugzilla.mozilla.org/show_bug.cgi?id=380181

this can be observed in both Firefox 2.0.4 and in the latest trunk build
on this page for e.g.:
http://trainofthoughts.org/blog/2007/06/24/openpkg-apache2/

System: Windows XP SP2, Athlon XP 2600+, 1.5 GB RAM, ATI Radeon 9600 XT

(In reply to comment #4)
> Milan, I don't think this is the same bug. Actually, I think you're basically
> experiencing bug 201307.
>

I'm sorry. I posted it into bug bug 201307 now.

WFM
Mozilla/5.0 (Windows; U; Windows NT 6.0; it; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a9pre) Gecko/2007101704 Minefield/3.0a9pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a9pre) Gecko/2007101704 Minefield/3.0a9pre

Simple scrolling takes very long and 100% CPU

Reproducible: Always

Steps to Reproduce:
1. try to scroll on the example page mentioned
2.
3.
Actual Results:
takes 100% cpu and is very slow (therefore)

Expected Results:
(normal) fast scrolling without 100% CPU usage just for that

*** Bug 394005 has been marked as a duplicate of this bug. ***

I run firefox 2.0.0.8 in ubuntu gutsy. I have both radeon and nvidia cards, and I tried opensource and proprietary drivers. This problem is very annoying and it is present in GMAIL, with the fixed element that shows the name of the following sender, when opening a long discussion.

I've been following this bug for quite a long time. I used to experience it a lot, but after some hardware upgrades many of the pages linked here, as well as the testcases, scroll at an acceptable speed (current setup: WinXP Pro SP2, P4 3.0 GHz with hyperthreading, GF 6600GT, 1.5 GB RAM (although no difference with when I had 512 MB)). However, the following page is still extremely slow:

http://forum.viva.nl/forum/list_topics/1

Both IE7 and Safari hardly have problems with it. In IE7 the text jumps up and down similar to in Firefox, but not as much. Safari is really smooth. I'll try my Linux partition later but expect the same results.

I think that someone should actually start solving this nasty problem,
as it is obvious that it is a problem...
I don't see a point in posting even more reports that oh I can see it too...
It is a bug in the code, It doesn't matter which graphics card you have, ... etc.
As Windows XP is the biggest platform (Vista is afftected) too, it's quite serious.

Created an attachment (id=303709)
Firefox 3b3 very very slow scrolling!!! (Firefox 2 scrolling fast)

"position: fixed;" is very importan for top menu on intranets. Browser is not good for intranets, when scrolling very very slow.

(In reply to comment #98)
I'm afraid this testcase will be worksforme for many users. I, for, one, see the same behaviour (i.e. no problem) with FF 2.0.12 and FF 3.0b3 on Win XP, Core Duo 1.8GHz, Nvidia Geforce 7600GS (a run of the mill machine, for today's standards)

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4pre) Gecko/2008021623 Minefield/3.0b4pre ID:2008021623

all testcase WFM except the last one with the large/huge table, which isn't really this bug

Huh? Ok, no testcase but realworld page--what about: http://www.assoziations-blaster.de/info/Physiker.html
It's slooow in Seamonkey and FF (both recent trunk) and blazingly fast in Opera.

Huh?
Peter: how can you call it "not a bug"? The last testcase works extremely slow on Gecko trunk, and very well on Firefox 2.

If that's not a regression bug than what? "feature"?

the one with 100 positionned elements is definitely choppy and eats 100% CPU while scrolling (tested with Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9b4pre) Gecko/2008021404 Minefield/3.0b4pre ID:2008021404). Works perfectly on the same machine which has decent current hardaware (core 2 duo 2Ghz, 2GB ram, Nvidia 8400M card) with Firefox 2, so this is a performance regression.

(In reply to comment #102)
> Huh?
> Peter: how can you call it "not a bug"? The last testcase works extremely slow
> on Gecko trunk, and very well on Firefox 2.
>
> If that's not a regression bug than what? "feature"?
>
That testcase is a bug, but not this one.
Large tables suck when scrolled, it has nothing to do with position:fixed

The testcase that is performing badly for me is the one with 100 positionned transparent images, not the one with 100 positionned empty so it looks like it is not due to the positionning of elements but to the alpha channel of images.

(In reply to comment #104)
> That testcase is a bug, but not this one.
> Large tables suck when scrolled, it has nothing to do with position:fixed

Let me repeat. The testcase with huge tables works very well and smooth on Fx2. It scrolls choppy on recent trunk.
I call it a regression and even if there are other issues with big tables, this one is another to put on the stack.

I also tried to turn off position:fixed on the huge table testcase and it does help.

Created an attachment (id=303996)
Firefox 3b3 very very slow scrolling!!! (Firefox 2 scrolling fast)

Now, I attach new version - table is bigger and scrolling is slower. See Cpu usage and compare Firefox 3b3 with Firefox 2.

For user with ~1.5GHz CPU it is big problem! For Linux terminal server it is big problem!

"position: fixed;" is very importan for top menu on intranets. Browser is not
good for intranets, when scrolling very very slow.

Shouldn't a regression like this be blocking or something? It seems like a pretty big step back.

I'm told this is A LOT worse than Firefox 2...

Indeed FF3 shows a scrolling performance regression for very large tables but it has nothing to do with THIS bug, as other posters already noted. Please look at bug #54542 which is a 'meta' bug for all large table perfomance issues. There are decent test cases in bug #54542 that would stress even modern machines. Perhaps you may open a new bug and make bug #54542 depend on it. I'm obsoleting the last unrelated testcase.

I've discovered that the height of my browser window affects the scrolling performance, the shorter the window is the smoother the scrolling, the taller the window is the slower the scrolling.

I decided to try changing the height of my Firefox window by a few pixels at a time until the performance dropped to an unacceptable level (noticeable jerkiness), this ended up being roughly 820 pixels.

This was my test page: http://www.developmentseed.org/

Specs:
Minefield 3.0b4pre (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4pre) Gecko/2008030206 Minefield/3.0b4pre)
Windows XP SP2
Celeron CPU 3.06GHz
2GB of RAM
GeForce 7300 GS
Screen resolution: 1280x1024

Here's a site that's really bad: http://www.theloudspeakerkit.com/shop/

(In reply to comment #112)
> Here's a site that's really bad: http://www.theloudspeakerkit.com/shop/

The above testcase is worth examining and doesn't seem to be affected by factors unrelated to this bug.

We can use gdk_window_move_region to scroll partial rects on GTK2 to speed up fixed-pos painting the same way we do on Windows. See discussion in bug 382392.

I can confirm this issue with Firefox 2.0.0.13 on Ubuntu Gutsy 7.10.

Previous attachment: https://bugzilla.mozilla.org/attachment.cgi?id=133309 is a good simple example that exhibits this issue for me.

I forgot to mention, I came across this bug after having issues mainly in Gmail, with the box showing the name of the sender in the next reply (mentioned in comment # 95), and also the "Loading..." box that shows at the top of the screen while loading a long thread.

Sorry for the double post.

Created an attachment (id=315511)
Demonstration: html file with big tables + css file

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9pre) Gecko/2008041306 Minefield/3.0pre
But it's been like this on at least the few last builds.
I'm using Vista SP1, Core 2 Duo T7500 2.2, 2gig of ram, 8400gt.

I just added a new attachments which demonstrates the slow down.

The html file contains very large tables but speed is very good if there isn't a fixed div, so I don't think this is related to bug #54542.

With only one (unlike comment #105) fixed div in the page 2008041306 Minefield/3.0pre is really slow, whereas Firefox 2 doesn't have any trouble displaying this page, not slow down at all compared to minefield. Safari and Opera are faster than Firefox 2 on this page as expected.
Even if there is a lot of code, Minefield stops using resources as soon as the position of this div is changed. It's h2#dateTitle{ on line 424 in the css file.
Firefox 2 is a bit slower if that div has a fixed position but it's nothing compared to the slow down occurring in minefield.

I first thought it was the transparent png used as background but removing it didn't change anything (bug #105).

As Rowan said in comment #111, there is a big improvement when the window is resized to a smaller size, but with a lower height, about 500px, but that's probably normal as it's a lot smaller window and faster to generate.

I don;;t have any problem in gmail, as other poeple talk about it early but that's probably not related. Probably Bug #424915.
I don't know about minefield on mac, I'll have a look tomorrow.

I realized this bug in Firefox 3 RC1. The scrolling speed of Firfox 3 RC1 is very catastrophic if you use the "Fixed" attribute in a stylesheet after a big background image (1680x1050 Pixels).

I include 3 examples, which show the bug!

http://abiads08.ab.funpic.de/test123/index.html <-- attribut: Fixed, big background image --> slow

http://abiads08.ab.funpic.de/test123/index2.html <-- attribut: Fixed, samll background image --> fast

http://abiads08.ab.funpic.de/test123/index3.html <-- only big background image --> fast

<style type="text/css">

 body { background:#09aeff url(bg.jpg) fixed center; }

</style>

As you can see the problem appears only if you are using big background images with fixed attribute in CSS.

For the record, I've had this problem in Firefox 2, 3b5 and 3rc1

In firefox 2.0.0.* if there is a fixed image like blog.the-erm.com has. Scrolling barely takes a hit, however in 3b5 scrolling speed is slowed down dramatically, and it's jerky in 3rc1 it gets much much worse. I couldn't handle using it for more than 5 min before I realized I better get used to 2. because I can't upgrade to 3 with this kind of performance hit. It's a pitty too, because I improvements to the browser bar. The net is my income, and one of the pages I have that makes me the $$ has such a div, If I started using 3, I'd loose hours out of my year waiting for the screen to update, and considering I don't get paid until the job is done. I'd be loosing time & money if I used 3.

I'm running kubuntu linux 8.04 in (kde 3.5.9). I haven't tested it in gnome.

But a fixed div with bottom:0; right:0; *really* makes it slow in 3rc1 so much so that I would consider running firefox3 to be a downgrade over firefox2. Some pages have this problem in firefox 2 because people are being stupid and have a big fixed background image on their page like myspace user always do.

True, this is defenitly a regression, there is a huge difference between 2 and 3RC I posted here 6 weeks ago and nothing has happenned since. Worse Firefox is now RC... I hope this is going to be fixed. If not I'll be using Safari for a part of my work as one of the tools I used has a lot of tables+cells and fixed elements.
Please, I really like Firefox, don't leave this unfixed.

I really hate "me too" comments, and don't mean to make one here... but I have to say I cannot imagine Firefox 3 going out with this bug.

A lot of sites, including MySpace pages as some have noted, blogs, etc. are affected by this bug. While it's true some may change things to workaround this bug - that's really bad from an evangelism perspective.

I know that it's already RC1, and I'm figuring honestly there's no chance for this bug. Worse, I'd try to help and make a patch or at least troubleshoot the code, but I really don't have time in the next few weeks to do so - just to complain. Still, I wish this was getting more attention - even if it has to be for 3.1... then I could tell people of the light at the end of the tunnel.

Thanks,
-[Unknown]

I don't see big problem on the exemple you give. But it seems that position:fixed causes FF3 a lot of troubles! 100% CPU and a big lag. :-(

We discuss it on a french board: http://www.geckozone.org/forum/viewtopic.php?t=65654

Try the given exemples:
http://actu.c4.fr/
http://csszengarden.com/?cssfile=http://www.s427.ch/divers/cssZenGarden/v02/sample.css
http://www.thestyleworks.de/quickref/index.shtml

It seems indeed to be much better now compared to how it was on that narrenschiff page - hardly to detect now even.

(in fact on http://actu.c4.fr/ the delay is obvious).

To those who comment(ed) and/or complain(ed) about this bug:

1- How many of you have smooth scrolling on?

2- "dead slow", "horrible", "unbearable", etc.. are very subjective adjectives which do not give any kind of accurate measurement, objective measurement, quantifiable data, comparable data like a performance profile comparison. 0.3sec could be deadly slow to you while 0.4sec could be just fast enough to person_B. We have no idea here. How big is the gap between horribly slow and fast enough in milliseconds? We have no clue, no idea, not even an hint. And we have to compare (and to assess) all these measurements regarding respective hardware, configuration, os, settings, etc... involved.

3- How long is a long table or a very long table? "very long" is still vague, not quantifiable, non comparable, non-specific, not really useful ... and I'm not even mentioning nested tables, deeply nested tables and over-excessively formated tables for layout purpose here..
"scrolling performance regression for very large tables but it has nothing to do with THIS bug". Dimitrios, comment #110

4- How many of you are mentioning webpages which have hundreds of validation markup errors, CSS errors, regarding webpages which can not in any way constitute a reduced testcase highlighting the issue in this bug?

5- How many of you are mentioning webpages that have lots of images, which are Flash-intensive, Flash-dependent, with a very large and deep DOM tree of nodes, with divitis and classitis, with thousands of javascript lines of code spread into several script files and functions, abusing setTimeout and setInterval, with generated content (like ads rotating, iframe refreshed), in over-constrained layout, over-excessively defined constraining stylesheets for pixel-perfect layout, etc.?

6- How many of you are mentioning webpages which would be considered - anyway and regardless - CPU-demanding, RAM-demanding, video-memory-demanding and user-system-resources demanding according to today's standards? How many of those webpages are already pushing the limits a bit far to begin with?

7- "'position: fixed;' is very importan for top menu on intranets": Do intranet webpage require 100 fixed elements?

8- How many of you are referring to characteristics which should be reported in other bugs (bug 90198, bug 64401, bug 202718, bug 54542, etc...) and not in this bug?

9- How many of you have read
What is a Simplified Test Case, and How Do I Make One?
http://www.mozilla.org/newlayout/bugathon.html#testcase

10- How many of you have read
How to Really, Really Help Developers on Bugs -- Minimal Testcases
http://wiki.mozilla.org/MozillaQualityAssurance:Triage#How_to_Really.2C_Really_Help_Developers_on_Bugs_--_Minimal_Testcases

11- How many background images (tiled) constitute the fixed background regarding the mentioned webpages? You do understand that one big image in the background is quite different from having 1px by 1px image repeated+tiled all over the canvas... Anyway, why such issue is mentioned in this bug and not instead bug 90198 .. if that is needed?

12- How many of you have actually read the Bug writing guidelines?
http://developer.mozilla.org/en/docs/Bug...

> 1- How many of you have smooth scrolling on?

Without, it's a little better, but 100% CPU anyway.

I think this bug https://bugzilla.mozilla.org/show_bug.cgi?id=400230 is a duplicate. I posted a few examples of lagging sites in it.

For me the worst is http://www.thestyleworks.de/quickref/index.shtml
Very, very slow!

(In reply to comment #122)
> To those who comment(ed) and/or complain(ed) about this bug:
>
> 1- How many of you have smooth scrolling on?
>
> 2- "dead slow", "horrible", "unbearable", etc.. are very subjective adjectives
> which do not give any kind of accurate measurement, objective measurement,
> quantifiable data, comparable data like a performance profile comparison.
> 0.3sec could be deadly slow to you while 0.4sec could be just fast enough to
> person_B. We have no idea here. How big is the gap between horribly slow and
> fast enough in milliseconds? We have no clue, no idea, not even an hint. And we
> have to compare (and to assess) all these measurements regarding respective
> hardware, configuration, os, settings, etc... involved.

Your comments are very long and I cannot answer all of the points, but I can answer these.

Let's use for a test case "http://www.tuaw.com/". The following builds of Minefield and Bon Echo will be used for comparison:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008052308 Minefield/3.0pre
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.15pre) Gecko/20080520 BonEcho/2.0.0.15pre

1. general.smoothScroll greatly aggrevates this bug. Since there is UI to turn this on, let's test with it enabled in both Bon Echo and Minefield, please. (note that the problem occurs with it off.)

2. Let us measure how long it takes to scroll to the bottom of this same page in Minefield and Bon Echo. I'm using a not-as-modest AMD 64 X2 3800+ w/2.0 gig of ram, a GeForce 7600 GT at 1280x1024, and XP SP2. We will preform this test by consistently scrolling the mousewheel. I'm timing using my iPhone manually.

Minefield (smoothScroll OFF): 00:08.2
Minefield (smoothScroll ON): 00:14.0
BonEcho (smoothScroll OFF): 00:07.1
BonEcho (smoothScroll ON): 00:07.2

However, Minefield in both cases gets a lot of shearing (a very distinct and definable phenonemon), whereas BonEcho is fine.

Now, this is not a reduced testcase as you say. Good point. Let's make it one. Go ahead and install Firebug in both browsers. For best results, use the same version of Firebug (1.1 or 1.2).

Open Firebug on the website, click "HTML", and then on "<body>". On the right, select the "Style" tab. Look for "background:", and click on it.

Change the value from:
#477CBD url(http://www.blogsmithmedia.com/www.tuaw.com/media/tuaw-bg.jpg) no-repeat fixed 50% 0pt

To:
#477CBD url(http://www.blogsmithmedia.com/www.tuaw.com/media/tuaw-bg.jpg) no-repeat scroll 50% 0pt

This removes the "fixed" scrolling being discussed here. Now, run the above tests again. You will notice a difference.

I imagine this may have to do with possible any of the following factors:
A. Screen resolution/browser size.
B. Length of page and number of elements overlaying background (most likely just height of elements.)
C. Size of background image (width/height.)
D. Positioning of the background image.

This is clearly a regression from Bon Echo (which had no problems here.)

-[Unknown]

@Unknown,

I commend your efforts to bring more formal steps to reproduce and more objective data/measurements (including possibly performance profiling) into this bug...

> Look for "background:", and click on it.
>
> Change the value from:
> #477CBD url(http://www.blogsmithmedia.com/www.tuaw.com/media/tuaw-bg.jpg)
> no-repeat fixed 50% 0pt
>
> To:
> #477CBD url(http://www.blogsmithmedia.com/www.tuaw.com/media/tuaw-bg.jpg)
> no-repeat scroll 50% 0pt
>
> This removes the "fixed" scrolling being discussed here.

... but all this is about background-position: fixed which is bug 90198, not this bug 201307. This 201307 bug shouldn't be far from being fixed if bug 203439 has been fixed. Again, I still think this bug should be resolved as WFM... unless someone can bring something real, concrete, reproducible, good testcase, etc... Who here experienced "slow scrolling" with attachment 139911 and with provided URL (http://www.w3.org/Style/Examples/007/scrollbars.html)?

Your post also identified how you scrolled (which is very good from a reproducibility perspective): you roll the mousewheel. You see, it could have been [PgDn], [PgUp], dragging scrollbar thumb up|down, clicking the scrollbar arrows or up|down key arrows...

------

@madjik

If smooth scrolling is ON, then it should be resolved as a DUPLICATE of
bug 202718 (Windows), bug 424308 (Mac), bug 409456 (Linux)

> preform this test
> by consistently scrolling the mousewheel.
>
> Minefield (smoothScroll OFF): 00:08.2
> Minefield (smoothScroll ON): 00:14.0

That has to be bug 202718, not *this* bug.

(In reply to comment #125)
> ... but all this is about background-position: fixed which is bug 90198, not
> this bug 201307. This 201307 bug shouldn't be far from being fixed if bug
> 203439 has been fixed. Again, I still think this bug should be resolved as
> WFM... unless someone can bring something real, concrete, reproducible, good
> testcase, etc... Who here experienced "slow scrolling" with attachment 139911 [details]
> and with provided URL (http://www.w3.org/Style/Examples/007/scrollbars.html)?

Ah, I confused this with that one (actually I thought they were the same, but now that I delve into my memory, I remember that there were two bugs after all.) Before I didn't care about that other one, because I thought it was reasonably fast.... then I forgot they were different bugs.

Sorry for the bugspam. IMHO, as a developer, I don't think this needs to be fixed at all for 3.0 or anything. Virtually no sites use position: fixed, it's not (or wasn't once) well supported across browsers anyway iirc.

That said, bug 90198 really is about a more general problem of it "being slow". Probably I'm looking for a more specific bug for this actual regression.

Sorry for the bugspam.

As for that attachment, it scrolls identically for me in Bon Echo and Minefield, and what's more, very quickly and without shearing. Again, I totally agree this bug is probably not a huge issue (and from the comments which I just looked over again, seems to find a lot of people confusing it with backgrounds.)

(In reply to comment #126)
> > preform this test
> > by consistently scrolling the mousewheel.
> >
> > Minefield (smoothScroll OFF): 00:08.2
> > Minefield (smoothScroll ON): 00:14.0
>
> That has to be bug 202718, not *this* bug.
>

Not really. I don't care about smooth scrolling. It's easier to reproduce using smooth scrolling (likely because of that bug) but I'm talking about the *recent* change in speed of scrolling with fixed backgrounds (compared to Bon Echo) whether smooth scrolling is enabled or not.

That bug is about both versions (and even older too), and I see shearing on the page it references even with my hardware and Bon Echo.

-[Unknown]

Firefox 3 2008052304

(In reply to comment #122)

> 1- How many of you have smooth scrolling on?
Nope it's off.

> 2- "dead slow", "horrible", "unbearable", etc.. are very subjective adjectives
> which do not give any kind of accurate measurement
1 sec between redraws maybe

> 3- How long is a long table or a very long table? "very long" is still vague
6 tables of 62 columns, 15 lines each, no backrgrounds on the cells.

> 7- "'position: fixed;' is very important for top menu on intranets"
2 fixed divs

> 4- How many of you are mentioning pages which have hundreds of validation errors
> 5- lots of images, Flash-intensive, Flash-dependent, with a very large and deep
> DOM tree of nodes with thousands of javascript lines of code spread
> into several script files and functions, abusing setTimeout and setInterval,
> with generated content (like ads rotating, iframe refreshed), in
> over-constrained layout, over-excessively defined constraining stylesheets for
> pixel-perfect layout, etc.?
> 6- How many of you are mentioning webpages which would be considered - anyway
> and regardless - CPU-demanding, RAM-demanding, video-memory-demanding and
> user-system-resources demanding according to today's standards? How many of
> those webpages are already pushing the limits a bit far to begin with?

Yes that's the case.

Maybe it should be slow then... regarding the mess in the code. After reading comment #122 this slow down could definitly be normal and justified. And a few people have probably been convinced that it's not a firefox problem.

The code is a mess and is pretty heavy, there's a fixed div with a png background, and there a png background. It's slow. Without the images it's better but still slow.
So I actually have 2 'bugs' here at the same time. But both of them have a big impact on performance.

I'm posting this because Firefox 2 handles it perfectly fine.

Like W. Brackets did, comment #124, rolling the scroll wheel as fast as possible, the time it took to scroll from top to bottom of the page, retried, 3 or 4 times if any difference:

Smoothscroll on
FF 2 about 5, 6 seconds, slightly slower than whithout smoothscrolling.
FF 3 2008052304 took an astonishing 48 seconds the first time and 50 seconds the second time I tested it. Where 20 seconds are spent on the last 200px of the page. 8 times slower?
We knew already that smoothscrolling did that, but I didn't really expect it to be this bad. Redrawn once per second as well, not worse then with smoothscroll off, but the distance scrolled at each redraw is a lot smaller.

Smoothscroll off:
Firefox/2.0.0.11 20071127: between 3 and 5 secondes, redrawing maybe 4 or 5 times a second.
Firefox 3 2008052304 after trying several times: between 13 and 15sec to scroll from the top to the bottom, with about 1 redraw per second. About 3 times slower...

But I don't really see shearing, a slight bit, but far less than some other websites on internet somethimes.

I'm not using smoothscrolling anyway, I don't use it.

This has been tested on a G5 1.8ghz 2gig ram, some nvidia card... I'm at work at the moment. But on Vista SP1 core 2 duo 7500, 2gig ram, 8400gt, the result is the same, it's faster...

> Yes that's the case.
>
> Maybe it should be slow then... regarding the mess in the code. After reading
> comment #122 this slow down could definitly be normal and justified. And a few
> people have probably been convinced that it's not a firefox problem.
>
> The code is a mess and is pretty heavy, there's a fixed div with a png
> background, and there a png background. It's slow. Without the images it's
> better but still slow.
> So I actually have 2 'bugs' here at the same time.

Or maybe the position: fixed bug has been fixed.

> But both of them have a big
> impact on performance.

Correct and appropriate QA bug management indicate that we shouldn't confirm a bug unless a set of conditions are met, a good, clear testcase, thorough search for duplicate has been done, etc.

> I'm posting this because Firefox 2 handles it perfectly fine.
>
> Like W. Brackets did, comment #124, rolling the scroll wheel as fast as
> possible, the time it took to scroll from top to bottom of the page, retried, 3
> or 4 times if any difference:
>
> Smoothscroll on
> FF 2 about 5, 6 seconds, slightly slower than whithout smoothscrolling.
> FF 3 2008052304 took an astonishing 48 seconds the first time and 50 seconds
> the second time I tested it. Where 20 seconds are spent on the last 200px of
> the page. 8 times slower?
> We knew already that smoothscrolling did that, but I didn't really expect it to
> be this bad. Redrawn once per second as well, not worse then with smoothscroll
> off, but the distance scrolled at each redraw is a lot smaller.
>
> Smoothscroll off:
> Firefox/2.0.0.11 20071127: between 3 and 5 secondes, redrawing maybe 4 or 5
> times a second.
> Firefox 3 2008052304 after trying several times: between 13 and 15sec to scroll

Then that is bug 202718, not *this* bug. Discussion, data, comparison regarding smoothscroll ON or OFF should not be in this bug.

> The website where I get this is on the intranet.

Realistically speaking, there is nothing to be done without being able to examine, investigate, test, performance-profile a webpage. We still would need a reduced testcase focusing and targeting (and highlighting) well the performance + behavior considered as incapacitatingly slow.

> I will try to upload a new archive containing the images/html/css files,
> stripped from the private information.

Please consult

What is a Simplified Test Case, and How Do I Make One?
http://www.mozilla.org/newlayout/bugathon.html#testcase

How many of you have read
How to Really, Really Help Developers on Bugs -- Minimal Testcases
http://wiki.mozilla.org/MozillaQualityAssurance:Triage#How_to_Really.2C_Really_Help_Developers_on_Bugs_--_Minimal_Testcases

I believe that attachment 139911 and this bug's URL
http://www.w3.org/Style/Examples/007/scrollbars.html
were adequate webpage and testcase for this bug. If no one experiences significant (measurable) loss of performance in those webpages with a trunk build, then this bug should be resolved as WFM.

@Gérard Talbot No offense but it looks to me as if you're trying to convince everyone that there isn't any bug. I do think there's is something with this position:fixed

I wasn't comparing smoothscroll.

Here are the results again, with smoothscroll off:
FF2: between 3 and 5 seconds, redrawing maybe 4 or 5 times a second
FF3: between 13 and 15 seconds, redraw once a second
that's 4 to 5 times slower.

I've posted an attachment already a few weeks ago, cleaned up from all the images only but not css. I know I should have created a simple file with a fixed div and some text... I did read the 'howto' file a bug and do tests, etc...

But in my case it's a bit complex. So please bear with me and maybe advise me on how to proceed with this case.

In this case:
I have a png in the background, and a png in the fixed div, and a hole lot of tables, lot of stuff styled... All together it's slow. See results above.
If I get rid of the fixed div. It's back to normal, it's not slowed down. This tells me I'm in the correct bug, and I'm not posting in the wrong place.
BUT with the fixed div:
If I get rid of the png backgrounds and keep the fixed div, it's still slow but a lot better. And when I get rid of all the css styles, then it's back to a normal speed. Speed difference slightly visible.

I know it really sounds like it's something else in the code that slows it down, but I've spent a few hours removing rules one by one to see if there was a performance impact. And it became better, gradually; I couldn't see any difference each time I removed a rule. In the end there wasn't much an impact between 'not fixed' and 'fixed'.

Concludion:
- Clean of images and css, difference slightly visible.
- Alltogether, css, images, etc... Big difference between the version that has the fixed div and the one that hasn't.

Now I'm only speculating on how this is possible...

in FF2, a fixed div might have a 50% performance impact... So between the version that may take let's say, 100ms, it will take 150ms if there is a fixed div.

in FF3, there might be a 500% performance impact.
So on the simple test case like attachment #139911 where it takes 10ms to draw without fixed div, it would take 50ms, with a fixed div. 50ms is not slow. The few attachment indeed do not have any significant loss of performance.
But if the page takes 100 seconds to be drawn without fixed div because it's damn complex, it would take 500ms to redraw with fixed div.

So no I will not post a testcase like attachment #139911, because it doesn't represent what I get. But i don't really have any other ideas to post a test case whitout all the css and images. Anybody has any ideas on how to create a test case for this?

> it looks to me as if you're trying to convince
> everyone that there isn't any bug.

I do not see a bug. I can not reproduce the problem when using a trunk build on windows. I can not reproduce the problem when trying all of the mentioned URLs so far, including this bug's provided URL http://www.w3.org/Style/Examples/007/scrollbars.html
and attachment #139911 . Now, if the bug is still happening on the trunk, then provide a testcase relevant and relative to this bug. Do you understand?

I am trying to convince you that several of the so-called URLs, testcases included in this bug were
- 404 not found
- redirected to nowhere
- abusing or depending on Flash
- abusing or depending on javascript
- have huge amount of coding errors, are examples of over-excessive formating, over-excessive coding, declaring, over-constrained layout,
- etc..

and that none of this serve the purpose of demontrating or reproducing or isolating a bug or faulty behavior or weak performance. If this bug still occurs, then at least a large minority of us should notice, measure something significant when trying attachment attachment #139911 or this bug's provided URL.

> I do think there's is something with this
> position:fixed

Fine! Then proceed accordingly with

What is a Simplified Test Case, and How Do I Make One?
http://www.mozilla.org/newlayout/bugathon.html#testcase

How to Really, Really Help Developers on Bugs -- Minimal Testcases
http://wiki.mozilla.org/MozillaQualityAssurance:Triage#How_to_Really.2C_Really_Help_Developers_on_Bugs_--_Minimal_Testcases

There are such things as the capability to reproduce a bug under controlled conditions, where we can compare data, examine testcases, use and compare (before fix and after fix) performance profiles, etc... Otherwise we shouldn't confirm a bug.

> I wasn't comparing smoothscroll.

Why do people in this bug keep mentioning smooth scroll then? Why can't you provide smooth scroll related data to respective bugs like bug 202718 (Windows), bug 424308 (Mac), bug 409456 (Linux)?

> Here are the results again, with smoothscroll off:
> FF2: between 3 and 5 seconds, redrawing maybe 4 or 5 times a second
> FF3: between 13 and 15 seconds, redraw once a second
> that's 4 to 5 times slower.

Which test case are you referring to? What's your overall system configuration for getting those data? I can not reproduce anything close to your data with this bug's provided URL http://www.w3.org/Style/Examples/007/scrollbars.html
and attachment #139911.

> I've posted an attachment already a few weeks ago, cleaned up from all the
> images only but not css. I know I should have created a simple file with a
> fixed div and some text... I did read the 'howto' file a bug and do tests,
> etc...
>
> But in my case it's a bit complex.

It is **NOT** just a bit complex. It's an 85 Kilo-byte HTML file (7598 lines of code, 86193 bytes!) with several linked (external and imported) stylesheets and several linked external javascript files that we can not see or examine with your RAR compressed file because your very long HTML file uses relative addressing, not absolute addressing. And I'm not even mentioning inline style, inline javascript cod...

Created an attachment (id=322577)
Simple test case with plenty of fixed divs (requires js.)

Here's an example that shows plenty of fixed divs.

Doesn't appear to be affected by using an image as a background or not. Greatly affected by smooth scrolling, but that's not this bug.

For me, performance is similar in Minefield and Bon Echo.

With this testcase, I detect a small amount of slowness compared to scrolling this bug report. I have a feeling it's dependent on system specs, but with my approx. 2-year old hardware it's barely detectable. With a 600 MHz PIII, it might be a different story.

One thing I notice is that the scrolling decelerates when it gets to the last 5 or so lines at the top or bottom of the page. This does not happen on a page without the fixed elements.

I see very similar performance with Fx2 and Fx3 RC.