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.
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.
Yes, the same thing goes for font resizing with ctrl+scroll wheel.
It also happens when the sidebar is opened or resized.
OS: Windows 98 → All
Hardware: x86 → All
Version: 1.0 Branch → Trunk
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.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WORKSFORME
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.
reopening as per comment 7 mconley: does that recipe work for you?
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
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.
Component: General → Layout
Product: Firefox → Core
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 :(
You need to log in before you can comment on or make changes to this bug.