Closed Bug 46877 Opened 24 years ago Closed 22 years ago

Scroll position in page not being remembered in Reload

Categories

(Core :: DOM: Navigation, defect, P2)

Product:
Core
Component:
DOM: Navigation
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME
Milestone:
mozilla0.9.1

People

(Reporter: bugzilla, Assigned: pollmann)

References

(
URL
)

Details

(Keywords: regression, Whiteboard: [nsbeta1+])

Attachments

(1 file)

Fix
3.48 KB, patch
Details | Diff | Splinter Review 
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.
Keywords: correctness, nsbeta3
Summary: Remembering scroll position doesn't work → Remembering scroll position doesn't work
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?
Severity: normal → major
Keywords: regression
OS: Windows NT → All
Hardware: PC → All
Summary: Remembering scroll position doesn't work → Scroll position in page not being remembered in SH
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?)
Keywords: relnote2
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.
Assignee: radha → pollmann
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!
Assignee: pollmann → evaughan
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)
Assignee: evaughan → pollmann
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.
Whiteboard: [nsbeta3-]
Target Milestone: --- → Future
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.
Whiteboard: [nsbeta3-]
however it happened, this is fixed in 80508 win98!
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
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
Status: RESOLVED → VERIFIED
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.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
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.
Priority: P3 → P2
Whiteboard: [nsbeta3+]
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...
Status: REOPENED → ASSIGNED
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...)
Assignee: pollmann → evaughan
Status: ASSIGNED → NEW
*** Bug 52830 has been marked as a duplicate of this bug. ***
Keywords: relnote3
Summary: Scroll position in page not being remembered in SH → Scroll position in page not being remembered in session history
*** Bug 53892 has been marked as a duplicate of this bug. ***
Keywords: rtm
Whiteboard: [nsbeta3+]
Target Milestone: Future → M19
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.
Whiteboard: [nsbeta3-][rtm+]
*** 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.
Whiteboard: [nsbeta3-][rtm+] → [nsbeta3-][rtm-]
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.
Keywords: mostfreq
removing rtm- as was presumably intended.

Eric, can you give us an evaluation/risk of the possible fix? (have you looked 
into this yet?)
Whiteboard: [nsbeta3-][rtm-] → [nsbeta3-]
rtm need info: is there a simple/low-risk fix for this?
Whiteboard: [nsbeta3-] → [nsbeta3-][rtm need info]
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.
Status: NEW → ASSIGNED
Attached patch Fix — — Splinter Review 

    
    

    
  
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.
Whiteboard: [nsbeta3-][rtm need info] → [nsbeta3-][rtm+]

    
    

    
  
a=hyatt


    
    

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

Whiteboard: [nsbeta3-][rtm+] → [nsbeta3-][rtm-]

    
    

    
  
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.

Priority: P2 → P1
Whiteboard: [nsbeta3-][rtm-] → [nsbeta3-][rtm+]

    
    

    
  
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."

Priority: P1 → P2

    
    

    
  
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

Whiteboard: [nsbeta3-][rtm+] → [nsbeta3-][rtm+ 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++

Whiteboard: [nsbeta3-][rtm+ need info] → [nsbeta3-][rtm++]

    
  
Blocks: 56156

    
    

    
  
Checked into the branch.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED

    
    

    
  
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.

    
    

    
  
*** 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.

Status: RESOLVED → VERIFIED

    
    

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

    
    

    
  
It's broken again :\
Status: VERIFIED → REOPENED
Resolution: FIXED → ---

    
    

    
  
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.
Assignee: evaughan → pollmann
Status: REOPENED → NEW

    
    

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

    
    

    
  
nav triage team: yes this is a netscape beta stopper. 
Keywords: nsbeta1
Summary: Scroll position in page not being remembered in session history → Scroll position in page not being remembered in Reload

    
    

    
  
mozilla0.9 as well
Keywords: mozilla0.9

    
    

    
  
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+
Whiteboard: [nsbeta3-][rtm++] → [nsbeta3-][rtm++][nsbeta+]

    
    

    
  
eric: any update on whether we can get this for mozilla 0.8 or 0.9? thanks, Vishy
Keywords: nsbeta3, 
          
            relnote2, 
          
            relnote3, 
          
            rtm
Whiteboard: [nsbeta3-][rtm++][nsbeta+] → [nsbeta1+]

    
    

    
  
0.9.1?  I'll try for 0.9 though!
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.1

    
    

    
  
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. 
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → WORKSFORME

    
    

    
  
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)
Status: RESOLVED → VERIFIED

    
    

    
  
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.)
Status: VERIFIED → REOPENED
Resolution: WORKSFORME → ---

    
    

    
  
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.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 22 years ago
Resolution: --- → WORKSFORME

    
    

    
  
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>

    
  
Component: History: Session → Document Navigation
QA Contact: claudius → docshell

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: