1669952 - Pinch zoom position is changed after hitting the back button

Status: REOPENED

(Core :: Panning and Zooming, defect, P3)

Description

[Hani Yacoub, Desktop QA]

Affected versions

Firefox Nightly 83.0a1

Affected platforms

Windows 10 x64
MacOS x 10.15

Preconditions

fx.webrender.all = true OR fx.webrender.all = false
apz.allow_zooming = true
apz.windows.use_direct_manipulation = true

Steps to reproduce

1. Open Firefox
2. Go to wikipedia.org
3. Pinch zoom on any language displayed on the page (eg. English)
4. Click on the link
5. Click on the back button

Expected result

Pinch zoom position should remain the same after hitting the back button

Actual Result

• Pinch zoom position is changed after hitting the back button on both touchpad and touch screen

Suggested severity

S2

Comment 1

[Kartikaya Gupta (email:[e-mail])]

Hm. We're restoring the zoom level but the visual scroll position gets reset to 0,0. It would be better if we either didn't restore the zoom level or also restored the visual scroll position.

Comment 2

[Kartikaya Gupta (email:[e-mail])]

And yet evidently in some cases at least we do restore the visual scroll position, per bug https://bugzilla.mozilla.org/show_bug.cgi?id=1669982

So most likely in this case it's getting restored and then reset somehow.

Comment 3

[Kris Taeleman (:ktaeleman)]

I think it would be safer at this point to not restore the zoom, as it can be very disorienting when hitting back on sites with dynamically loaded content.

@botond: I think you've looked at this before, any thoughts?

Comment 4

[Kartikaya Gupta (email:[e-mail])]

This one is not a bug on our side. Wikipedia is resetting the scroll position by calling scroll(0,0) on the window. Chrome will also reset the scroll position back to 0,0 if you scroll down, click away, and go back.

Edited to add, for posterity:
While investigating I observed that the scroll position actually gets changed three times after hitting back. The first one is from the restore code, which restores the scroll position that was there prior to navigating away. That one has a ScrollPositionUpdate with origin=Restore. The second one is from the search field getting focus and trigger the scroll to show code, here. The third is the scrollTo from JS. The second and third both generate a ScrollPositionUpdate with origin=Other.

Comment 5

[Kartikaya Gupta (email:[e-mail])]

Argh, didn't mean to close it just yet. Kris' question above is still valid.

Comment 6

[Kartikaya Gupta (email:[e-mail])]

I will, however, downgrade it and take it off the blocker list.

Comment 7

[Kris Taeleman (:ktaeleman)]

Edge seems to handle this case, maybe they restore their zoom after the site has loaded again?
From a browser comparison perspective, it does seem like we should restore the zoom position, but maybe this can be done for the follow-up releases and we reset the zoom for now?

Comment 8

[Botond Ballo [:botond]]

(In reply to Kris Taeleman (:ktaeleman) from comment #3)

@botond: I think you've looked at this before, any thoughts?

I think restoring the zoom level and the visual scroll position should "go together", i.e. we shouldn't do one without the other.

Whether we restore them or not is largely a UX question. My personal feeling is that restoring them is consistent with the current behaviour of restoring the layout scroll offset (after all, the distinction between the visual and layout scroll offsets it's largely an implementation detail and not particularly relevant to the user), and that it's a useful behaviour. Causing problems for dynamic sites could be a reason not to do it, or to try to detect dynamic sites and behave differently for them, but I don't have a good sense for the prevalence of this issue.

(In reply to Kris Taeleman (:ktaeleman) from comment #7)

From a browser comparison perspective, it does seem like we should restore the zoom position, but maybe this can be done for the follow-up releases and we reset the zoom for now?

That sounds reasonable to me (especially as reliably restoring both requires bug 1525259 which we've already postponed to desktop-zoom-post).