bear with me on this one - it's kind of hard to describe what's going on. if you go to a long page such as http://cgi.pathfinder.com/time/magazine/articles/0,3266,22372,00.html or http://www.macintouch.com, scrolling down behaves differently than in legacy browsers. here are a few observations: communicator 4.51 using netcape's previous browsers, pressing page down or clicking beneath the thumb in the scrollbar scrolls the page down, replacing what you see in the browser window with about 90-95% new material and about 5-10% of old material (that is, what you already had on the page before you). for example, if you were looking at a page with the alphabet on it, each character on its own line, you might see this: (at first load) a ... f (page down) e ... r (page down) q ... z this makes things much easier for the reader, as there is some familiar text on the page which allows one to orient one's eyes more easily. however... seamonkey (apprunner, april 20 build) if you were to view the same page using apprunner, what you would get is this: (at first load) a ... e (page down) f ... q (page down) r ... z because the contents of the window change 100% every time you scroll down (in this case by clicking beneath the thumb in the scrollbar), it is significantly more difficult for the readers to re-orient themselves after scrolling down. when you scroll down, there is suddenly nowhere to look at the top of the screen that continues the sentence or train of thought you were only just reading at the bottom of the screen. i hope this makes sense to you... i'm cc'ing German Bauer on this if he has any further comments, they're welcome.

agreed the finding is right. In terms of how much there should be around 20 - 30 px overlap.

Rod, I thought you did some work on scrolling. If not, re-assign back to me.

I think this is a view or frame system issue, when it figures out how big the scroll jump should be

Patrick, I think this is a Scrolling View issue.

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

It appears that Bug 11751 addresses the same issue as this bug; however, the assignee of Bug 11751 seems to have landed some code that partially fixes the scrolling-distance problem (when GFX scrollbars are turned on), so perhaps it would be better to make this bug a DUP of that one, rather than the other way around. On the other hand, 11751 has a target of M13, one after this bug's M12. Decision time?

Giving to eric since he owns GFX scrollbars.

the two bugs are definitely daling with the same issue and are now assigned to the same engineer. So one bug should go away. I vote for this one. *** This bug has been marked as a duplicate of 11751 ***

verified duplicate of 11751.