Closed
Bug 60584
Opened 24 years ago
Closed 24 years ago
Page keeps jumping to the bottom.
Categories
(Core :: Layout, defect, P2)
Tracking
()
VERIFIED
FIXED
mozilla0.9.1
People
(Reporter: gabriel, Assigned: dr)
References
Details
Attachments
(4 files)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review |
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.
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.
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?
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.
I can still reproduce this under linux build 2000120808. FYI I'm on a 56K dialup.
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)?
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
Keywords: mozilla0.8
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.
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");
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.
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)
Updated•24 years ago
|
Keywords: mozilla0.8.1
Updated•24 years ago
|
Keywords: mozilla0.8
Comment 18•24 years ago
|
||
Updated•24 years ago
|
Whiteboard: needs review
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>
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 ?
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???
Comment 23•24 years ago
|
||
->dr/p2 to take patch (this one is driving us all nuts!)
Assignee: evaughan → dr
Status: ASSIGNED → NEW
Priority: P3 → P2
Assignee | ||
Comment 25•24 years ago
|
||
Assignee | ||
Comment 26•24 years ago
|
||
Assignee | ||
Comment 28•24 years ago
|
||
Assignee | ||
Comment 29•24 years ago
|
||
fixed
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•