User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:73.0) Gecko/20100101 Firefox/73.0

Steps to reproduce:

Set zoom under options, open webpage, click on link on webpage and open link, then close link.

Actual results:

Webpage goes back to the top and not to the position previously on page.

Expected results:

It should return to the same position on the page as the link that was opened and not to the top of the page.

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:73.0) Gecko/20100101 Firefox/73.0
20200128001646

Please provide exact steps to reproduce the issue. The following works for me:

STR:

1. In about:preferences set Default Zoom to 133%
2. https://en.wikipedia.org
3. Scroll down.
4. Either left-click a link to open it in the same tab or Ctrl+click to open it in a new tab.
5. Either click the Back button or close the new tab that was opened previously.

AR:
The initial page retains its scroll position.

If the above steps are what you meant, check if the problem goes away when starting with add-ons disabled (safe mode).

Thank you for attempting to solve the problem. Your example is exactly the steps that I had taken, including the 133% zoom. I now tried the opening in safe mode and it didn't help. Unchecking or checking the zoom text only works to clear the problem until the browser is opened the next time and then I have to repeat the zoom checking or unchecking to clear the problem. Please give me your thoughts.

(In reply to jmacione from comment #2)

Please give me your thoughts.

It would be useful to check if you can reproduce the issue in a new profile as well:

1. Enter about:profiles into the address bar.
2. Click the Create a New Profile button, then the Next button, name the profile whatever and click the Finish button.
3. Click the Set as default profile button below your old profile so that Firefox won't automatically start with the new blank profile.
4. Click the Launch profile in new browser button below the new profile and check if the problem still occurs.

Regardless of the outcome, I likely don't have anything else to add. I'll move this to what looks like an appropriate component for investigation.

I followed your instructions and set a new profile. Unfortunately, it continued with the problem. I greatly appreciate your efforts and look forward to the fix.

That is really odd... Does it happens with Nightly?

Morgan, any ideas why default zoom would have any impact here?

(In reply to Emilio Cobos Álvarez (:emilio) from comment #5)

That is really odd... Does it happens with Nightly?

Morgan, any ideas why default zoom would have any impact here?

I have no idea :( Areas of the patch that might be worth checking are where I (a) added caching for the CPS call so we don't over-do database queries (b) ensured the UI in the URL bar responded to the default zoom value when hiding and setting the zoom badge.

Otherwise, the patch just changes how we use/store the CPS value, which doesn't seem like it'd affect anything.

ni'ing pbone who mentioned to me that there's some differences with div resizing/positioning with global zoom now? Not sure if that's related, but maybe he could explain further.

Apparently someone has worked to correct the problem, but not posted here. Checking or unchecking the "zoom text only" does not change what it does. It now always returns to the top of the page when closing the link.

Now it is mysteriously changed back...thanks!!!

If this doesn't repro on Nightly it may have been fixed by bug 1561900... But otherwise I have no idea what's going on. Clearer steps to reproduce would be helpful.

Not fixed, just back to the original problem.

Checking or unchecking the "text only" zoom now has no effect. It now always goes back to the top of the page containing the link that was opened.

I thought I noticed this happening in the last few weeks without default zoom on searchfox.org, but I can't reproduce it now.

Also I have tested:

• No zoom
• Default zoom
• Tab specific zoom (whatever you get when you use the zoom controls)
• Default zoom with zoom text only.

All have the expected results.

Morgan, the think I mentioned with the divs I think is the expected behaviour. As in I had 133% zoom, then clicked "zoom text only" and the divs made themselves smaller because they were no-longer zoomed. If I sounded concerened it's that hopefully this doesn't break any web author's sites the way zooming or changing text sizes did in the early 2000s (before people used ems as much as they do now).

This problem continues, but by checking or unchecking "zoom text only" the problem goes away until the next time the browser is opened and then the procedure is required again.

I have now switched to Nitely and the problem continues.

Please address this problem. I now get updates two or more times a day, but this problem is still not addressed. Thanks!!!

The main reason this has not been fixed is that we have not been able to reproduce it.

Perhaps a screencast demonstrating the issue might help to make sure we are performing the exact same steps as you.

Thanks for the quick response. Please see screen shots attached above.

The document shows screenshots from https://protopage.com , and I can indeed reproduce the bug there (though I don't think that page has been mentioned so far in this bug report, and I'm wondering if this is specific to something on that page.

jmacione, can you clarify if this is specifically just an issue you've been hitting with that page in particular, or if you've seen it other places as well (and if so, where)?

Also, I've reproduced this several times without applying full-page zoom (and conversely, I was able to perform the STR a few times with full-page-zoom applied and without triggering the issue). So I don't think this has to do with full-page-zoom after all. I think it has something to do with the page's searchbar being focused, since it looks like we scroll up to bring that text field into view.

Here's a profile of me reproducing the bug, at https://protopage.com/ , for the record: https://perfht.ml/2Kncgbz

The screenshots are pretty small in the screenshots track, but if you look closely, you can see that the screenshots at the start do not have a visible textfield near the top left, whereas the screenshots at the end do have a visible textfield near the top left.

My STR:
(1) visit https://protopage.com/
(2) Scroll to the bottom of the page. (Ensure that the website's [textfield] Google | Amazon | Wikipedia | Maps | ... bar has been scrolled out of view. If it's still visible, then resize your window until it's skinny enough that you can scroll that bar out of view.)
(3) Click some link (note: this will open a new tab)
(4) Click to select your original tab. (Or, equivalently, close the tab that just opened, which takes you back to the original tab)

EXPECTED RESULTS:
Page should still be scrolled to the end.

ACTUAL RESULTS:
The page is not scrolled to the end. It's been scrolled up a bit so that the [textfield] Google | Amazon | Wikipedia | Maps | ... bar is in view.

I think you are correct. I can't reproduce anywhere else. But, this page didn't do it before the zoom text was added.

(In reply to jmacione from comment #20)

I think you are correct. I can't reproduce anywhere else.

OK, thanks. :)

For future reference: it would've been super-useful if you'd mentioned that site somewhere here (e.g. in comment 2, in response to GingerbreadMan's sample steps with wikipedia -- you said there that GingerbreadMan's steps with wikipedia were "exactly the steps that [you] had taken" -- but in fact, you were trying a different site entirely, which is quite an important detail & which explains why you were getting different results.

Bugs are very often site-specific (or specific to only a handful of sites), so it's extremely useful for us to have an idea of some affected site in order to proceed usefully & avoid wasting time chasing things down.

But, this page didn't do it before the zoom text was added.

I suspect that in fact it did, but it's just easier to trigger when you have full-page-zoom, because this all ties back to the textfield being scrolled offscreen, and there may not be enough content available to scroll it offscreen if you don't have full-page-zoom applied.

Note: if I hit "tab" before step (3) of my comment 19 STR, to explicitly take focus out of the textfield, then I cannot reproduce the bug. So this has something to do with that textfield having & regaining focus...

I used mozregression to track down when this broke, and it was relatively recent:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=7e15763c3316c4b0fd1441004b6000a7ad1926cf&tochange=62fb499df45aaff8686a9ae4a03a7f602cb163d3

Marking as a regression from bug 1588259.

Here's a screencast of the bug, in a fresh profile. (I'll mark the .dox attachment as obsolete, since I think this is an easier way for folks to quickly visualize the bug, with no need for opening an external program.)

Note that I'm scrolled all the way to the bottom at 0:09 when I click the link -- but when I switch back to the same tab at 0:13, the scrollbar has magically jumped up for no clear reason (such that the focused textbox is now in view).

kmag, maybe you could take a look here? mozregression says this was caused by the patch stack in bug 1588259 - do you know how/why that bug's changes might be causing this?

I'm not sure. I imagine it has something to do with the site's JS. The patches in question suppress event handling while we're spinning the event loop waiting for the new window to be open. Presumably prior to that change, there was some code running either on the site or in our front-end JS that runs slightly later now, but I really don't know. The site's JS is heavily obfuscated, and I don't have the time to try to decode it.

The severity field is not set for this bug.
:farre, could you have a look please?

For more information, please visit auto_nag documentation.

No longer a problem. Unable to explain why it now performs normally.