Scroll position persists after clicking on a link

VERIFIED FIXED in Firefox 67

Status

()

VERIFIED FIXED
2 months ago
27 days ago

People

(Reporter: csheany, Assigned: botond)

Tracking

({regression})

Firefox 67
Firefox 67
ARM
Android
regression
Points:
---

Firefox Tracking Flags

(firefox65 unaffected, firefox66 unaffected, firefox67 verified)

Details

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

2 months ago

User Agent: Mozilla/5.0 (Android 7.1.1; Tablet; rv:67.0) Gecko/67.0 Firefox/67.0

Steps to reproduce:

  1. Open https://github.com/mozilla-mobile/focus-android
  2. Request desktop site
  3. Tap Commits
  4. Scroll to the bottom
  5. Tap Older

Actual results:

The bottom of the page is in view

Expected results:

The top of the page is in view

(Assignee)

Comment 1

a month ago

Regression compared to Firefox 65.

Keywords: regression, regressionwindow-wanted
(Assignee)

Updated

a month ago
Keywords: regressionwindow-wanted

I can't reproduce at all on my Android phone.

(Assignee)

Comment 4

a month ago

I was testing on a tablet. I just tried on a phone, and I can't repro there either. Guess it's tablet-specific.

I couldn't reproduce this issue on the latest Nightly build 67.0a1 with a Google Pixel 3 XL (Android P) and Sony Xperia Z5(Android 7.0).
Every time when I tapped on the older the top page was in view. I tried to reproduce this while the web page was zoomed in but with not so much success.
Can you please mention the exact device, android version and firefox version that are you using while reproducing this issue.

Flags: needinfo?(csheany)
(Reporter)

Comment 6

a month ago

Thank you for looking into it. The device is a Samsung Galaxy Tab A.

I am using the latest Nightly.

As Botond mentioned, only tablets might be affected.

Flags: needinfo?(csheany)

Comment 7

a month ago

Hi,
I was able to reproduce the issue with a Samsung Galaxy Tab S3, on Firefox 65.0.1, and Beta 66.0b7.
But I was not able to reproduce it on the latest Nightly 67.0a1 (2019-02-12).
I will confirm the issue.
Thanks for the report!

Status: UNCONFIRMED → NEW
status-firefox65: --- → affected
status-firefox66: --- → affected
status-firefox67: --- → unaffected
Ever confirmed: true
OS: Unspecified → Android
Hardware: Unspecified → ARM

I'm confused on how to rectify comment 2 with comment 7. Can someone please try to explain?

Flags: needinfo?(mirabela.lobontiu)
Flags: needinfo?(botond)

Comment 9

a month ago

Mira, can you help with a regression?

Keywords: regressionwindow-wanted
(Assignee)

Comment 10

a month ago

I think comment 7 may be confusing the "good" and "bad" outcomes.

The scroll position being at the top of the new page, which happens in 65 and 66, is the "good" outcome. The scroll position being near the bottom of the new page, which happens in nightly, is the "bad" outcome.

It's a bit confusing because if navigation does not occur, you expect the scroll position to be preserved. If navigation does occur (as in these STR), you expect the scroll position to be at the beginning of the new page.

Flags: needinfo?(botond)

I'll go with that, thanks :)

Has Regression Range: --- → yes
status-firefox65: affected → unaffected
status-firefox66: affected → unaffected
status-firefox67: unaffected → wontfix
Flags: needinfo?(mirabela.lobontiu)
Keywords: regressionwindow-wanted
Summary: Scroll posititon persists after clicking on a link → Scroll position persists after clicking on a link

I will see what's going on there.

Flags: needinfo?(hikezoe)

I suppose we still want to fix this in 67.

Anyway, I thought I can reproduce the issue on RDM with specifying 'Nexus 10' there (and enabling apz.allow_zooming pref). But the issue I can see is also reproducible without disabling the minimum scale change. So the issue I am seeing might be a different issue.

I also tried on Android emulator with tablet mode (I believe it's tablet mode, I am using 1280x800 resolution), but I can't reproduce it yet.

status-firefox67: wontfix → affected

Comment 14

a month ago

Thank you Botond, I was misguided by the "good" and "bad" outcome.
I rectify Comment 7, the issue is reproducible only in Nightly 67.0a1.
Thank you, Ryan, for changing the flags.
I`m sorry for the confusion.

(Assignee)

Comment 15

a month ago

Let's park this bug with me as I'm able to reproduce it. I will investigate when I get a chance.

Assignee: nobody → botond
Flags: needinfo?(hikezoe)
(Assignee)

Comment 16

a month ago

The issue here is related to the layout viewport being larger than it should be on this page. The layout viewport size should match the visual viewport size when the page is at its minimum zoom, but on this page it's taller, tall enough to include the entire content size.

(Assignee)

Comment 17

a month ago

I have a fix for this locally. I would like to write a test as well.

(Assignee)

Comment 20

a month ago

Depends on D19996

Attachment #9044294 - Attachment is obsolete: true

Comment 22

a month ago
bugherder
Status: NEW → RESOLVED
Last Resolved: a month ago
status-firefox67: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 67

Verified as fixed on latest Nightly build (67.0a1) with Samsung Galaxy Tab S3 (affected device).

Status: RESOLVED → VERIFIED
status-firefox67: fixed → verified
You need to log in before you can comment on or make changes to this bug.