Last modified: 2014-03-18 14:24:17 UTC
When browsing an article on the iPhone (and possibly other mobile hardware) navigating Back in history closes any previously open page sections on the page that was navigated to. This means the user loses the ability to quickly navigate to inline links within an article and later resume reading that article from where he left off, and haa to resort to always opening links in new browser tabs.
Thanks for taking the time to report this! Could you please provide an example link?
As far as my experience goes, this is not related to a specific page; you can consistently reproduce this behavior on any page with collapsible sections. The only thing to note is that this behavior doesn't "activate" if the Back-button is pressed very soon after the navigation. You need to wait a minute or two (I guess depending on non-deterministic circumstances) before navigating Back will cause the previously open sections of the page to be collapsed. This is probably related to how the mobile Safari caches pages, and when it decides to reactivate/reload the JS hooks on a page (which do the collapsing). Also, note that—and this should really be a separate bug report—very often (but not consistently) the scroll state of the previous page is reset after a Back-navigation, i.e. the page is scrolled back to the top. It also seems that it related to the search box at the top of the page—there seems to be some sort of JS auto-scrolling magic in action again because when I activate the search textbox and deactivate it, the problem disappears on subsequent navigate+back operations.
Also, I've verified that this annoyance is also consistently reproducible on Chrome for iOS, with the same characteristics.
(In reply to Erik Allik from comment #2) > As far as my experience goes, this is not related to a specific page; you > can consistently reproduce this behavior on any page with collapsible > sections. On any random website using MobileFrontend? On some Wikipedia in some languages? On all Wikipedias? Or instead on Wikisource and Wiktionary? *Any* steps to reproduce one occurrence would be welcome...
I've observed this on English Wikipedia; I also just checked and the problem appears to be present also on at least the Estonian wikipedia; should be safe to extrapolate that this is the case on Wikipedias of all languages (running the same software version, that is). Just assuming though.
So we talk about https://en.m.wikipedia.org/ , not https://en.wikipedia.org/
Prioritization and scheduling of this bug is tracked on Mingle card https://wikimedia.mingle.thoughtworks.com/projects/mobile/cards/1784
*** This bug has been marked as a duplicate of bug 53308 ***
