Bug 19896 – Safari does not maintain content position in viewport when resizing window after scrolling

• Status: UNCONFIRMED
• Component: New Bugs

[Dylan]

If you resize a page to be either narrower or wider while not at the very top of the document, Safari/WebKit does not attempt to scroll to follow the content. Rather, it maintains a fixed scroll position and lets the content shift as appropriate due to any change in metrics caused by the resize. 

For example, if you scroll down 100 pixels and then make a window smaller and thus force additional line-wraps above the viewed content, Safari/WebKit maintains the 100 pixel scroll from the top. Since the content above has re-wrapped and now takes more vertical space, this forces the content that was at the top of the browser window to drop down. If you were reading the document at the time and resized it to get at a file on the desktop, when you come back you have to search the visible content to see where you were.

If you do the same thing in TextEdit (though obviously you need a long text file not website), TextEdit makes an attempt to keep the top line that you were looking at near the top of the viewport, and it does a good job (if you resize a window to be like an inch wide, it starts messing up, and it has some problems with paragraphs, but for most reasonable widths TextEdit keeps the top line of your viewport within a few lines of the top and adjusts the scroll location accordingly).

Firefox does the same as Safari/Webkit for what its worth, but I don't really think that there is any compatibility issue (except perhaps with the javascript resize functions which would not expect this scrolling to happen). As it is, if you resize a page  in either browser and content re-wraps and takes up more space, it is very easy to completely lose your position in the document. But, if the viewport could follow the top-most element on screen (like TextEdit), this would no longer be an issue. 


To reproduce, visit any long page with lots of text that can be made to re-wrap. The WebKit blog [ http://webkit.org/blog/ ] works. 
Scroll down a at least a few hundred pixels and put some distinct header at the top of your viewport so that you have something obvious to watch (I used "Just the Beginning" in the Squirrelfish entry, but anything works that has sufficient text above it).
Resize the window to be narrower than the content area of the page (in the case of the webkit blog, you need to make it smaller than the width of the main text column) and watch your visual placeholder move down the viewport, eventually off screen. 
Take note of what now happens to be on the top of the screen, and make the window wider. Watch this item disappear off the top of the viewport almost instantly and your original marker come back into sight eventually (yes, resizing to the same original size brings it back to where it started, but if you start narrow and go wider you lose your place, and if you start wide and go narrower you also lose your place)

To see what TextEdit does, open any long text file (the page source for the website you were testing should work, TextEdit will render it similarly to a browser, not as source code), and do the same thing. Although it makes some mistakes, TextEdit tries to keep the topmost element near the top of the page (it succeeds especially well when making the page wider, it has some issues with paragraphs when going narrower). It seems TextEdit works best if an element is cut off on the top (for example, scrolling so that the x+y tree diagram (pre) in the WebKit blog is half off the top of the page). Xcode, if line wrapping is on, also keeps the same line number at the top of the viewport (although it does not re-wrap its lines until you release the resize handle so it has it a little easier than would Safari/Webkit)



One thing that would need to be considered if this is changed is that many pages have a fixed-width navbar along one side that will rarely if ever re-wrap even if the page changes size, and an element in the main content of the page, when resized, will move relative to this very tall navbar. So, when determining what element to keep at the top of the page, one from the content area would need to be selected, not from a navbar (the easiest way to do this that I can think of is to select an element from the widest block that touches or crosses the upper edge of the viewport. Hopefully that will select something in the content in almost all cases).