Go to http://en.m.wikipedia.beta.wmflabs.org/wiki/0.28647961229659646#/notifications and click the close button.
Expected behavior: The overlay closes and you see the article.
Actual behavior: Your browser goes back to the previous page that was loaded before.
Version: unspecified
Severity: enhancement
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=65041
https://bugzilla.wikimedia.org/show_bug.cgi?id=67639
bingle-admin wrote:
Prioritization and scheduling of this bug is tracked on Mingle card https://wikimedia.mingle.thoughtworks.com/projects/mobile/cards/1666
jgonera wrote:
If you type that link directly in the browser then unfortunately that's what will happen. It basically goes to the previous item in browser's history.
To be fair that's how the web works... not sure we should complicate things by trying to change that. I'd suggest this is a WONTFIX...
If you followed a link to the editor from twitter would you expect back to take you to the article or back to the tweet on twitter? probably the latter.
If we're going to treat overlays as pages rather than overlays, the interface should reflect that. In other words, we should be using back arrows instead of close 'x's. Otherwise the behavior is confusing.
I suppose my first question is this: Is it implemented as an overlay, or as a new page?
If it's a 'true' overlay, then it should just dismiss. However, it sounds like it's handled as a whole page, in which case I should think it behaves like a page (and thus would have an arrow rather than a close).
In the future especially for tablet we'll treat them more as overlays - notifications will look more like it does on desktop. On desktop if you open notifications, then click back, you're taken to the previous page - because you can still see the current page underneath. I think it should behave the same way on mobile.
kwang wrote:
Yes I would expect it to close the notifications so you can see the article.
After discussing this with Juliusz, Kenan, Max, Arthur and Ryan we agreed that we would not break the web and that each URL would be treated as a separate identity. If a page links to the issues on an article we should load the issues for that article and clicking back should take them to the page that linked to it.
We are not willing to jeopardize the back button behaviour in the normal case.
We will revisit this if we get any complaints which bring new light to this. Currently it is only a minor inconvenience.
Previously closed with https://phabricator.wikimedia.org/T62848#655232 as the rationale.
@Niedzielski @ovasileva not sure if you want to re-ignite this conversation. We could add special handing for this case but I'm not sure it's worth the work. Also something to think about for Marvin (cc @Jhernandez )