gabriel Reporter
	Description • 24 years ago

Linux build 2000111708.

To reproduce:
go to a longish page with links (e.g http://freshmeat.net).

Click on a link near the bottom, and let the new page load.

Click back and before the original page has loaded completely, hold down page up.

Results:
The page loads fully and then 'jumps' to the bottom. After this the page keeps
jumping to the bottom every few secconds, no matter how much you try to scroll up.

I think this may have something to do with the fix for bug 46877, so it should
probably be assigned to evaughan. Looks as if a timer is not being cleared
somewhere.

	Toby Haynes
	Comment 1 • 24 years ago

I've seen this behaviour on Windows NT  - build 2000111220. Go to slashdot.org,
scroll down the page and select a link on the right. Visit that page and then
come back to Slashdot. More often than not, Mozilla will keep jumping back to
the previous scroll position, regardless of what you do to persuade it
otherwise. This jumping back occurs within a few seconds of moving the page away
from this position, with keys or scrollbars.

	Eric Vaughan
	Comment 2 • 24 years ago

I just followed these instructions and cannot reproduce. Are you on a slow
modem. Is there something different about you setup?

	Toby Haynes
	Comment 3 • 24 years ago

I can continue to reproduce this bug on NT 2000112720. My brief daliance with
2000121008 couldn't reproduce the problem, but the broken psm handling on that
build is a blocker for me so I'm still back on the 1127 build.

	Eric Vaughan
	Comment 4 • 24 years ago

targeting

	gabriel Reporter
	Comment 5 • 24 years ago

I can still reproduce this under linux build 2000120808. FYI I'm on a 56K
dialup.

	djk
	Comment 6 • 24 years ago

I still see this on Win98se with build 2001011604.
I'm on a T1.

	Toby Haynes
	Comment 7 • 24 years ago

I'm still seeing this behaviour on the 2001011620 Win32 Build. However I have
noticed that hitting escape normally gets the jumping to stop, which makes me
think that the problem may revolve around the page, for whatever reason,
continue to think that it has more to load and render. Surely the code to jump
the correct place on the page should only be called once, when the page is close
to finishing rendering (i.e. all text loaded, all image sizes determined)? 

	Jason Eager
	Comment 8 • 24 years ago

I keep getting hit with this as well.

Nominating for Mozilla 0.8 since it is already targetted for mozilla 0.8

	timeless
	Comment 9 • 24 years ago

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

	djk
	Comment 10 • 24 years ago

Note that bug 66652 has been determined not to be a dup of this bug.

However, I think bug 66309 is a dup.  The description of that bug is interesting
because it leads me to believe that the page jumping has something to do with
animated gifs.

	Toby Haynes
	Comment 11 • 24 years ago

Animated GIFs? Now that is interesting. I have added the necessary line to my
prefs.js file to make animated GIFs play once only, and the bouncing back stops
after a while. 

For the interested, 

user_pref("image.animation_mode", "once");

	gabriel Reporter
	Comment 12 • 24 years ago

That is possible, freshmeat has banner ads. There is also a bug out there about
animated gifs hitting the network for ever, which would possibly explain this
behaviour since the page might never receive notification of being fully loaded.

	Peter Trudelle
	Comment 13 • 24 years ago

->moz0.9

	Jens Lautenbacher
	Comment 14 • 24 years ago

As far as I see, this really is triggered by animated gifs. maybe there's still
something else there, but all occurences I can remember of this bug lately were
on pages with animated gifs. (this is on linux, 2001021121)

	Asa Dotzler [:asa]
	Comment 15 • 24 years ago

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

	Peter Trudelle
	Comment 16 • 24 years ago

->moz0.9.1

	Eric Vaughan
	Comment 17 • 24 years ago

Ok I have fix attach enclosed:

	timeless
	Comment 19 • 24 years ago

would you consider using /**/ for your long multiline comments?
484,488c488,527 this block doesn't line up w/ itself
>             if (y > cy || x > cx) {
>            } else {// if we reached the position then stop
>             }
>           } else {

<tangent>
>             if (NS_SUCCEEDED(scrollingView->GetScrolledView(child)) && child) 
I don't like that succeeded isn't enough of an assurance, but lxr shows it 
isn't... </tangent>

	gabriel Reporter
	Comment 20 • 24 years ago

Just a minor nitpick:

// so this with fix any round off problems.

should be:

// so this will fix any round off problems.

surely ?

	djk
	Comment 21 • 24 years ago

This bug has been untouched for 3 weeks...and it drives me up a wall. :-)

I don't want to sound ungrateful for all the work everyone does, but could
someone clean up the patch, get an r/sr, and check this in please?  Pretty please???

	Marek Z. Jeziorek
	Comment 22 • 24 years ago

is there a chance/need that this could be checked into 0.9.1?

	Peter Trudelle
	Comment 23 • 24 years ago

->dr/p2 to take patch (this one is driving us all nuts!)

	Dan Rosen Assignee
	Comment 24 • 24 years ago

ja.

	Eric Vaughan
	Comment 27 • 24 years ago

-r=evaughan

	Dan Rosen Assignee
	Comment 29 • 24 years ago

fixed

	gabriel Reporter
	Comment 30 • 24 years ago

Thanyou :-)

	Chris Petersen
	Comment 31 • 24 years ago

Marking verified in the May 25 build.