[Webkit-unassigned] [Bug 19896] New: Safari does not maintain content position in viewport when resizing window after scrolling

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=19896

           Summary: Safari does not maintain content position in viewport
                    when resizing window after scrolling
           Product: WebKit
           Version: 525.x (Safari 3.1)
          Platform: Macintosh
        OS/Version: Mac OS X 10.5
            Status: UNCONFIRMED
          Severity: Enhancement
          Priority: P4
         Component: New Bugs
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: dylanryan at mac.com


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).


-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.