Page MenuHomePhabricator

Hash fragment/scroll handling is broken in mobile
Open, MediumPublic

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 added a subscriber: ovasileva.

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

Edtadros added a subscriber: Edtadros.

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.

Jdlrobson added a subscriber: Jdlrobson.

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)