At the CNN main page, I try scrolling down the page using the arrow keys and at some point, it appears to get "stuck" where the page keeps jumping slightly up and down and never actually moving down. It doesn't happen with all window sizes -- it seems like a smaller window is more likely to have the problem than a large one. It appears like it could be either an event error or a rounding error with the scroll bars, but I'm not really sure. Sorry, I may not have chosen the right component. (P.S. This is using the M4 build.)

This behavior is yet exhibited with the MICROSOFT WINDOWS 98 Apprunner of 1999062408 - but is difficult to reproduce.

i get the exact same behavior with the 6/26 build on windows 98 in apprunner. It occurs on both the mozillazine and the mozilla page. The problem also occurs in conjunction with the arrows keys jumping to either the bottom or top of the page.

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

From Bug 8760: Build ID: 1999062308 Platform: Windows NT To reproduce: - Load a longish page - At times, scrolling is jerky and skips screenfuls of information. (This behavior as 'posed to that spurning the view toward the top or bottom of the page - this reporter is yet able to unreliably produce that action and all those reported here as of the 1999062909 Apprunner build)

I tried this on Mozillazine.org and found this: ( Build 1999062808 ) WIN95 Click on an area of text in the middle of the page using the keyboard highlight the text Holding shift press the down arrow so the paragraph highlights itself The browser stops at the bottom of the highlighted text --- Do it again, but this time go up, the browser loops when the gets to the top of the highlight. It happens for me on all pages

Platform: Win95 Build ID: M8-1999070808 I have seen this problem with jerky scrolling as well, and was able to pin down when it begins. I don't think it has to do with the code of the page, but just any long page than requires scrolling to view all contents -- at least that is what I have seen so far. Here's how I reproduced: 1.) Load www.mozillazine.org 2.) Click in the window (to give focus for scrolling), but make sure you click over top of the title image. 3.) Scroll up and down with arrow keys. -> Motion should be fluid. 4.) Now, click on over top of any text, you don't need to select or drag. 5.) Scroll with arrow keys. -> Motion should become jerky. 6.) RELOAD the page, and you can start again (motion should restore to fluid). 7.) This time try clicking between the tables (between two 'talkback' box borders). 8.) Scroll with arrow keys. -> Motion should be jerky. 9.) RELOAD. 10.) Retest 2 and 3 to see that motion IS restored to fluid after reloading the page. You can try these over and over, reloading between each to see that motion is fluid until the mouse click is over a piece of text or a valid text area (if that makes any sense in the architecture of the page layout). -- Here's another... if you reload, and click next to the text inside the talkback box that reads "(n responses)", clicking about 10 pixels away from the text where you won't actually activate text, the motion will not become jerky. It only becomes jerky after clicking over text or an area delineated for text. I hope that last bit made a hint of sense.

The bug being discussed seems to occur on all webpages, the skipping of pages of text, if you hold down the arrow keys the pages skips to the bottom no matter where you are in the page.

same thing on Linux, seems to be on all platforms... by the way, it seems (at least on Linux, I don't know on other platforms that when some page switch occur, about 200 pixels on the left of the HTML viewer window is not painted at the same time as the rest is... (odd cosmetic effect)

I don't see a difference in scrolling on Macintosh.

m12

Is this really a problem with the activex component? If not, please reassign to the correct component. A bug may have changed this bug's component.

No, it's not activeX. Not sure if its actually views or event handling so I'll take it in event handling for now.

Moving to m13 because Joki seems to be distracted.

Mass-moving excess bugs to M14

Moving to M15

Under Windows 98 with M13, I have a problem like this, but not identical. It starts up displaying some of a long page (say, a slashdot.org comments page in flat mode), and scrolling works for a bit, but then locks up -- it won't scroll back up or down -- until more of the page is loaded. The wait can be several seconds, perhaps as many as 10.

Under Linux with M13, I experience that when I scroll up or down a page, the CPU usage of my laptop goes shortly to 100% and page scrolls slowly. When same page is blocked, if I try to scroll up or down pressing up or down keys, my CPU goes again to 100%. And while I'm editing a text, as like now as I'm writing this comment, if I move back with left key or move ahead with right key, once again my CPU reach 100% and the cursor moves slowly. But if I move back with backspace key, so deleting text, this operation works fine and fast, without charging of CPU

andrew - that sounds like it could be bug #17325 instead.

I use M14 on a more-or-less RedHat 6.0 system (kernel 2.2.14)with a Cyrix 150 chip. Tke vertical scrollbar stuck in the Edit / Preferences / Appearence / Fonts / Serif menu.

Mass-moving bugs out of M15 that I won't get to. Will refit individual milestones after moving them.

Bulk prioritizing bugs for correct milestones.

joki - want to close this bug? Gerv

Yeah. I do. I think I'll go with WORKSFORME at this point, the bug being over a year old and mostly explained by the really horrible refreshes on linux at the time which have been improved a lot.

verified on build 2001-08-14-trunk