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)
Core
Layout
Tracking
()
NEW
People
(Reporter: sfraser_bugs, Unassigned)
References
(Depends on 1 open bug, Blocks 1 open bug)
Details
(Keywords: polish, Whiteboard: [nsbeta3-])
Attachments
(1 file)
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.
Comment 1•25 years ago
|
||
Marking this dependent on the "store scroll position" bug on Eric Pollmann's plate and re-assigning this to Eric.
Updated•25 years ago
|
Status: NEW → ASSIGNED
OS: Mac System 8.5 → All
Target Milestone: M14
Comment 2•25 years ago
|
||
Moving to M14, per dependency.
*** Bug 19077 has been marked as a duplicate of this bug. ***
Comment 7•24 years ago
|
||
Not nsbeta2+ and no fix ready, so pushing off. Hopefully this will be fixed when I fix bug 16806!
Target Milestone: M16 → M17
Comment 9•24 years ago
|
||
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.
Comment 10•24 years ago
|
||
Dup of bug 42660
Comment 11•24 years ago
|
||
*** Bug 42660 has been marked as a duplicate of this bug. ***
Comment 12•24 years ago
|
||
Taking to look at since Eric has not had a chance...
Assignee: pollmann → attinasi
Status: ASSIGNED → NEW
Comment 13•24 years ago
|
||
Accepting and moving to M18
Status: NEW → ASSIGNED
Target Milestone: M17 → M18
Comment 14•24 years ago
|
||
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.
Reporter | ||
Comment 15•24 years ago
|
||
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?
Comment 16•24 years ago
|
||
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!
Comment 17•24 years ago
|
||
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.. :)
Comment 18•24 years ago
|
||
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.
Comment 20•24 years ago
|
||
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.
Comment 21•24 years ago
|
||
[nsbeta3-] and FUTURE.
Whiteboard: [nsbeta3-]
Target Milestone: M18 → Future
Comment 22•24 years ago
|
||
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?
Comment 23•23 years ago
|
||
*** Bug 100497 has been marked as a duplicate of this bug. ***
Comment 24•22 years ago
|
||
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.
Comment 25•22 years ago
|
||
*** Bug 139832 has been marked as a duplicate of this bug. ***
Updated•22 years ago
|
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)
Updated•22 years ago
|
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
Comment 26•21 years ago
|
||
.
Assignee: attinasi → other
Status: ASSIGNED → NEW
Priority: P3 → --
QA Contact: cpetersen0953 → ian
Target Milestone: Future → ---
Comment 27•20 years ago
|
||
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).
Comment 28•20 years ago
|
||
*** Bug 198876 has been marked as a duplicate of this bug. ***
Comment 29•20 years ago
|
||
*** Bug 98895 has been marked as a duplicate of this bug. ***
Comment 30•20 years ago
|
||
*** Bug 146239 has been marked as a duplicate of this bug. ***
I have a plan for fixing this in bug 43114.
Updated•15 years ago
|
Assignee: layout → nobody
QA Contact: ian → layout
Blocks: 398763
Comment 32•12 years ago
|
||
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.
Comment 33•10 years ago
|
||
Be really nice if this could get fixed. I often run into this issue.
Comment 34•9 years ago
|
||
this as been reported 16 years ago (!!) and nobody has fixed this really annoying bug?
Updated•2 years ago
|
Severity: normal → S3
Comment 35•2 years ago
|
||
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)
Comment 36•2 years ago
|
||
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)
Comment 37•2 years ago
|
||
You need to log in
before you can comment on or make changes to this bug.
Description
•