Page MenuHomePhabricator

API responses gives desktop site's links for "Read in another language", "notifications" and "MediaViewer" details link
Open, Stalled, HighPublic

Description

Language

In the language overlay the links generated are desktop links instead of .m. ones. And it won't automatically jump to mobile site either.

Mediaviewer

In the mediaviewer overlay a similar problem:
Visit https://en.m.wikipedia.org/wiki/Book#/media/File%3ABook_Collage.png and click on the "Details" button. You'll be taken to https://commons.wikimedia.org/wiki/File:Book_Collage.png#mw-jump-to-license.

Expected: You should be taken to https://commons.m.wikimedia.org/wiki/File:Book_Collage.png#mw-jump-to-license

Echo

Steps to reproduce:

  1. Wait for a mention from user on some wiki
  2. Go to that wiki on mobile phone browser and login
  3. Tap the bell icon
  4. Tap that new unread mention

Expected behavior:
Link leads to mobile view page.

Current behavior:
Link opens desktop view page instead.

Related: T107108

Details

Reference
bz65047

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

Dropping from sprint @dr0ptp4kt per stalled status and https://phabricator.wikimedia.org/T67047#1850561 - this is not actionable at current time. Was the idea to have a spike around this?

For ResourceLoader capable UAs, would it be possible to use JavaScript to understand the current mode and conditionally rewrite the domain name or change it on item tap?

This would get very messy and hacky as it would require assuming that all mobile sites are on the m domain which is simply not true.

For ResourceLoader incapable UAs, or UAs that end at the HTML language switcher, it looks like Special:MobileLanguages already in practice keeps the user on the mdot subdomains.

mm.. it does seem that way (it didn't used to) - it would be worth exploring how this is working and see if we can use it in the API.

I'll add to sprint at the bottom of in analysis in case we have time in kick off to discuss and write a spike for the above, although given we have 3 minutes per story I'm not optimistic we'll cover this :)

Jdlrobson added a subscriber: Anomie.EditedFeb 1 2016, 9:47 PM

I looked into this:
Special:MobileLanguages explicitly calls MobileContext::singleton()->getMobileUrl
@Anomie is it possible to mixin to existing API functions?
e.g. could MobileFrontend add a parameter mobile: true to the langlinks query which when enabled transforms/appends to the URLs in langlinks ?
Example query:
https://it.m.wikivoyage.org/w/api.php?action=query&format=json&meta=siteinfo&siprop=general%7Clanguages&prop=langlinks&llurl=true&lllimit=max&titles=Italia&formatversion=2

Proposed new query:
https://it.m.wikivoyage.org/w/api.php?action=query&format=json&meta=siteinfo&siprop=general%7Clanguages&prop=langlinks&llurl=true&lllimit=max&titles=Italia&formatversion=2&mobile=1

Anomie added a comment.Feb 2 2016, 2:55 PM

This is why mobile support should be merged into core instead of having an extension that tries to hack up all of MediaWiki. Then "getMobileUrl" wouldn't be needed at all because all the URL-generating methods would be able to just do the right thing in the first place based on whether it's it.wikivoyage.org or it.m.wikivoyage.org.

Also, llurl is deprecated. You should be using llprop=url now.

Also, llurl is deprecated. You should be using llprop=url now.

Already done in 106467b7aff396f55f5f5fccf402be5d7e02922e.

@Anomie sure but that is a different question to what i asked... :)
It could be any extension - I'm just keen to know if there are any examples of extensions can extend API modules functionality.

(But while on the subject it feels like you are contradicting what you said on T100402 - I felt like you were against moving this stuff to core - so if you're not it would be great for you to clarify your position there so we can actually do that)

Anomie added a comment.Feb 2 2016, 5:04 PM

@Anomie sure but that is a different question to what i asked... :)
It could be any extension - I'm just keen to know if there are any examples of extensions can extend API modules functionality.

In something like this, not terribly easily. It would need either adding hooks or horrendous hacks like what MobileFrontend does to ApiParse.

(But while on the subject it feels like you are contradicting what you said on T100402 - I felt like you were against moving this stuff to core - so if you're not it would be great for you to clarify your position there so we can actually do that)

What I said there was

  • MobileContext::getMobileUrl moved to ContextSource

I still hate the idea of this method, and reiterate that it would be much better if stuff would just automagically generate the correct URL in the first place.

Note I want mobile support in core, but not necessarily what MobileFrontend currently does. If we make a completely responsive site we won't even need to worry about different URLs, and if we do have to have different URLs then it would be better for the URL-generation methods to handle it instead of making everything everywhere call some hacky URL-mangling function.

Jdlrobson added a comment.EditedFeb 4 2016, 8:10 PM

Thanks @Anomie for your clarifications.
I guess the cleanest thing to do in the interim would be to create a new Api that extends the existing one but adds the mobile URL to responses or find some way to format the URL in JavaScript (yuk)?

Given varnish handles redirects, @dr0ptp4kt I think this is not worth the effort and my advice would be to decline this bug.

Unfortunately, it doesn't redirect desktop users who prefer the mobile site, even if they used the footer "Mobile view".

Additionally, every use of the JavaScript based feature even on mobile devices is adding an unnecessary request directed at the Varnish edge (I believe 301s are cached, though - @BBlack, please let us know).

From a functionality perspective, this isn't urgent, because as you note, it works. But we should still get a fix in at some point and stop having the extra network request. Although I'm unsure, a fix may also help in more accurate intra-site "internal" Referer analysis for Hive's "internal" / "external" / "unknown" field. @Nuria, can you comment on the "internal" / "external" / "unknown" counts values and how the impact of an intervening HTTP status code 301 plays into our calculations when both the 301 and the redirected resources (which is a 200) are on our domains?

Jhernandez lowered the priority of this task from High to Normal.May 25 2016, 4:14 PM
Jhernandez moved this task from Incoming to Needs Prioritization on the Readers-Web-Backlog board.

@dr0ptp4kt @Jdlrobson During grooming it was thought that maybe this task is not worth doing. If you feel otherwise, could you describe what needs to happen next?

I would prefer that @ovasileva provide guidance on prioritization. This said, as this only impacts ResourceLoader-capable UAs, I wonder if one option is when the user is on mobile web Wikipedia, with JavaScript intercept the click and and change the domain name before changing window.location; of course not breaking any instrumentation so long as instrumentation continues to be in place on this workflow. That's not a robust option for other sites, but deals with the lion's share of traffic.

@dr0ptp4kt - I think that's a good suggestion (and potentially worthwhile). I don't see immediacy, however, so lowering the priority.

ovasileva lowered the priority of this task from Normal to Low.Oct 3 2016, 1:41 PM
Nuria removed a subscriber: Nuria.Jan 30 2017, 4:33 PM

I'm not sure to get the idea behind lowering that task and stalling it: there is a big bunch of mobile readers who are impacted, no?

Regardless it's stalled so priority doesnt mean much. Mobile readers are impacted in the sense we unnecessarily redirect them but they still end up in the right place.

they still end up in the right place.

I don't think so. They end up on desktop page and without knowledge of the foreign language they can not switch to mobile version easily.

they still end up in the right place.

I don't think so. They end up on desktop page and without knowledge of the foreign language they can not switch to mobile version easily.

{{support}} :)

I'm not sure to get the idea behind lowering that task and stalling it: there is a big bunch of mobile readers who are impacted, no?

@Dvorapa, @Trizek-WMF - This would only impact two groups of users:

  • mobile users who are using the desktop site in mobile - a behavior we would not necessarily like to promote, as it is not the optimal user experience
  • desktop users who use the mobile site on desktop - here it is a somewhat larger issue, as these users have specifically chosen to use mobile

We do have some options on fixing this although they would be somewhat time-consuming. Since both of the above cases are fairly rare, we're not considering this task to be high priority as of now.

@ovasileva, @Jdlrobson Please see T156578, which was closed as a duplicate of this. There is a third group of users: mobile users who are using the mobile site

fireattack added a comment.EditedFeb 1 2017, 5:16 PM

I didn't get it. What's the difference between T156578 and this one? Isn't it exactly the same bug? Why reopen that and keep this (firstly-reported) one as low & stalled?

fireattack added a comment.EditedFeb 1 2017, 5:25 PM

Also I did a quick test on cs.wiki (with an Android phone). It can redirect to correct mobile views of other language version of Wikipedia just fine (no idea how the reporter there has successful rate of only 10%).

The major problem today (since bug 66888 has been fixed) IMO, as I and @Jdlrobson stated in 2014,

Despite the existence of bug 66888, this implementation (rely on redirection) itself is questionable. Some developers commented above said "you should avoid using hard link blabla", but we already use hard mobile link for interlinks everywhere so this statement makes little sense for me.

Actual behaviour:
On a mobile device, clicking them does take you to mobile, but via 2 HTTP requests rather than 1.
On a desktop device you are taken to desktop site rather than being kept in mobile skin/site.

is that the current implementation will have 2 http requests, rather than one, which feels kinda unnecessary.

@fireattack I've commented on the bug for clarification but I'm pretty sure it's the same. The behaviour however can depends on the browser and user's behaviour.

Anyway, I'm not disagreeing it's an annoying bug, I'm just pointing out we don't know how to fix it... this bug has been open since 2013 I think. I've opened T156847 to try and push this through the developer wishlist to find a generic solution. Fingers crossed.

Jdlrobson renamed this task from "Read in another language" gives desktop site's links to API responses gives desktop site's links for "Read in another language" and "MediaViewer" details link.Apr 17 2017, 4:06 PM
Jdlrobson updated the task description. (Show Details)
Jdlrobson updated the task description. (Show Details)
Jdlrobson added subscribers: Steinsplitter, Poyekhali.
Jdlrobson raised the priority of this task from Low to High.May 3 2017, 3:29 PM
Jdlrobson added a subscriber: Vachovec1.

This seems to hit a lot of users, so I don't think a low is justified here but this remains blocked on T156847

Jdlrobson added a subscriber: Tgr.May 3 2017, 3:31 PM

There has been a little bit of action in T156847

Jdlrobson renamed this task from API responses gives desktop site's links for "Read in another language" and "MediaViewer" details link to API responses gives desktop site's links for "Read in another language", "notifications" and "MediaViewer" details link.Jul 13 2017, 5:39 PM
Jdlrobson moved this task from Backlog to Tracking on the MobileFrontend board.
Jdlrobson updated the task description. (Show Details)

I don't know if it has been already highlighted but I've just noticed that also the interwikilink goes to the desktop version.

Look at https://it.m.wikivoyage.org/wiki/Firenze#Cosa_vedere in particular at the end of each item listed there, there's the Wikipedia icon that is a link Wikipedia and the first one for example is:
https://it.wikipedia.org/wiki/Basilica_di_Santa_Maria_Novella
instead of
https://it.m.wikipedia.org/wiki/Basilica_di_Santa_Maria_Novella

@ovasileva Didn't you claim the duplicate task I created? So maybe you can work on this one?

Elitre removed a subscriber: Elitre.Sep 17 2019, 4:54 PM