Page MenuHomePhabricator

[EPIC] Hash fragment/scroll handling is broken in mobile
Closed, DeclinedPublic

Description

Scrolling doesn't work as expected in mobile. Due to several issues here, we likely want to rethink how it works.

Issue 1: Mobile: Section links jump to wrong spot when a section is open

I happened to notice that the section links in the Safari mobile view navigated to a seemingly random place within the article if the page had already been loaded and one or more preceding sections had previously been opened. In the preceding case, trying the "Australia" links immediately after the "sight vocabulary" links caused this behavior (e.g., by clicking on one of the "sight vocabulary" links, then clicking the "back" button twice [once to return to the top of the page and once to go back to the sandbox] and then immediately clicking on one of the Australia links). I'm wondering if may be because the section's physical location is being calculated assuming that all sections are collapsed. Once I collapsed all above sections and tried again, the section link sent me to the correct place.

Issue 2

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

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.

Event Timeline

@MattCleinman: Hi, which codebase / repository is this task about? (Please set appropriate project tags when possible. Thanks!)

@Aklapper Thanks, didn't realize I had more to tag. I added MobileFrontend.

ovasileva assigned this task to Edtadros.
ovasileva subscribed.

@Edtadros - could you take a look and provide some reproduction steps?

Edtadros subscribed.

In Safari on a mobile device.

  1. navigate to (Paste and Go): https://en.wikipedia.org/w/index.php?title=Wikipedia:Teahouse&oldid=991606142#Seeing_wikilnks_to_subtitles_on_my_iPhone

The page should appear with the "Seeing wikilnks to subtitles on my iPhone" in view.

  1. Scroll up and expand a few sections.
  1. navigate again to: https://en.wikipedia.org/w/index.php?title=Wikipedia:Teahouse&oldid=991606142#Seeing_wikilnks_to_subtitles_on_my_iPhone

Expected Result: The page should appear with the "Seeing wikilnks to subtitles on my iPhone" in view.

Actual Result: The expected section does not appear in view.

ezgif.com-gif-maker (2).gif (960×444 px, 2 MB)

Jdlrobson subscribed.

If we fix this we'd break the back button behaviour. Right now the behavior is such that when you click a link in a section and click back we expand previously opened sections so that after hitting back you appear at your previous position in the article. We can't tell when the user clicked back or refreshed the page, so this scenario breaks it.

Perhaps we could disable this behaviour when the hash fragment is present in the URL ? I

The hash fragment handling in mobile web is pretty ghastly, and I don't need to do any analysis here to say that revisiting it and all the edge cases will likely be estimated highly. I haven't done this here. If I was working on this I'd recommend dropping all the hash fragment handling and starting again with a spec of what it should do.

Would recommend turning this into a spike to do more analysis.

Jdlrobson renamed this task from Mobile: Section links jump to wrong spot when a section is open to Hash fragment/scroll handling is broken in mobile.Mar 3 2021, 9:58 PM
Jdlrobson updated the task description. (Show Details)
Jdlrobson renamed this task from Hash fragment/scroll handling is broken in mobile to [EPIC] Hash fragment/scroll handling is broken in mobile.Jul 26 2021, 8:46 PM
Jdlrobson moved this task from Triaged but Future to Epics/Goals on the Web-Team-Backlog board.
Jdlrobson updated the task description. (Show Details)
Jdlrobson added a project: Epic.

Regarding sub-issue 2 (found this issue here via T209418, which was marked as a duplicate)

capture the scroll position on every link click and ensure that expandStoredSection restores the scroll position.

Even that wouldn't be enough – what if the browser kicks the current Wikipedia page out of the device RAM (while I'm looking at a different tab), respectively if the OS kicks the whole browser out of the device RAM (probably while I have some other app open)? In that case when I re-open the respective Wikipedia tab, the same issue with regards to the collapsible sections applies – the scroll position the browser remembered only makes sense if the exact state of the collapsible sections is restore before the browser attempts to restore the scroll position. So if that's not possible and we have to resort to restoring the scroll position ourselves, basically the scroll position would have to be stored each time the page is scrolled, wouldn't it? (With some buffering/throttling obviously, so not each individual scroll event triggers the full saving routine, but still…)

Also I have a feeling that the stored sections are only preserved for the current browser session. I might have to double-check again to be absolutely sure, but I think that both with Chrome and Firefox on Android, expandStoredSection only works as long as the browser itself didn't get kicked out of the device RAM by the OS (e.g. while you temporarily were switching to a different app). Once that happens, the former section state seems to be lost for good.

The logic for remembering expanded stored sections is no longer functional and will be removed as part of T375674