Maniphest T209418

When I navigate away from an article and then back, I'd like my scroll position to be preserved
Closed, DuplicatePublic
Actions

Assigned To

None

Authored By

	cmadeo
	Nov 13 2018, 9:10 PM

Description

From OTRS
Ticket: https://ticket.wikimedia.org/otrs/index.pl?Action=AgentTicketZoom;TicketID=10866024

Hello,

I have a technical question concerning the mobile version of Wikipedia, using the Chrome browser for Android Oreo: when I click on a hyperlink on a Wikipedia page to go on a new page (that opens in the same browser window), and then use the back button of the phone (lower right), I often don't get back to the same location of the Wikipedia page where the hyperlink is located, but higher up or lower down on the page. Why is this? Is there a remedy for this?

Many thanks for your help,
Max

Chrome for Android ... hyperlink and then go back don't get back to the exact location of the hyperlink but higher up in the page ...

Replication steps

This one seems easy to replicate in an emulated Chrome window or Android

Visit https://en.m.wikipedia.org/wiki/Ozone_layer?oldid=871775124
Expand section "Depletion"
Scroll to "Regulation" and click "Hydrochlorofluorocarbon"
Click back button
Expect: To see the link "Hydrochlorofluorocarbon"
Actual: No sign of the link "Hydrochlorofluorocarbon"

Developer notes

This doesn't appear to be related to any tinkering with window.scrollTop but is to do with the fact that sections are collapsed by default. In fact if I disable JS this works just as expected.

The method expandStoredSections inside Toggler ensures that the section that contains the link is opened, but it opens after the browser has restored the scroll position of the page.

The only way to solve this and retain the toggle behaviour would be to capture the scroll position on every link click and ensure that expandStoredSection restores the scroll position.

There is a good opportunity here to refactor Toggler to not have the responsibility of scroll position. This code should live in Minerva as Minerva should be responsible for the scroll position at all times.

Related Objects

Mentioned In: T269623: [EPIC] Hash fragment/scroll handling is broken in mobile
T230293: [Chrome] On mobile web, links to sections whose names include double quote " work incorrectly
T211162: [Bug] Exiting and re-entering the image gallery via browser history loses page scroll offset
Mentioned Here: T211162: [Bug] Exiting and re-entering the image gallery via browser history loses page scroll offset

Event Timeline

cmadeo created this task.Nov 13 2018, 9:10 PM

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptNov 13 2018, 9:10 PM

• Charlotte moved this task from Needs Triage to UX Debt Backlog on the Wikipedia-Android-App-Backlog board.Dec 3 2018, 4:40 PM

• Charlotte added a project: Android Design.Dec 4 2018, 1:09 PM

@cmadeo This is actually a mobile web issue it seems. @ovasileva can tell us how to tag it perhaps?

@Charlotte - now triaged :)

• Charlotte removed projects: Android Design, Wikipedia-Android-App-Backlog.Dec 4 2018, 2:37 PM

• Charlotte unsubscribed.

I am unable to reproduce this on either Android or iOS. However, oddly, if I follow the reproduction steps on T211162, I am then able to reproduce the bug described here.

• alexhollender_WMF mentioned this in T211162: [Bug] Exiting and re-entering the image gallery via browser history loses page scroll offset.Dec 10 2018, 5:40 PM

Jdlrobson renamed this task from When I navigate away from an article and then back, I'd like my reading depth to be preserved to When I navigate away from an article and then back, I'd like my scroll position to be preserved.Dec 12 2018, 7:19 PM

@Charlotte @cmadeo can we contact the user and ask them what webpages they see this on? I reckon there is a reflow problem on specific pages that is causing this problem, as it looks like the code is working as it should to me (hence why we cannot reproduce it). Without that information it's going to be impossible to do anything with this bug!

Similar situation here - I was able to reproduce the first time I tried this but not afterwards and cannot produce reliable reproduction steps, unfortunately

@Jdlrobson, sure! I can re-open the ticket and ask them. Is there any specifi information other than which page they were on that would be helpful to you?

@ovasileva I think I've encountered this issue too. With some pages this occurs on we should be able to get replication steps. Annoyingly we have lots of config flags that can interfere with this

@cmadeo I think this bug is page specific so it would be useful to have some examples of pages. The following information would be useful if we can get it!::

what page(s) do you notice the problem on? URLs would be ideal here e.g. https://en.m.wikipedia.org/wiki/Sunshine
what links do you click on the page, which when clicking back result in the problem. What sections of the article do they occur in?
Does the issue happen when you are logged out of Wikipedia?
What mobile browser and operating system (iOS or Android) are you using?
Click the hamburger icon and visit the settings page. Is "Expand all sections" selected? (if not, click to enable it.. does the problem go away with it selected?)

@Jdlrobson wrote to the user and will report back if they reply.

@Jdlrobson

Here's the response from OTRS:

Thank you for your answer and the precise questions. I use the mobile version of
Wikipedia, with Chrome for Android, the Chrome version being 70.0.3538.110 and the
Android version 8.0.0. I do not have a Wikipedia login. I made the essay on the site
https://en.m.wikipedia.org/wiki/Ozone_layerhttps://en.m.%20wikipedia.org/wiki/Ozone_layer,
after expansion of all sections via the upper left settings icon. I clicked on the
"hydrochlorofluorocarbons" hyperlink in the "Regulation" subsection of the "Depletion"
section (phrase starting by, "Compounds containing ..."), leading me on the page
https://en.m.wikipedia.org/wiki/Chlorofluorocarbon. When I then pressed on the "Back"
button on the lower right of my telephone, it directed me back to the top of the
"Depletion section", so somewhat higher up on the page than where the hyperlink used
is located. The behavior was different when I clicked on the "chlorofluorocarbons"
hyperlink in the very first section (phrase starting, "In 1976 athmospheric ...") - it
got me also on https://en.m.wikipedia.org/wiki/Chlorofluorocarbon, but when I pressed
"Back" again, I got back to the exact location of the hyperlink in the ozone layer
article.

@cmadeo thanks for reaching out and please extend that thanks to the user. I have clear replication steps now so this task is very actionable! Thank you!

Jdlrobson removed a project: Local-Wiki-Template-And-Gadget-Issues.Dec 18 2018, 7:36 PM

Will do, thanks @Jdlrobson

This can be reproduced if you collapse a section and then navigate out and back. The root cause seems to be javascript mutating the layout. One possible fix is to record the position offset to the current section, and restore after all layout mutating code are finished.

Jdlrobson lowered the priority of this task from Medium to Low.Jul 31 2019, 7:58 PM

Jdlrobson mentioned this in T230293: [Chrome] On mobile web, links to sections whose names include double quote " work incorrectly.Aug 15 2019, 7:11 PM

Jdlrobson closed this task as a duplicate of T269623: [EPIC] Hash fragment/scroll handling is broken in mobile.Mar 3 2021, 9:58 PM

Restricted Application added a subscriber: Masumrezarock100. · View Herald TranscriptMar 3 2021, 9:58 PM

JanTH mentioned this in T269623: [EPIC] Hash fragment/scroll handling is broken in mobile.Jun 5 2023, 12:22 PM

When I navigate away from an article and then back, I'd like my scroll position to be preservedClosed, DuplicatePublicActions