Build ID: 2000072808 WinNT4 M18 Steps to Reproduce: (1) Go to the URL above (2) Scroll to about the middle of the page (3) Reload the page Result: you're back at the top (the scroll position isn't remembered). Also happens when navigating with back/fwd buttons.

Asa also sees.

this seems specific to tables. will try to investigate more later

I'm seeing this more and more lately across many pages. must be fixed for beta3. Claudius, could you test to ensure that this isn't in the beta2 branch?

pollmann, I thought you fixed this long time ago. Can you take a look? Thanks.

I don't see this on any of the branch bits - leading me to believe this is a recently introduced regression on the trunk.

I see this on every page now, even in a simple testcase I made with just a bunch of <br>'s. So doesn't seem to be related to tables, as Asa suggested. Claudius: odd that you don't see it in branch bits, Sarah said she saw it. (btw: what'd you change in the URL?)

Anyone know when this started appearing? That would help trace it down...

I noticed it in Bug Lists on the 28th trunk builds (but I assumed it was just for tables or something) then I noticed it with 8/01 trunk builds today on a number of non table pages.

Eric V, I see all of the code that saves and restores scroll position (GetStateType, SaveState, RestoreState) was removed from nsScrollPortFrame.cpp on 6/23. (rev 3.25 for Autoscrolling menus) Was this code moved elsewhere or removed completely?

Looks like it moved over to nsScrollBoxFrame. SaveState seems to work fine, and the RestoreState is called but does not actually update scroll position for whatever reason...

Well, RestoreState works too. However, after the restoreState calls ScrollTo on the nsScrollPortView, nsGfxScrollFrame gets a few AttributeChanged calls for "collapsed" "maxpos" and "pageincrement". Each one of these sets the scroll position to 0,0 - effectively undoing the work of the state restoration. These stray ScrollTo calls are made in nsGfxScrollFrameInner::AttributeChanged irregardless of what attribute is changed. Could the call to ScrollTo be restricted to the cases where scroll position is actually changed? Should the ScrollPortFrame be setting content attributes on the scrollbar (i.e. set the "curpos" attribute) rather than directly manipulating the view when restoring frame state?

Looks like this bug will be safe in pollman's or vaughan's hands. Right now giving to pollman who knows where this should really go.

Since this worked with nsScrollPortFrame but not the new nsScrollBoxFrame, I'm handing it over to the other Eric. I don't quite understand why the attributes are being changed or why that resets scroll position to (0,0). Let me know if I can help though!

pollmann: you may want to take this bug since evaughan is away until mid-August (vacation). I also note that there are actually two bugs here (one that may have : 1) in the branch builds (branch cut jul26?) and in a mozilla build of Jun29 the only page affected in this way (as far as I can see) is the bugzilla bug list (i.e., other pages -- a page with a long table, or a page with all BR will return the scroll position to the previous position on a reload). Here's a guess -- the bugzilla bug page delivered as 'Content-type: multipart/x-mixed-replace' In other words, a reload receives two consecutive HTML documents, the second of which is the actual bug list. How does that play into SH (did this ever get handled the right way?) 2) in more recent builds (on the trunk) *any* long page (as far as I can see) will not return to its previous scrolled position when reloaded. That is a recent development (i.e. last 6 days)

I reiterate that I don't see this on any of the branch builds: 2000073104 - RH Linux 6.1 2000073104 - MacOS 8.5.1 2000080104 - Win98 If i'm not nuts then this was introduced on the trunk after the branch was cut (7/27?) Blake, I didn't touch the URL field. I know bugzilla says I did but I didn't. I did a comparision and 'NEW' and 'OLD' are char for char exatcly the same.

Marking nsbeta3- This bug has been marked "future" because the original netscape engineer working on this is over-burdened. If you feel this is an error, that you or another known resource will be working on this bug,or if it blocks your work in some way -- please attach your concern to the bug for reconsideration.

This is happening on branch mozilla build 080204 when I have a long buglist in Bugzilla and select a bug on the list then hit the back button. This does not seem to happen at any other site I've tried on branch builds. This is happening all over the place on M18 builds. Did PDT review this bug for beta3?

I tried the mozilla binary builds since the branch, and the general[1] support for "returning to a previously scrolled page position when reloading a page" appears to have broken between 8am Jul 28 and 8am Jul 29. I think it is worth sorting out what broke a working feature (hopefully, it's a straightforward fix). ([1] I don't believe reloading a bugzilla bug list has ever worked (unless someone can point me to an old build where it did work). But 'bug_list.cgi' is a special case page ... multipart/x-mixed-replace is very rarely used in practice on the web. I will file a separate bug on that point, and expect to see that bug futured.)

I, too, would like to voice my opinion that this at least be looked into. Anyone who navigates bugzilla query list on a daily basis knows that this is near-dogfood (and some QA people have agreed). And surely the usability and functionality it provides is more important than the nsbeta3+/M18 bug 44227, no?

I opened a separate bug (bug 47350) for the bugzilla case (x-mixed-replace). That, as far as I know (and no one has offered evidence otherwise) has *never* saved scroll position on a reload. Claiming it is now dogfood is an insult to dogs. This bug is about the general case (i.e., normal HTTP/HTML pages), which worked until July 28.

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

Going back to Blake's original steps to reproduce, this worked fine for me. I went to the site, scrolled halfway, and hit reload. Result: back to the same spot. I am working on 080204 Win98. Will someone else please check this out? However, this is not the case when I reload or navigate back/fwd with something like a bug list.

Nevermind, I was using my M17 build. ...obvious regression.

This is really a new case of bug 16806. That bug was marked mostfreq, and had a large number of votes. This is also one thing that I predict a lot of reviewers will notice, if it's not in nsbeta2. It's also frequently mentioned as a reason people prefer IE to Netscape (that is, the fact that it remembers your position in a page when you go back to it). I really think somebody in the Mozilla team should look into this. It is a very, very important usablity feature.

gabriel, this is not a problem in the M17/nsbeta2 branch.

clearing nsbeta3- designation. This is a VERY recent regression(post-branch) and the original incarnation of this bug (bug 16806) is nsbeta2+ and mostfreq. Although I don't agree in the bugzilla case (bug 47350) some people are arguing dogfood for this bug and I almost agree. Someone broke this in M18 and should have to fix it in M18. please reconsider.

however it happened, this is fixed in 80508 win98!

Wow, cool - I didn't touch a thing in that area though, so someone else is to be congratulated. :)

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

VERIFIED Fixed with 2000090608 builds

It's still happening for me on the 2000090704 winNT build, on some pages. For example, the bugzilla bug list page reloads at the top, but on slashdot, it's OK.

This has regressed. It was fine yesterday and is broken today. tested on win, mac and linux 09/20 builds.

rick/radha: do you know anything about this regression?

I have no clue what is going on. I'm still running a 9/18 pull which works though :-) I would suggest that since this regression keeps appearing and no one knows why. We should at least track it down and understand the cause before PDT declares the broken behavior a new feature of 6.0.

It is almost completely broken in 9/21 build. It almost never remembers the scroll position. Marking nsbeta3+. P2. Highly visible, often used functionality is broken.

I can't help but thinking that Adam's checkin ~6am 09/20 for bug 50949 is a factor -- "nsIWebNavigation::LoadURI() needs to support session history bypass"

Adam, could this possibly be related to your checkins? I highly doubt it. Scroll bar psition is restored along with form values. If scroll bar is broken, we wouldn't be restoring form values too upon back or forward. Is form value restoreation working?

Both scroll position and form values are restored correctly on this morning's Windows build. Testing on Linux...

Linux tip build: Form values are restored but scrolling is not. I think this was also the case with last night's Mac build. I'll try to trace down where scroll position restoration is failing in the Linux build, but this will have to wait until after my other P1 bug is fixed.

restoring scroll position doesn't work for me in windows tip build.

The build I tried on Windows was an optimized commercial build from 4PM today - I suspect this bug may be timing related. See related bug 53501

On Linux, I'm seeing the same problem that Mike and I saw last night on Mac. Namely, the scroll postition is stored correctly in nsScrollBoxFrame::StoreState, and an attempt is made to restore the correct value in nsScrollBoxFrame::RestoreState. However, this method calls nsScrollPortView::ScrollTo, and this routine refuses to update the scroll position. The reason is exactly the same on Mac an Linux (possibly Windows too, haven't checked): scrolledView->GetDimensions(&scrolledSize.width, &scrolledSize.height); This returns scrolledSize.height to be the height of the entire document nsSize portSize; GetDimensions(&portSize.width, &portSize.height); This returns portSize.height to be the height of the entire document. ***** I'm fairly certain this is where the bug is. ***** nscoord maxX = scrolledSize.width - portSize.width; nscoord maxY = scrolledSize.height - portSize.height; This returns maxY of 0 (meaning we can't scroll) if (aX > maxX) aX = maxX; if (aY > maxY) aY = maxY; This sets aY to 0 (meaning we won't scroll) Did anything change with nsScrollPortView recently that might have broken this?

Not sure if this is related, but if you click on the scrollbar, event.target.localName == "HTML" (bug 53537); in other words, it thinks it's the whole document, from a DOM point of view.

Never mind. That other bug was just that it had not been switched over from using event.target to event.originalTarget when dealing with anon. content.

Ack, I'm confused after staring at this for too long. Handing this to Eric to look at why the scroll frame is acting funny - Can you take a look at my previous comment and maybe explain what's going on? Reassigning because as far as I can tell this is a regression in nsScrollPortView (most likely I'm wrong though, so feel free to give it back...)

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

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

clearing nsbeta3+ for triage by new owners. This clearly does not fit the profile for nsbeta3, but we should consider for rtm. nominating, ->m19

nsbeta3-, rtm+, highly visible regression in one of the most commonly used features.

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

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

PDT marking [rtm-] because we have bigger fish to fry at this point in the Seamonkey cycle.

Removing rtm- for reconsideration. Since this bug regressed ~10 days ago, it has been reported four more times. In its earlier life as bug 16806, there were 27 duplicate bug reports. By evidence, this is a highly visible feature which was working fine until 9/20.

removing rtm- as was presumably intended. Eric, can you give us an evaluation/risk of the possible fix? (have you looked into this yet?)

rtm need info: is there a simple/low-risk fix for this?

I noticed something which may be relevant to this bug. I was looking at the latest Mozilla status report, and this is what happened: open status report click on link to bug go back to status report part of status report is shown mozilla scrolls down a little rest of status report is loaded so maybe the scroll position is being restored too soon ? Could it be something to do with asynchronous reflow ?

It also seems that pages with a link names are being ignored. For instance, try going to the following link: http://www.maubi.net/mozilla/journals/2000-09.html#29 Expected: page should load, and once fully loaded, go directly down to where: <a name="29">some text</a> is Actual: no such behavior. The page loads and ignores the #29 directive Is this related to this bug? It seems like it to me. I also agree that this is a high visibility bug and absolutely needs to be fixed. Try browsing any of the W3C specs and go back and forth between pages. You lose your place so easily if the browser doesn't remember where you were on the previous page. Since IE does this, people are going to discard any browser that doesn't perform this useful function for the user. Jake

I just wrote bug 55244 about the anchors issue. Although the scenario hoju@visi.com describes is slightly different that the generic case I wrote the bug for I still believe it to be the same unrelated issue. Especially since that bug showed up after this one.

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

Eric V.: do you have any idea what the problem here is?

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

Ok I know why this happens now. It was broken by incremental loading of the page. When we resore state and it says we should go to y position 1800. The page hasn't even loaded yet. It hasn't overflowed off the window yet to be able to scroll at all. So when you call scrollto on the ScrollingView. it does nothing because 1800 is greater that its max scroll position which is 0. This might have worked at one time before incremental layout of pages was really turned on. The way to fix this is to store the position and keep adjusting as the page comes in. I'll see if I can't come up with a good fix.

Ok this fix works pretty well but I did noticed that if I went to my bug list and scrolled down it didn't hold the state. I put a break point in restore state and it is never called. Is something broken in the state restore system as well?

The buglist page is a different beast, and has never been known to work. It uses multipart/x-mixed-replace (i.e., it's two documents in one stream). So, don't worry about that case -- it's bug 47350 "Current scroll position not retained, reloading multipart/x-mixed-replace"

Eric: nope, that's not your fix's fault; it's a separate problem when a page has a content type of multipart/x-mixed-replace. See John's 8/2 comment: "I opened a separate bug (bug 47350) for the bugzilla case (x-mixed-replace). That, as far as I know (and no one has offered evidence otherwise) has *never* saved scroll position on a reload. Claiming it is now dogfood is an insult to dogs." So 47350 is covering that [less important] issue.

Evaughan: damn ! So I was right ! Do I get a prize ?

In bug 55476, someone noticed that on windows, if you minimise mozilla and maximise it back, it loses the place in the page as well. Is this related to this bug or something new?

I've been running with this fix for about a day now on Linux, and it seems to be working fine, although it does indeed lose position on Bugzilla bug lists.

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

Is this fix in the nightlies yet? I'm running 2000100904 on Win98se, but the page position isn't being remembered.

Removing [needs info] and making RTM+ to get PDT approval for checkin.

r=pinkerton

a=hyatt

PDT marking [rtm-] because it's time to focus on P1 crash/data loss bugs.

this is a mostfreq, and a very visible UI problem with our product. we have a fix and we know it's ramifications. requesting re-triage.

Is the patch in the trunk? It has r= and a=, so it should be. /be

Based on the fact that we have 9 duplicates of this bug, just days after nsbeta3 was released, and it is a regression from nsbeta2, I think it is more severe than it may initially appear. The original bug, bug 16806 had 25 dups and 12 votes, for a total of 34 dups and 26 votes. This is a very important usability issue on long documents. After a few incidents of reading far into a long document, then clicking a link, then going back only to find I've lost my place and have to scroll through the entire document to find it again, I might just be tempted to can the browser from my machine. Some quotes from users who noticed this bug: "It happens on all long pages that I have recently used (bugzilla search results, slashdot, freshmeat, W3C HTML spec, and many others). This is a very annoying bug from a usability standpoint." "I, too, would like to voice my opinion that this at least be looked into. Anyone who navigates bugzilla query list on a daily basis knows that this is near-dogfood (and some QA people have agreed). And surely the usability and functionality it provides is more important than the nsbeta3+/M18 bug 44227, no? " "This is a real annoying buy when following threads say in <a href=http: //slashdot.org> http://slashdot.org</a> . You follow a link and come back, your position is screwed!" "I suggest either reopening 16806 and making this a dupe, or adding regression keyword and changing severity to major since 16806 had 12 votes, and was marked mostfreq." "This is bad." "Using the back button refreshes to the top of the page, rather than restoring to the scrolled place where i was at when i went to the next page. not really a bug, i guess -- but darn annoying." "This has now regressed and been reborn as bug 46877. I suggest we use our voting power to try and get this fixed again."

OK, I checked this into the trunk per Brendan's request (thanks for the reminder). I'd also like to voice my support that this be fixed. I've been running with the patch for days with no problem. This would have gotten in if PDT had gotten around to it a day earlier than they had, so it seems silly to minus it arbitrarily because an extra couple of hours have passed.

Thanks for getting this into the trunk. Now for the branch.... Can we get permission? This is a real show stopper if we RTM without it.

Come on, this is core functionality, present in every browser release we've ever shipped. This doesn't manifest itself to naiive users as described, all they see is that the Back button is broken, and won't take them back where they were, and a lot of links don't work either. Let's at least make the top 2-3 features work correctly.

Allowing this to cook for a day on the trunk. Please update bug tomorrow with any regression information. Marking need info

Okay, so this is working very well in the trunk builds for this evening on win2k linux and mac. Visiting a variety of pages (by HTML complexity, by length, with/without frames), scroll position is restored when reloading/back/forward among the pages. No regressions in scrolling behaviour were observed. If someone can have a whack at this in the morning, with no problems noted, then I think we are good to go on the branch. Thanks to Eric^2 (pollmann and vaughan) for fixing this! (Side note [which does not block landing on branch in any way]: this does not work for XML content, but that is outside the scope of this bug -- however, do we have an active bug for this issue? Second side note: directly reloading a single HTML frame via a context menu does not restore scroll position -- is here an active bug for that issue?)

By all means, please check this into the branch!

Given John Morrison's comment, marking rtm++

Checked into the branch.

I am still getting broken behaviour in build ID: 20000101204 running on NT.

hmm, on build 2000101208, Linux, I am seeing the following: 1) scroll down a page. 2) click on a link to an internal anchor within the same page 3) hit the "Back" button 4) mozilla goes to the top of the page instead of the last place I was on the page I've been testing this on http://www.w3.org/TR/html4/about.html; it has plenty of internal links.

er, that link should have been: http://www.w3.org/TR/html4/struct/links.html

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

Bug 56285 may be related to those problems.

Build 2000101220 fixed it for me...

VERIFIED Fixed on Branch and Trunk builds 2000101608.

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

It's broken again :\

Sorry, should have clarified a bit more: works for back/fw, not for reload.

broken on Mozilla 0.6 (win / Linux)

nsScrollBoxFrame::RestoreState is never called on a reload but it is for back and forward. Reassigning to Eric P.

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

nav triage team: yes this is a netscape beta stopper.

mozilla0.9 as well

A (late) response to Blake Ross' comments "Sorry, should have clarified a bit more: works for back/fw, not for reload." It does not work all the time for back eg : with a bugzilla bug list, open today's bug list scroll down, go to another url and click back -> top of the page.

a bugzilla buglist is a special case - bug 47350 as stated several times in this bug description and now once more :-)

nav triage team: Marking nsbeta1+

eric: any update on whether we can get this for mozilla 0.8 or 0.9? thanks, Vishy

0.9.1? I'll try for 0.9 though!

Does this bug cover Back/Forward as well? The title says no, but some comments say Yes. Anyway, saving scroll position for that is currently not working either :-( Gerv

Backwards and forwards have been working for me with Linux builds for some time now.

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

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

WFM with recent Linux builds.

Please also try to see if you can reproduce bug 78157 It's been set as duplicate of this bug, but I'm not 100% sure it is.

I am marking this as WFM. !!! :-) Eric did you fix this? _______________ Henrik, I am not sure that your bug is a dupe (this bug 46877 "to me" is with reloading current pages by hitting refresh button and mozilla going back to the top of the page instead of putting the viewport where you were before the reload). If you can create a simple testcase that reproduces your bug than reopen your bug. Not all dupes are marked correctly. Yours may be one of them.

I fixed some bugs last week, related to Reload. I think those patches helped fix this one.

Might work for some, but I'm still seeing this on Windows build 2001053020: On this page for example: http://java.sun.com/j2se/1.3/docs/api/java/lang/Object.html Scroll down to "Method Summary", click on a method name, then click the back button. Takes me to the top of the page all the time. Reloading the page after scrolling to "Method Summary" _rarely_ moves it to the top as well. Many other sites do work fine, but where it appears this bug is very annoying.

I think this is a problem particular to tables, because if you click on a link outside of a table it works (for me anyway).

That might very well be, but the bug is staying WORKSFORME, because some people happen to use only web pages without tables ? (Boy, that's a whole lot of pages, these days...)

gabriel, please file a new bug with specific steps to reproduce your problem and a specific page to test that. Thanks.

I have filed bug 83673 for the scroll position in tables problem.

VERIFIED WFM (modulo other bugs)

I am finding this behavior again. I'll explain how to reproduce it with build: First go to the page: http://www.cleanpornhost.com/users/bothasia/watermelons/watermelons.html (warning: this is a porn site but it's the only site offhand I can remember that does this although others do it also from time to time.) now scroll into the middle or so of the page, view a picture and press back. The scroll bar will return to the top instead of where you were left browsing the thumbnails. This is detrimental to my pr0n viewing and is very important to fix ;-) But seriously, if some pages do this with Mozilla and pages don't do this with IE or Opera, people aren't going to use Mozilla. Oh as a note: Sometimes it seems to work and sometimes not... so if it worked for you, try doing it with a few different pictures and see if you can reproduce the behavior. Someone please verify this, or tell me I'm an idiot and "if you do this" or "if you use the latest nightly" this will be fixed. Or "Bug number blah blah is better suited for this because blah blah" I just don't want to see this behavior in the 1.0 release!

Reopening. I can verify that back always returns to the top of the page on the trunk build 2002062608 under Windows XP using the "clean" and more appropriate site http://www.ntcompatible.com/ To duplicate: 1. Scroll down the page far enough that it's obvious you're no longer at the top. 2. Click on "Read more." 3. Click the back button. 4. You will now be back at the top of the page, rather than in the previous vertical position. Note: Under IE what happens is that when you click on "Read more," it opens another window. In Mozilla it opens in the same window. However, this should not have any affect on Mozilla's scroll history and hitting back should still correctly position you to your previous vertical position. (Especially since you ARE browsing within the same window and did not click on a hyperlink to get back.)

Okay, yes, if you have set 'browser.block.target_new_window' to true, then the behaviour is as you describe. But, really, that's best handled as a new and separate bug. So please file at as a new one, noting the role of that pref, and let's leave the baggage of this bug behind. Thanks.

Um, actually, this isn't dependent on that pref, since if I click on a link that still points to ntcompatible.com (and I have the block pref set to false) when I go back to the home page, I am scrolled to the top of the page. However, the reason is that the home page is served with: Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 When the page is requested not to be cached, then we don't. bug 105395.

Opened bug 154969 due to comment 123. However, by the time I finished writing up the bug report, comment 124 came in which will probably result in it being immediately closed as WONTFIX. Just one of those days. <grin>