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)
Core
DOM: Navigation
Tracking
()
RESOLVED
WORKSFORME
mozilla0.9.1
People
(Reporter: bugzilla, Assigned: pollmann)
References
()
Details
(Keywords: regression, Whiteboard: [nsbeta1+])
Attachments
(1 file)
(deleted),
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.
Reporter | ||
Comment 1•24 years ago
|
||
Asa also sees.
Keywords: correctness,
nsbeta3
Summary: Remembering scroll position doesn't work → Remembering scroll position doesn't work
Comment 2•24 years ago
|
||
this seems specific to tables. will try to investigate more later
Reporter | ||
Comment 3•24 years ago
|
||
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
Comment 4•24 years ago
|
||
pollmann, I thought you fixed this long time ago. Can you take a look? Thanks.
Comment 5•24 years ago
|
||
I don't see this on any of the branch bits - leading me to believe this is a recently introduced regression on the trunk.
Reporter | ||
Comment 6•24 years ago
|
||
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
Assignee | ||
Comment 7•24 years ago
|
||
Anyone know when this started appearing? That would help trace it down...
Comment 8•24 years ago
|
||
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.
Assignee | ||
Comment 9•24 years ago
|
||
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?
Assignee | ||
Comment 10•24 years ago
|
||
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...
Assignee | ||
Comment 11•24 years ago
|
||
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?
Comment 12•24 years ago
|
||
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
Assignee | ||
Comment 13•24 years ago
|
||
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
Comment 14•24 years ago
|
||
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
Comment 15•24 years ago
|
||
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.
Comment 16•24 years ago
|
||
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
Comment 17•24 years ago
|
||
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?
Comment 18•24 years ago
|
||
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.)
Reporter | ||
Comment 19•24 years ago
|
||
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?
Comment 20•24 years ago
|
||
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.
Reporter | ||
Updated•24 years ago
|
Comment 21•24 years ago
|
||
*** Bug 47376 has been marked as a duplicate of this bug. ***
Comment 22•24 years ago
|
||
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.
Comment 23•24 years ago
|
||
Nevermind, I was using my M17 build.
...obvious regression.
Comment 24•24 years ago
|
||
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.
Comment 25•24 years ago
|
||
gabriel, this is not a problem in the M17/nsbeta2 branch.
Comment 26•24 years ago
|
||
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-]
Reporter | ||
Comment 27•24 years ago
|
||
however it happened, this is fixed in 80508 win98!
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 28•24 years ago
|
||
Wow, cool - I didn't touch a thing in that area though, so someone else is to be
congratulated. :)
Comment 29•24 years ago
|
||
*** Bug 48800 has been marked as a duplicate of this bug. ***
Comment 31•24 years ago
|
||
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.
Comment 32•24 years ago
|
||
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 → ---
Reporter | ||
Comment 33•24 years ago
|
||
rick/radha: do you know anything about this regression?
Comment 34•24 years ago
|
||
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.
Comment 35•24 years ago
|
||
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+]
Comment 36•24 years ago
|
||
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"
Comment 37•24 years ago
|
||
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?
Assignee | ||
Comment 38•24 years ago
|
||
Both scroll position and form values are restored correctly on this morning's
Windows build. Testing on Linux...
Status: REOPENED → ASSIGNED
Assignee | ||
Comment 39•24 years ago
|
||
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.
Reporter | ||
Comment 40•24 years ago
|
||
restoring scroll position doesn't work for me in windows tip build.
Assignee | ||
Comment 41•24 years ago
|
||
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
Assignee | ||
Comment 42•24 years ago
|
||
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?
Comment 43•24 years ago
|
||
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.
Comment 44•24 years ago
|
||
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.
Assignee | ||
Comment 45•24 years ago
|
||
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
Comment 46•24 years ago
|
||
*** Bug 52830 has been marked as a duplicate of this bug. ***
Updated•24 years ago
|
Keywords: relnote3
Summary: Scroll position in page not being remembered in SH → Scroll position in page not being remembered in session history
Comment 47•24 years ago
|
||
*** Bug 53892 has been marked as a duplicate of this bug. ***
Updated•24 years ago
|
Comment 48•24 years ago
|
||
clearing nsbeta3+ for triage by new owners. This clearly does not fit the
profile for nsbeta3, but we should consider for rtm. nominating, ->m19
Comment 49•24 years ago
|
||
nsbeta3-, rtm+, highly visible regression in one of the most commonly used
features.
Whiteboard: [nsbeta3-][rtm+]
Comment 50•24 years ago
|
||
*** Bug 54878 has been marked as a duplicate of this bug. ***
Comment 51•24 years ago
|
||
*** Bug 54900 has been marked as a duplicate of this bug. ***
Comment 52•24 years ago
|
||
PDT marking [rtm-] because we have bigger fish to fry at this point in the
Seamonkey cycle.
Whiteboard: [nsbeta3-][rtm+] → [nsbeta3-][rtm-]
Comment 53•24 years ago
|
||
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.
Reporter | ||
Comment 54•24 years ago
|
||
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-]
Comment 55•24 years ago
|
||
rtm need info: is there a simple/low-risk fix for this?
Whiteboard: [nsbeta3-] → [nsbeta3-][rtm need info]
Comment 56•24 years ago
|
||
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 ?
Comment 57•24 years ago
|
||
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
Comment 58•24 years ago
|
||
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.
Comment 59•24 years ago
|
||
*** Bug 55335 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 60•24 years ago
|
||
Eric V.: do you have any idea what the problem here is?
Comment 61•24 years ago
|
||
*** Bug 55476 has been marked as a duplicate of this bug. ***
Comment 62•24 years ago
|
||
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
Comment 63•24 years ago
|
||
Comment 64•24 years ago
|
||
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?
Comment 65•24 years ago
|
||
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"
Reporter | ||
Comment 66•24 years ago
|
||
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.
Comment 67•24 years ago
|
||
Evaughan: damn ! So I was right ! Do I get a prize ?
Comment 68•24 years ago
|
||
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?
Comment 69•24 years ago
|
||
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.
Assignee | ||
Comment 70•24 years ago
|
||
*** Bug 50776 has been marked as a duplicate of this bug. ***
Comment 71•24 years ago
|
||
Is this fix in the nightlies yet? I'm running 2000100904 on Win98se, but the
page position isn't being remembered.
Comment 72•24 years ago
|
||
Removing [needs info] and making RTM+ to get PDT approval for checkin.
Whiteboard: [nsbeta3-][rtm need info] → [nsbeta3-][rtm+]
Comment 73•24 years ago
|
||
r=pinkerton
Comment 74•24 years ago
|
||
a=hyatt
Comment 75•24 years ago
|
||
PDT marking [rtm-] because it's time to focus on P1 crash/data loss bugs.
Whiteboard: [nsbeta3-][rtm+] → [nsbeta3-][rtm-]
Comment 76•24 years ago
|
||
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+]
Comment 77•24 years ago
|
||
Is the patch in the trunk? It has r= and a=, so it should be.
/be
Assignee | ||
Comment 78•24 years ago
|
||
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
Reporter | ||
Comment 79•24 years ago
|
||
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.
Comment 80•24 years ago
|
||
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.
Comment 81•24 years ago
|
||
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.
Comment 82•24 years ago
|
||
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]
Comment 83•24 years ago
|
||
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?)
Comment 84•24 years ago
|
||
By all means, please check this into the branch!
Comment 85•24 years ago
|
||
Given John Morrison's comment, marking rtm++
Whiteboard: [nsbeta3-][rtm+ need info] → [nsbeta3-][rtm++]
Comment 86•24 years ago
|
||
Checked into the branch.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Comment 87•24 years ago
|
||
I am still getting broken behaviour in build ID: 20000101204 running on NT.
Comment 88•24 years ago
|
||
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.
Comment 89•24 years ago
|
||
er, that link should have been:
http://www.w3.org/TR/html4/struct/links.html
Comment 90•24 years ago
|
||
*** Bug 56251 has been marked as a duplicate of this bug. ***
Comment 91•24 years ago
|
||
Bug 56285 may be related to those problems.
Comment 92•24 years ago
|
||
Build 2000101220 fixed it for me...
Comment 93•24 years ago
|
||
VERIFIED Fixed on Branch and Trunk builds 2000101608.
Status: RESOLVED → VERIFIED
Reporter | ||
Comment 94•24 years ago
|
||
*** Bug 58249 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 95•24 years ago
|
||
It's broken again :\
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Reporter | ||
Comment 96•24 years ago
|
||
Sorry, should have clarified a bit more: works for back/fw, not for reload.
Comment 97•24 years ago
|
||
broken on Mozilla 0.6 (win / Linux)
Comment 98•24 years ago
|
||
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
Comment 99•24 years ago
|
||
*** Bug 62784 has been marked as a duplicate of this bug. ***
Comment 100•24 years ago
|
||
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
Comment 102•24 years ago
|
||
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.
Comment 103•24 years ago
|
||
a bugzilla buglist is a special case - bug 47350 as stated several times in this bug description and
now once more :-)
Comment 104•24 years ago
|
||
nav triage team:
Marking nsbeta1+
Whiteboard: [nsbeta3-][rtm++] → [nsbeta3-][rtm++][nsbeta+]
Comment 105•24 years ago
|
||
eric: any update on whether we can get this for mozilla 0.8 or 0.9? thanks, Vishy
Updated•24 years ago
|
Assignee | ||
Comment 106•24 years ago
|
||
0.9.1? I'll try for 0.9 though!
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.1
Comment 107•24 years ago
|
||
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
Comment 108•24 years ago
|
||
Backwards and forwards have been working for me with Linux builds for some time now.
Comment 109•24 years ago
|
||
*** Bug 76360 has been marked as a duplicate of this bug. ***
Comment 110•24 years ago
|
||
*** Bug 78157 has been marked as a duplicate of this bug. ***
Comment 111•24 years ago
|
||
WFM with recent Linux builds.
Comment 112•24 years ago
|
||
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.
Comment 113•24 years ago
|
||
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 → 24 years ago
Resolution: --- → WORKSFORME
Comment 114•24 years ago
|
||
I fixed some bugs last week, related to Reload. I think those patches helped fix
this one.
Comment 115•24 years ago
|
||
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.
Comment 116•24 years ago
|
||
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).
Comment 117•24 years ago
|
||
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...)
Comment 118•24 years ago
|
||
gabriel, please file a new bug with specific steps to reproduce your problem and
a specific page to test that. Thanks.
Comment 119•24 years ago
|
||
I have filed bug 83673 for the scroll position in tables problem.
Comment 121•23 years ago
|
||
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!
Comment 122•22 years ago
|
||
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 → ---
Comment 123•22 years ago
|
||
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: 24 years ago → 22 years ago
Resolution: --- → WORKSFORME
Comment 124•22 years ago
|
||
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.
Comment 125•22 years ago
|
||
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.
Description
•