Open Bug 19261 Opened 25 years ago Updated 2 years ago

When resizing the window, need to keep place in content

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Type:
defect

Tracking

()

People

(Reporter: sfraser_bugs, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

(Keywords: polish, Whiteboard: [nsbeta3-])

Attachments

(1 file)

Example of the bug - you resize and lose content position
2.58 MB, image/gif
Details 
Load a long HTML document, and scroll half way down. Now take note of your place
in the content, then resize the window horizontally. Notice how, after reflow,
we've just lost your place in the content, so that you have to scroll around to
find it.

What we're doing now is repositioning after resize based on the scroll position.
This is wrong. We should anchor via an offset into the content, and set the
scroll position accordingly.
Assignee: nisheeth → pollmann
Depends on: 16806
Marking this dependent on the "store scroll position" bug on Eric Pollmann's
plate and re-assigning this to Eric.
Status: NEW → ASSIGNED
OS: Mac System 8.5 → All
Target Milestone: M14
Moving to M14, per dependency.
*** Bug 19077 has been marked as a duplicate of this bug. ***
Moving non PDT+ bugs out.
Target Milestone: M14 → M15
Moving out to M17.
Target Milestone: M15 → M17
Rescheduling
Target Milestone: M17 → M16
Not nsbeta2+ and no fix ready, so pushing off.  Hopefully this will be fixed 
when I fix bug 16806!
Target Milestone: M16 → M17
Marking polish for tracking.
Keywords: polish
This turns out to be a completely separate code path from that for bug 16806.  
CC'ing Eric Vaughan on this one as it may be Gfx Scrollbar related.

For reference of what we should look like, IE does an absolutely beautiful job 
of keeping place in the content while resizing the window.  An example is here:
http://www.w3.org/MarkUp/  Scroll about halfway down the page or farther, then 
begin resizing horizontally to see the different strategies we take versus what 
IE takes.
Dup of bug 42660
*** Bug 42660 has been marked as a duplicate of this bug. ***
Taking to look at since Eric has not had a chance...
Assignee: pollmann → attinasi
Status: ASSIGNED → NEW
Accepting and moving to M18
Status: NEW → ASSIGNED
Target Milestone: M17 → M18
This looks like it can be taken care of in the ViewManager:

When the window is resized the method nsViewManager2::SetWindowDimensions is 
called. In there the resize-reflow is kicked off and then nothing else is done. 
One possible solution would be to get the size of the view before and after the 
resize reflow and compute the delta. Then, the scroll position of the root 
scrollable view could be re-scrolled to account for the change in the relative 
position of the scrolled content. 

Put another way, the scroll position is currently unchanged when the length of 
the document is changed and that makes it look like the content is scrolling 
when resized. If we cause a scroll to balance the change in the document length 
then it would no look like the content had scrolled. If we tracked the scroll 
position in relative terms, like in percent, then this would not be necessary. 
However since we track the scroll position in absolute terms we need to account 
for the change in absolute length and fixup the scroll offset.

CC'ing Kevin to see if this sounds rational to him, since he knows how the 
ViewManager works better then I do.
I'm not clear on how we can use a view size delta to ensure that we keep place in 
the content after a resize. A change in width could cause all sorts of layout to 
change (e.g. a line with a big image suddenly begins to wrap), so simple view 
size deltas don't seem to cut it here.

I'd imagine that we'd want to do something like get the content node of the 
content in the top left of the visible area, and ensure that we scroll after 
resize so that that content node is as close as possible to its old position.

Or am I misunderstanding something here?

I agree.  The 'percent' approach described above sounds a lot like what I did 
for bug 16806.  It works pretty well, but not in all cases.  It may cause the 
position to shift plus or minus a few lines as we are reflowing (it does in 
16806's case, leaving, resizing, then returning to a page).  This would probably 
be a lot more noticable when resizing a page.  There are some alternative 
approaches  discussed on 16806 - don't know if any of these are reasonable, but 
they might be worth a look!

That said, the delta, or percent approach is probably better than what we're 
doing now, it's a step in the right direction.  And this is acting as a reminder 
for me to open a new bug on myself to come up with a better fix for 16806.. :)

You are spot-on Simon, in your explanation of why the size-delta approach is 
imperfect. I was looking for an 80-20 fix (80% of the benefit for 20% of the 
risk). If we have the time we should get this 100% correct, however.

Keeping track of the content element or frame at the top of the viewport (and 
the scroll offset of that element as well in case it is not flush at the top) 
would be the best approach, however I'm guessing we need to do it symbolically 
to handle cases where the content element and/or frames are destroyed and 
re-created (as pollman mentioned in the related bug 43114).

So, how important is this? nsbeta3? I'll nominate it and see what the PDT 
thinks...
Keywords: nsbeta3
It's not trivial to pick the right content element to track.  See my comments 
dated 2000-04-16 on bug 16806.
Getting back to a comment by Eric on 2000-06-07 20:00:

I tried IE5 and it doesn't seem to handle the resize well at all! It doesn't 
even guarantee that a heading at the top of the screen stays visible when I 
resize... Were you using IE5.5 or something? Opera 4, on the other hand, keeps 
whatever is at the top of the window pretty much pasted to that location no 
matter how I resize...

I'm not sure it matters too much what IE does, however I wonder why we are 
seeing different behavior. 
[nsbeta3-] and FUTURE.
Whiteboard: [nsbeta3-]
Target Milestone: M18 → Future
Could you do this:
Before resize, insert a temporary anchor in the current text position, and then 
after reflow navigate to that anchor and remove it?
*** Bug 100497 has been marked as a duplicate of this bug. ***
I've been inactive on bugzilla a long time but I'd like to get involved again.  

Does this one need a testcase?  

If so, please email me, or send me an AOL IM at pakaran2.  I'll be out most of
this evening.
Depends on: 43114
*** Bug 139832 has been marked as a duplicate of this bug. ***
Keywords: nsbeta1
Summary: When resizing the window, need to keep place in content → When resizing the window, need to keep place in content (loses scroll position after text zoom)
Keywords: nsbeta1
Summary: When resizing the window, need to keep place in content (loses scroll position after text zoom) → When resizing the window, need to keep place in content
.
Assignee: attinasi → other
Status: ASSIGNED → NEW
Priority: P3 → --
QA Contact: cpetersen0953 → ian
Target Milestone: Future → ---
Still a problem in Mozilla 1.7b
(Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040421)
(4 1/2 years later).
*** Bug 198876 has been marked as a duplicate of this bug. ***
*** Bug 98895 has been marked as a duplicate of this bug. ***
*** Bug 146239 has been marked as a duplicate of this bug. ***
Blocks: 168902
Assignee: layout → nobody
QA Contact: ian → layout
Was just about to report this "bug".

As I resized the window horizontally while browsing this site http://www.thebestpageintheuniverse.net/c.cgi?u=ranker_sucks , the content rearranged itself but the scrollbar stayed in it's absolute position instead of following any of the visible content.
Be really nice if this could get fixed.  I often run into this issue.
this as been reported 16 years ago (!!) and nobody has fixed this really annoying bug?
Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 7 duplicates and 17 votes.
:dholbert, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(dholbert)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Flags: needinfo?(dholbert)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: