Closed Bug 16806 Opened 25 years ago Closed 24 years ago

Save scroll position in session history

Categories

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

Product:
Core
Component:
DOM: Navigation
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: pollmann, Assigned: pollmann)

References

(Blocks 1 open bug)

Details

(Whiteboard: [nsbeta2+][Will be minus on 6/15] fix in hand) 

Need to implement nsIStatefulFrame for the scroll frame.
Status: NEW → ASSIGNED
Will just implementing nsIStatefulFrame provide adequate results for named
anchors?  That is, if you move from one named anchor to another, and back, will
you go to the remembered position?  (Or was this bug about scroll position in
textareas and iframes, etc.?)


See my comments on bug 16379 and bug 3891.
*** Bug 3891 has been marked as a duplicate of this bug. ***
*** Bug 16379 has been marked as a duplicate of this bug. ***
The way I'm attacking it now is to store scroll position for each
nsScrollPortFrame.  I don't see how moving to named anchors will be any
different than just preserving the session history - when a link is clicked, you
are going to a different URL, even if that happens to be a named anchor on the
same page.  This should work now, no?

There is one known problem if I store the scroll position by pixel offset, as I
am currently implementing.  If the width of the window is resized, the position
in the document may be different, due to a reflow.  I don't see an easy fix for
this yet.
Played around with the resizing issue in a few browsers, and based on
what I saw, there may not be an easy fix for the resizing known issue
at all, based on pixel offsets. The best you could do would be to apply
two different factors based on height and width change. Two factors would be
needed because changes in height have a much greater effect than changes
in width. Also, this would have to based on canvas size, not window size.
The sidebar also complicates things. To do this, it would probably be
necessary to save the canvas size for each entry in the session history.

If the canvas size were saved, a simple workaround (albeit one that may strike
many people as weird) would be to resize the browser as the session history
is moved through, so that the canvas size is the same that it was when each
page was last viewed. The pixel offsets would be correct then for sure!
But this is probably too weird.

There is another workaround for this issue: store the page position based on
an integer pixel offest from the top of the topmost DOM node on the page
(integer because it could be off the top of the page). I'm guessing this
would be harder, but who knows? Note that the scroll position would still
need to be stored as a pixel offset as a backup, in case the page in the
session history has changed and that node on the DOM tree no longer exists!
How is the offset remembered for when we do reflows? When we change to an
alternate stylesheet, the entire window is redrawn but the position is not
reset to the top -- is the way that is done even remotely portable to the
session history?
I think it's remembered as a pixel offset from the top - that's how it looks,
anyway.

There's existing (but somewhat buggy) code (for event handling) to get the frame
at a given point, and existing code to scroll to a given frame.  The problem
with a better solution is knowing what point will give the correct frame (or
probably finding the frame some other way).
We could:
1) Get the current scroll offset
2) Get the frame at those coordinates (top left corner of view)
3) Find coordinates of that frame.
4) Store 2 and 1 minus 3 (offset into that frame) as the scroll state

When restoring we set the scroll offset to the coordinates of frame 2 (which may
be different due to a resize) plus the offset into that frame.

Another possibility would be to get the frame in the center of the view, and
scroll that into the center of the view when restoring.

These seems more user friendly than pixel offsets, but also could require a lot
of computation.  This logic would be used for every scrollbar visible on the web
page when it was left, including the scrollbars for listboxes and textareas.

For a first pass, I'm going to just store pixel offsets. Once that is working,
I'll look at optimizing the offset logic - perhaps to what I just mentioned, or
a rough approximation that requires less computation.
The problem with what you suggest is that you can easily hit a gap between
frames and end up with the BODY frame when you ask for the frame at a given
point.  Furthermore, you don't want to be messed up by floaters or fixed
positioned elements or other such things.
Thanks.  Yes, there are several issues now that I think about that - especially
the first suggestion I wrote is flawed - what if it got an inline frame that was
at the beginning of a line but then reflowed to the far right side of the line.
The user would be viewing a big blank document.  More thinking required on this.

Is pixel offsets is acceptable to everyone as a first pass?  :)
It's certainly better than nothing! :-)
Blocks: 19261
*** Bug 18658 has been marked as a duplicate of this bug. ***
*** Bug 19548 has been marked as a duplicate of this bug. ***
*** Bug 21739 has been marked as a duplicate of this bug. ***
Target Milestone: M14
Marking this feature for M14.
*** Bug 23079 has been marked as a duplicate of this bug. ***
Blocks: 24206
*** Bug 25304 has been marked as a duplicate of this bug. ***
*** Bug 26122 has been marked as a duplicate of this bug. ***
Keywords: beta1
Can we live without this for beta1?
Whiteboard: [PDT-]
Do you want beta1 to impress people?
*** Bug 27372 has been marked as a duplicate of this bug. ***
I honestly could deal without this for beta1, but it definitely should not slip 
beta2.

Moving non PDT+ bugs out.
Target Milestone: M14 → M15
*** Bug 24852 has been marked as a duplicate of this bug. ***
*** Bug 29967 has been marked as a duplicate of this bug. ***
*** Bug 30263 has been marked as a duplicate of this bug. ***
Updating QA contact.
Component: Browser-General → History
QA Contact: leger → claudius
*** Bug 30111 has been marked as a duplicate of this bug. ***
*** Bug 33704 has been marked as a duplicate of this bug. ***
ftp/file expantion state also needs saving, might be common code: see bug 33703
*** Bug 33965 has been marked as a duplicate of this bug. ***
*** Bug 34141 has been marked as a duplicate of this bug. ***
*** Bug 34523 has been marked as a duplicate of this bug. ***
Moving out to M17.
Target Milestone: M15 → M17
I really missed seeing this in PR1. I surely hope it doesn't get bumped 
indefinitely. At HotBot.com we gets lots of user feedback about this and 
only can tell them to use IE5 if this feature is important to them.
Rescheduling
Target Milestone: M17 → M16
*** Bug 35729 has been marked as a duplicate of this bug. ***
What about storing a certain amount of the source file at the position in the
history.  Then when the going back, search for the stored text in the source and
set the scroll position accordingly?  The hard part would be writing the code to
translate a linenumber in the source to a pixel coridinate for the scroll frame.

That doesn't explain which position in the document to use.  I was thinking a
bit about an algorithm for this, and I wrote down some notes somewhere.  (If
you're interested, I can try and find the notes.)  But the basic idea was this:
 * pick n points (say n=10) across the top of the scrolling view (or maybe a
hair below the top), kinda like this:
   *       *       *       *       *       *       *       *       *       *
and then find the frame that is the closest common ancestor of at least a*n of
them (say, a=0.5), and store the position in twips relative to that frame (or,
really, the a way of finding the content node for that frame).
 * have special cases for being at the top or the bottom (and of course hitting
it)
 * I know I have some other things to say here...

This algorithm could also be used during a resize-reflow.  It would be good to
use the original remembered position for a series of resizes - that is, on a
drag-resize (or even a series thereof), one would want to use the original
remembered position throughout, rather than continually recalculate.  This could
be done by clearing the remembered position when the view is scrolled.

One might also need to make special exceptions for when scrolling views were
within scrolling views (e.g., IFRAME), since the reference frame (probably)
shouldn't be within another scrolling view (or perhaps it's not a problem?).
*** Bug 36070 has been marked as a duplicate of this bug. ***
*** Bug 36477 has been marked as a duplicate of this bug. ***
*** Bug 36543 has been marked as a duplicate of this bug. ***
Removing 'beta1' keyword since beta 1 is long gone.
Keywords: beta1
Oops, I noticed there's a 'nsbeta2' keyword as well.  Putting that in.
Keywords: nsbeta2
*** Bug 37390 has been marked as a duplicate of this bug. ***
Depends on: 35566
Clearing Status Whiteboard since `beta1' has been replaced by `nsbeta2'.
I really hope that [PDT-] was left over from `beta1'...
Whiteboard: [PDT-]
*** Bug 38452 has been marked as a duplicate of this bug. ***
From a usability point of view, I think it's most obvious if the top of the 
content frame is kept constant, rather than the middle. Therefore, I suggest ...

* As soon as the frame either {starts to go to a new location} or {is resized,
  whether because of window resizing, sidebar opening, or whatever}, define an
  anchor point for the original layout at (0 + left margin of BODY in pixels,
  0 + top margin of BODY in pixels).

* Find the object boundary in the same layout frame which is nearest to the
  anchor point in the northwest direction. `Object boundary' here could be the
  border between two words, or between two images, or a plugin and a word, or
  whatever.

* Record both the identity of the object boundary (however you like -- the number
  of the relevant character in the source code might work, unless of course
  you're viewing an image) and the x and y offsets from that object boundary to
  the anchor point. So for example, I might end up with an anchor point that was
  `3 pixels south and 5 pixels east of the boundary between the 785th and 786th
  elements in the page'.

* Whenever that location is returned to, or the window is resized, position the
  layout so that, in order of priority:
  - the vertical position of the anchor point is exactly the same as it was
    originally
  - the horizontal position of the anchor point is as close as possible to what
    it was originally.

* Do this for any frames and iframes in the page, as well as for the document as
  a whole.

* Only define the anchor point just before the *first* time the frame is resized
  while it is shown, not every time. That way you will avoid the possibility of
  the position drifting away from the original after repeated resizing.

* Exactly how this method should deal with languages which aren't read in the
  {left-to-right, top-to-bottom} direction is left as an exercise for the reader.

Example: let's say I'm in an HTML page, and the first completely visible line at 
the top of the screen reads
|
| razed and they shall be scorched to the earth. Their tags shall

When I resized the window, the content would always be scrolled so that the word 
`razed' had exactly the same vertical offset from the top of the scrollport as it 
did originally. (The horizontal position would obviously differ because of the 
different wrapping of the paragraph.)

Does this make any sense?

To some degree, but focusing on just the NW corner will mess things up when
there are left-floating elements involved.  I proposed that we worry about the
entire top of the viewport.
Putting on [nsbeta2+][6/01] radar.  This work must be done by 06/01 or we may 
pull this for PR2.
Whiteboard: [nsbeta2+][6/01]
Target Milestone: M16 → M17
Not going in before M16 closes tonight.
*** Bug 40104 has been marked as a duplicate of this bug. ***
With 24 dups, this thing should be mostfreq.

*SPAM* - adding mostfreq keyword to bugs with loads of dupes. Please aid this 
effort by adding this keyword to any bugs with more than 15 DUPEs.
Keywords: mostfreq
*** Bug 40505 has been marked as a duplicate of this bug. ***
*** Bug 40749 has been marked as a duplicate of this bug. ***
I have an implementation idea for this. When we need to store the scroll 
position, could we store the XPointer to the topmost (as in the visible area) 
DOM element? Of course we do not yet have any XPointer support, but suppose we 
did, would this work?

I know that if we have scripts involved, the script may change the document 
between each load so much that that might break almost any attempt, but are 
there any other issues?
I have a fix in my tree for this that works for both Gfx and Native scrollbars.  
So far, all I've implemented is very basic scroll positioning (x,y pixel 
offsets).

The fix was:

 Implement nsIStatefulFrame for nsScrollPortFrame for the gfx scrollbar case and 
nsScrollFrame for the native scrollbar case (implementations are identical)

 Expose nsFrameManager's CatureFrameStateFor and RestoreFrameStateFor as public 
methods and add an additional parameter to accept a fixed content id (scroll 
frames don't have any content associated with them.

 Capture frame state for the root scroll frame in PresShell::CaptureHistoryState 
and restore it in PresShell::EndLoad.  Use a fixed content id.  (I chose 1, but 
should probably come up with an enum or something like that)

Not sure this will be approved for beta2 now that the deadline is passed, keep 
your fingers crossed!  :)
Summary: Saving scroll position in session history → Save scroll position in session history
Whiteboard: [nsbeta2+][6/01] → [nsbeta2+][6/01] fix in hand
Due to slip in schedule, moving this bug from [6/01] to [Will be minus on 6/15] 
for fix deadline.
Whiteboard: [nsbeta2+][6/01] fix in hand → [nsbeta2+][Will be minus on 6/15] fix in hand
> So far, all I've implemented is very basic scroll positioning (x,y pixel...

I made a slight improvement on this today.  Instead of storing just x and y, 
also stored height and width of the frame *inside* the scroll frame.  When 
returning to the page, I scale x and y proportionally to the new height and 
width:
  newx = oldx * newwidth / oldwidth
  newy = oldy * newheight / oldheight

This gets us to within a few lines of where we were on even tough pages like:
http://www.w3.org/MarkUp/ (Try scrolling to a choice place in Nav or IE, then 
going somewhere else, radically changing window width and returning - both 
apparently store pixel offsets, and you'll have to scroll to find your place!)

Ideally, we should store a content pointer, but I don't have any ideas on how to 
easily implement this.  (I don't think I'll have time to go the xpointer 
route...)
Just checked in the fix.  To verify, go to any page.  Scroll part way down.  Go 
to any other page.  Click back.  You should see that you are at the same part of 
the page that you were at when you left the page.  Thanks!
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
*** Bug 42914 has been marked as a duplicate of this bug. ***
VERIFIED Fixed in the 2000061908 builds on all platforms. note this fixes saving scroll position for back/forwqard but nor for 
reload. That issue is beingtracked separately in bug 40104

note: the username t8m@centrum.com is being truncated to t8m@centrum.c on the cc list by 4.x and bugzilla won't let me submit 
this bug as such so I had to remove it, sorry, I'll try to correct later.
Status: RESOLVED → VERIFIED
No longer blocks: 24206
This has now regressed and been reborn as bug 46877. I suggest we use our voting
power to try and get this fixed again.

*** Bug 276007 has been marked as a duplicate of this bug. ***
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.