252803 - Firefox doesn't keep the current text position when the window is resized

Status: REOPENED

(Core :: Layout, defect)

Description

[Carlos Ribeiro]

User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7) Gecko/20040707 Firefox/0.9.2
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7) Gecko/20040707 Firefox/0.9.2

Well, this is not really a bug, it's more of a nuisance. When the Firefox window
is resized, you end up looking at a different portion of the page; in other
words, you lose your relative position inside the text. For example, if you are
at the middle of a very long webpage, and resize the window, then you'll end up
vieweing a completely different portion of the same page. I don't think this is
related to Gecko, but to the way the vertical scrollbar is updated during resizes.

(just to clarify, while it's obviously impossible to keep the same viewing
window when the browser window is resized, I expected to keep seeing at least
part of the text that was on the screen before the resizing took place. That's
my asumption, at least...)

Reproducible: Always
Steps to Reproduce:
1. Go to any web page; longer ones make it more easy to see what's going on.
2. Position the vertical scrollbar about midpage.
3. Resize the browser to half its current width.

Actual Results:  
You'll notice that the vertical scrollbar is now positioned somewhere close to
the 25% mark. Please note that this will happend independent of the page; for
example, assume that you are filling a form somewhere in the page, and then
resize it; depending on the length of the page, you may end up not seeing the
form at all. In this case, if you type some key, the viewing port will jump to
the correct place immediately. It's weird.

Expected Results:  
In short: the vertical scrollbar should keep its position *relative* to the
length of the page, independent of the current *length* of the page.

Actually, I believe that the result of test outlined above tells exactly what is
happening. When the window is resized, the length of the scrollbar gets changed,
but it's current position not. This is why we end up looking at some different
portion of the page. Instead, the vertical scrollbar position should have been
updated *in proportion* to the change in size; this would suffice for the
relative position to be kept the same. 

For example: assume that vertical scrollbar has length=100, position=50. If the
length doubles (length=200, as a result of window redimensioning), then the
correct position should be set to 100.

Comment 1

[Mark]

I agree. And the same thing happens when the font is resized, with ctrl- or ctrl+.

What it should do is before changing, record first visible character on the
screen. When the resize/font-change is done, scroll so that that character is on
the first visible line.

Comment 2

[Jon B]

Yes, the same thing goes for font resizing with ctrl+scroll wheel.

Comment 3

[Marc Bejarano]

i filed bug 304823 for the related issue with font resizing.

Comment 4

[Gary Schuster]

It also happens when the sidebar is opened or resized.   

Comment 6

[Mike Conley (:mconley) (:⚙️)]

I can't seem to reproduce this using a recent Nightly on Windows XP (Mozilla/5.0 (Windows NT 6.1; WOW64; rv:21.0) Gecko/20130214 Firefox/21.0). Our resize code seems to be doing a good job of keeping the scroll position in the browser.

Marking as WORKSFORME unless someone else has some more specific steps to reproduce.

Comment 7

[Kotofos]

Can reproduce at 40.0.3 at windows 7 at new profile.
Reproducible on long enough pages.

Steps:
1. Start Firefox by clicking on the desktop icon
2. Press (or Ctrl+N for windows users) to open a new browser window
3. Paste http://doc.qt.io/qt-5/model-view-programming.html in the address bar and press Enter
4. Set text zoom 120%
5. Scroll to "The model/view architecture" header
6. Resize window horizontally

Expected results:
Header stay at same place at screen
Actual results:
Header moves when resizing horizontally

Additional info:
Bug can be seen even at this page: https://bugzilla.mozilla.org/show_bug.cgi?id=252803#c0

Screenshots:
Original http://snag.gy/CIrBR.jpg
resized http://snag.gy/aRhSd.jpg

Sorry for jpeg.

Comment 8

[Marc Bejarano]

reopening as per comment 7

mconley: does that recipe work for you?

Comment 9

[Mike Conley (:mconley) (:⚙️)]

Ah, yes - I think I see what this bug is talking about now.

When the page is reflowed due to the window resize, we lose the scroll position. We should probably try to keep the same elements in view, if possible.

I suspect this is a layout enhancement request.

Comment 10

[Steve McMillen]

I run into this *a lot* with internal wiki pages that allow the page to flow full width of screen.  Its really annoying.  The example given above has page width limits so the effect is not as dramatic but if you find a page that allows text to flow fully and is more than 2-3 pages long the effect is very dramatic and its often very hard to find the place you were at.  For example, try this: http://www.kegel.com/minecraft/.  That page is only 2-3 pages long so its not even as bad as some of the docs we work with internally which are 20-40 pages long.  You can loose your place by 10 or more pages sometimes.

NOTE: You have to SCROLL to the position to repro (if you use bookmarks then things work as expected).  But if you are just scrolling thru (reading) a doc and then resize you loose your place.

Note: issue also occurs when you resize by hiding left navigation panel on our internal confluence site.  Hopefully whatever fix is put in place handles these types of resize events also (where you are resizing page regions, not resizing the browser window).

Like Mike says, what would be ideal is find the top-most element and then scroll that back to the top after the resize event.  I looked around hoping to find a plugin that did this since is soooo annoying (happens to me often because I'm always working with internal confluence specs) but can't find anything :(

Comment 11

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S4. However, the bug has 13 votes.
:dholbert, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 12

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

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.