Page MenuHomePhabricator

user pref to bypass mobile redirection
Closed, DuplicatePublic

Description

The mobile version of mediawiki is not fully functional, and power users often dont want to be redirected there.

Android Chrome, Android's 'Internet' app, and Android Firefox beta all have a setting to request that the desktop version be served, however I think that is session based only.

MediaWiki Mobile has an option to switch to Desktop, which I read uses a cookie to keep that setting for 30 days. In my experience, this isnt working properly, but I havent had the time to work out why. On Android Google Chrome I consistently switch to Desktop, and I am constantly being redirected to Mobile. maybe the cookies are being cleared inadvertently, such as due to the bug that forces logouts when using multiple devices.

It would be useful to have a permanent setting in mediawiki preferences to allow a user to opt-out of mobile redirection - all browsers, no dependency on cookies (which would mean Orweb works), etc.


Version: unspecified
Severity: enhancement
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49653
https://bugzilla.wikimedia.org/show_bug.cgi?id=46247

Details

Reference
bz57127

Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 2:15 AM
bzimport set Reference to bz57127.
bzimport added a subscriber: Unknown Object (MLST).

bingle-admin wrote:

Prioritization and scheduling of this bug is tracked on Mingle card https://wikimedia.mingle.thoughtworks.com/projects/mobile/cards/1420

  • This bug has been marked as a duplicate of bug 49653 ***

Sorry Jon but I have explained in this bug report why 'request the desktop' is not what I am wanting. It is session based.

(In reply to comment #0)

MediaWiki Mobile has an option to switch to Desktop, which I read uses a
cookie to keep that setting for 30 days. In my experience, this isnt working
properly, but I havent had the time to work out why. On Android Google
Chrome I consistently switch to Desktop, and I am constantly being redirected
to Mobile. maybe the cookies are being cleared inadvertently, such as due to
the bug that forces logouts when using multiple devices.

Jo(h)n: Either this bug report or a separate bug report should focus on this issue. Two separate issues are getting intermingled here:

  • adding a desktop/mobile user preference (non-trivial and probably somewhat controversial) and
  • why the Android Google Chrome can't seem to keep the user preference.

I'd prefer that a new bug be filed to track the user preference feature request.

P.S. More like interbingled, amirite?

(In reply to comment #4)

  • why the Android Google Chrome can't seem to keep the user preference.

Whoops, this is ambiguous. I mean selecting the 'desktop version' link in MobileFrontend. This sets an HTTP cookie, I believe. I should have said "keep/use the cookie", not the user('s) preference.

Android Google Chrome can't seem to keep/use the cookie. Maybe a browser setting? Maybe cross-origin something?

This bug is for the non-trivial and probably somewhat controversial user pref.

I dont have time or interest in why MobileFrontend wants to redirect me to the mobile site all the time. IMO it shouldn't be dependent on browser state/cache, especially if the cookie is cleared every thirty days. I know that people using larger screen devices are also getting annoyed; they don't want the backend determining that they are 'mobile' when they use these devices as their primary work environment.

I think it would help to have a higher level view of the issue: at what level do we want mobile detection to happen and on what should we base whether to auto-redirect (I think we currently use User-Agent, maybe)?

Do we want to keep "en.m.wikipedia.org" and the other 700-plus variations around forever? Does it make sense to fold back into "en.wikipedia.org"? We could have all traffic go to en.wikipedia.org and do mobile detection at a higher level.

Based on the answer to this question, it might be easier to consider possibly adding a user preference. But any user preference is expensive: it adds to user interface clutter and technical debt. So if there's a way to have sane default behavior, we always prefer that.

There are also possible common ground solutions like a hidden user preference. Clicking the link at the bottom could use one of those for persistence, perhaps.

(In reply to comment #7)

Based on the answer to this question, it might be easier to consider possibly
adding a user preference. But any user preference is expensive: it adds to
user interface clutter and technical debt. So if there's a way to have sane
default behavior, we always prefer that.

We have a user pref here, stored in a 30-day cookie afaik. What other prefs are managed this way?

There are also possible common ground solutions like a hidden user
preference.
Clicking the link at the bottom could use one of those for persistence,
perhaps.

That would work for me. I don't mind how the user activates the pref, and should work for most power users, however I think features that completely change the UI deserve a proper user pref to opt-out.

(In reply to comment #8)

There are also possible common ground solutions like a hidden user
preference. Clicking the link at the bottom could use one of those for
persistence, perhaps.

That would work for me. I don't mind how the user activates the pref, and
should work for most power users, however I think features that completely
change the UI deserve a proper user pref to opt-out.

Another possible option: implementing a user script or JavaScript gadget that sets the cookie and/or auto-redirects.

The problem here is the only way to bypass the redirect to my knowledge is to use a cookie. The way the switch to desktop mode is /supposed to work/ is to store a cookie that lives until you switch back to mobile. If this is not working for you( which it seems it isn't) this should be fixed. Having a /user preference/ would make absolutely no difference here - it would need to be implemented in exactly the same way and on a per device basis.

That aside, another way of looking at this bug is that it seems the mobile site is letting you down and we should work hard to make it more fully functional so that you can do the activities you do on desktop on a mobile screen. It would be interesting to know what features you need access to.

There is currently work in the beta that surfaces talk pages, history pages and recent changes for example (all currently with limited functionality)
See:
https://en.m.wikipedia.org/wiki/Special:History
https://en.m.wikipedia.org/wiki/Special:History/San_Francisco
Opt in here: https://en.m.wikipedia.org/wiki/Special:MobileOptions

Yet another way of looking at this is we should fix bug 36636 - we are very close to this and if this was to happen we could theoretically provide a setting that would allow a user to set a skin /for mobile/. Thus a user could choose the Vector skin instead of the mobile skin (called Minerva) yet view it on the m. domain. This would actually be better as I hear the opposite to your request where people want the mobile skin on desktop (usually due to bandwidth issues).

Allowing mobile to be a registered skin will make it possible to change preferences so that the vector skin is loaded on your mobile device. Let's do this instead.

  • This bug has been marked as a duplicate of bug 36636 ***

This wasnt resolved by T38636 , and new dups should be dupped against this much older task id.

Although not quite the same task a user preference would suffer from the same technical constraints. This would need to be done on the Varnish level which is responsible for the redirection.