User Agent: Mozilla/5.0 (Android 7.1.1; Tablet; rv:65.0) Gecko/65.0 Firefox/65.0 Steps to reproduce: 1. https://github.com/mozilla-mobile/focus-android 2. Request desktop site 3. Zoom in on the page 4. Click on the issues link Actual results: The page is still zoomed in. After zooming out and pressing the back button the previous page is zoomed out and should still be zoomed in. Expected results: The page should be zoomed out.

Thank you for your report! I was able to reproduce this issue but every time when I went to issues link, the page was zoomed out and even if i zoomed out again, when i tapped on the back button the previous page was still zoomed in, I checked this on the latest Nightly build 65.0a1 with Samsung Galaxy S9 (Android 8.0.0). Can you please check again and see if when you tap on "issues link" the page is zoomed in or out and also to mention what device, android version and build you used. If you can make a video with this issue please. Thank you, Andrei

Thank you for looking into it. The device is a Samsung Galaxy Tab A with Nightly 65.0a1 (2018-12-03). This is my experience: Actual Main page (zoomed in) - link (zoomed in) - link (zoomed out) - main page (zoomed out) Expected Main page (zoomed in) - link (zoomed out) - main page (zoomed in)

Hello and thank you for your report, The issue described seems to be the intended behaviour, but NI'ing :snorp to confirm.

I get: 1) Zoom in, click "issues" link 2) Issues loads with default zoom 3) Go back, page has default zoom 4) Go forward, "issues" page is zoomed in. So for me, the only bug seems to be that zoom on https://github.com/mozilla-mobile/focus-android is not correctly restored. I think this occurs when we don't use the bfcache, which can happen for a variety of reasons.

Thank you for your response. May I ask what happens when you click releases?

For me, zoom values seem to be remembered consistently on a per-page basis. That is, if I zoom in, and click a link (be it Issues or Releases), the new page is zoomed out, but going Back restores the my zoomed-in zoom level on the original page.

Can you think of any reason that wouldn't be the case?

(In reply to csheany from comment #7) > Can you think of any reason that wouldn't be the case? My understanding is that when we navigate away from a page, we store certain information such as the scroll offset and the zoom level in a place called the "session store", and restore them from there when we navigate back to that page. It sounds like this mechanism may be failing for some reason in your case. Snorp said above that this can happen for a variety of reasons. I'm not really familiar with it and don't know what those reasons are specifically.

Do you think that Jan might have a better idea?

Are there other bugs that might be getting in the way?

Based on comment #4, my theory is this: When we navigate away from a page, its scroll position and resolution (= pinch-zoom) are recorded into the PresState [1] and then stashed away into the session history, but for historic reasons (bug 873926) that presumably didn't take into account the possibility and future importance of pinch-zooming (at least on mobile), we don't save anything at all if the page has never been scrolled [2]. Previously this wasn't really noticeable because it's rare to pinch-zoom a page while never changing the scroll position at all. However because of bug 1498812, things are different at the moment: Right now, for the purposes of session history and scroll position restoring, scroll position still means the position of the *layout* viewport, and when you pinch-zoom into a page, it's rather to easy to get into a situation where you only scroll the *visual* viewport around, while the layout viewport remains unchanged all the time. [3] Hence when you then click a link while never having scrolled the layout viewport, we don't record the changed resolution into the PresState and when you later go back, the pinch zoom isn't restored. Bug 1498812 should get fixed soon-ish and restore things back to how they previously worked [4], but for complete correctness we should fix this here as well. [1] https://searchfox.org/mozilla-central/rev/bcc0fe1081dc4f84fc5fdfebe0d2de8c075a4e2c/layout/generic/nsGfxScrollFrame.cpp#6114-6149 [2] https://searchfox.org/mozilla-central/rev/bcc0fe1081dc4f84fc5fdfebe0d2de8c075a4e2c/layout/generic/nsGfxScrollFrame.cpp#6116-6119,6144-6148 [3] Because a picture is worth a thousand words, just turn on "apz.minimap.enabled" - the red border is the layout viewport and the blue border the visual viewport. [4] I.e. scrolling the *visual* viewport even just by a little bit will be enough to turn on state saving for both scroll position and resolution.

This seems to create a pretty bad user experience, so tentatively setting to P2.