enable mobile redirect broken (Certain iOS users getting served desktop site - reports of mobile view not sticking)
Closed, ResolvedPublic


Author: davidtyorke

iPhone 4, iOS 5.0.1
After switching to desktop view on a Wikipedia mobile page I am no longer redirected to the mobile Wikipedia from other sites (e.g.: google search results). (Side note: is this desirable behavior?)

Clicking on the "Mobile Version" link at the bottom of an article doesn't permanently re-enable the mobile redirect. neither does clicking the link on the "Enable Mobile version" page. http://en.wikipedia.org/wiki/Wikipedia:Enable_mobile_version

There is a overly complacated fix on the Enable Mobile Version talk page which points to a recent regression in Mediawiki. http://en.wikipedia.org/wiki/Wikipedia_talk:Enable_mobile_version

Version: unspecified
Severity: major
URL: http://en.wikipedia.org/wiki/Wikipedia:Enable_mobile_version


bzimport set Reference to bz38009.
bzimport added a subscriber: Unknown Object (MLST).
bzimport created this task.Jun 27 2012, 9:57 PM

davidtyorke wrote:

I hope my changes are helpful. please let me know. Thanks.

Thanks Dave. We are looking into this.

There have also been lots of reports on Twitter and I can replicate the problem and noise in the feedback forms. Maybe Arthur Richards can take a look at this when he returns Friday.

4th of july....

I added a script to take care of this highly annoying problem, since it's been a production problem for 2,5 months now.


mediawikibugzilla wrote:

I'm still seeing the problem in Mobile Safari (iPhone 4S running iOS 5.1.1).

Prepare to reproduce this problem:

  1. Clear all cookies: 1a. Force Safari closed (http://support.apple.com/kb/ht5137); this is important because Safari keeps a copy of cookies in memory while it's open and in the background; the Settings app only edits the persistent cookie storage. 1b. Open the Settings app 1c. Scroll down and tap on "Safari" 1d. Tap on "Clear Cookies and Data" 1e. Approve the action by tapping the "Clear Cookies and Data" button
  1. Press the home button then start Safari
  2. Tap Safari's address bar, type "en.wikipedia.org" and press "Go"
  3. Notice that Wikipedia redirects your browser to "en.m.wikipedia.org"

Now we're ready to reproduce/cause the problem:

  1. Scroll to the bottom of the page, expand the "WikipediA more" section and tap on the "Desktop" link.
  • At this point, the toggle_view_desktop parameter to index.php causes Wikipedia to set the "stopMobileRedirect=true" cookie with an expire date six months in the future and that "locks" the mobile browser to the Desktop version of Wikipedia because the cookie is quite difficult to unset.
  1. Scroll to the bottom of the desktop version of en.wikipedia.org that you'e viewing and tap on the "Mobile" link.

    This takes you to the mobile version of the home page as expected, but the stopMobileRedirect cookie remains true (even with the new MediaWiki:common.js click handler; apparently Safari ignores the null cookie).
  1. To demonstrate the problem, either search Google for something that points back to Wikipedia or enter the url "en.wikipedia.org". In either case, the user expects to return to the mobile view as that's what they last saw in the step above.

mediawikibugzilla wrote:

If it helps, here are a bunch of common.js experiments

The simplest working javascript I found was this:


document.cookie = 'stopMobileRedirect=false; domain=.wikipedia.org;'
                + 'path=/; expires=Thu, 01-Jan-1970 00:00:00 GMT;'

Unfortunately, none of my attempts succeeded using $.cookie().

Thanks for all the contributions - and nice hacks! I was going to suggest that we add some javascript to delete the cookie when the 'Mobile view' link gets clicked. This could be added to the MobileFrontend code so it gets loaded on the desktop version of the site via ResourceLoader.

The code that was added to common.js does not appear to be working, at least for me. In fact, it looks like it's setting an additional cookie, which is really just going to cause more problems for people. I didn't dig into this too deeply but I suspect it's because the path and/or domain of the cookie being set in common.js does not match that of the initially set stopMobileRedirect cooki. I made some quick modifications and this appears to work (from User:Awjrichards/common.js):

mw.loader.using( 'jquery.cookie', function() {

    $.cookie( 'stopMobileRedirect', false, 'Thu, 01-Jan-1970 00:00:00 GMT', '/' );


There have been a number of changes in MobileFrontend that negatively affected how the toggling cookies work, plus we've had extra complications with the cluster's caching infrastructure. But the solution you all came up with is pretty much exactly what I would've done - now let's just get it into MobileFrontend! Are any of you interested in making a patch to get this little bit of js loaded on the desktop view? This will help alleviate problems for the other sites as well.

I apologize that this is something that has gone unfixed for so long - we've had our hands full with other work that has been given higher priority and we have not had the chance to get this resolved. But for me, this shows how awesome the project and open source software in general is. It was broken, and you fixed it :)

mediawikibugzilla wrote:

I add your code to [[w:User:Mwarren_us/common.js]], however, it does not solve the problem under iOS 5.1.1 either. For some reason, all variants of $.cookie() running under iOS 5.1.1 fail to unset the stopMobileRedirect cookie; only directly setting document.cookie seems to get the job done. I've attached a version of Common.js with the fix that works in my testing.

mediawikibugzilla wrote:

MediaWiki:Common.js with code to unset stopMobileRedirect cookie in iOS

Since this fix does not need jQuery.cookie, I also removed the mw.loader.using() wrapper.

attachment Common.js ignored as obsolete

mediawikibugzilla wrote:

2nd version of iOS stopMobileRedirect cookie fix - follow Quirksmode advice...

Quirksmode (http://www.quirksmode.org/js/cookies.html#document.cookie ) says that document.cookie strings need to follow a strict format - this version of Common.js follows that.

attachment Common.js ignored as obsolete

mediawikibugzilla wrote:

The latest version of MediaWiki:Common.js worked for me.


Quick tests on my end look good with android 4.0.4. I think this fine to live in common.js for the short term, but we should get this into MobileFrontend as well. Mark, are you interested in trying to take that on with some support from the mobile team?

mediawikibugzilla wrote:

Change stopMobileRedirect cookie using $.cookie() function.

Finally found a way to call $.cookie() that works on iOS 5.1.1. This version of uses $.cookie() to change stopMediaRedirect to false but does not try to remove/expire the cookie.

Attached: Common.js

mediawikibugzilla wrote:

Suggested patch to MobileContext.php

I don't have a sandbox area to test this suggestion for MobileContext.php (https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/MobileFrontend.git;a=blob;f=MobileContext.php;h=8c768a14ab52922825c55ac379f9c79b64d382b6;hb=HEAD ), so please take it with a grain of salt. The PHP change tries to do something similar to the javascript workaround: set stopMobileRedirect to false as well as use a date in the past.

attachment MobileContext.php.patch ignored as obsolete

mediawikibugzilla wrote:

(In reply to comment #11)

Mark, are you interested in trying to take that on with some support from
the mobile team?

Sure, I can take a crack at that. Pointers about where to start reading about the MobileFronted maintenance process would be welcome. Thank you!

sumanah wrote:

Mark, you might also want to check out https://www.mediawiki.org/wiki/Git/Tutorial so you can more easily submit future patches directly into our source control system. Thanks!

Mark, thanks for taking a crack at it!

What I can tell you real quick now is that there is already good cookie setting/unsetting code in PHP in MobileFrontend, as well as in some Javascript which loads only for the mobile version of the site. The problem is, due to the cluster's caching infrastructure, there are issues unsetting the stopMobileRedirect cookie on the server side (in PHP). We should instead take the solution you refined in common.js on en.wikipedia and have MobileFrontend load that bit of javascript on the desktop version of the site. This will require using resource loader (http://www.mediawiki.org/wiki/ResourceLoader) and ensuring that it only gets loaded for non-mobile page views. It's not very clear in the code, but the decision about whether or not to show the mobile version of the site gets made in ExtMobileFrontend::requestContextCreateSkin().

I hope that's enough to get you started - I'll help dig in deeper later when I have some more time, likely this weekend or early next week.

  • Bug 37308 has been marked as a duplicate of this bug. ***

Comment on attachment 10979
Suggested patch to MobileContext.php

This will not work on the WMF infrastructure. A better solution would be to take the JS used in common.js and place it into a ResourceLoader module that gets added in MobileFrontend.

  • Bug 36734 has been marked as a duplicate of this bug. ***

I believe https://gerrit.wikimedia.org/r/#/c/25596/4 should fix this. When the changes get merged, I'd like to enable the changes on a single wiki (maybe mediawiki.org?) to test for a week to ensure this fully resolves the issue before pushing out everywhere since we don't really have the ability to test the efficacy of this change for the production cluster outside of the production cluster, unless someone else has a better testing strategy. The next MobileFrontend deployment is scheduled for the upcoming Tuesday, hopefully we'll get this out then.

PS big thanks to everyone who's been helping with this - I basically took the JS that's being used on enwiki in common.js and integrated it with MobileFrontend to get loaded on the desktop version of the site.

This fix has now been deployed to simple.wikimedia.org, and appears to be working for me. Can folks who've been experiencing this issue please test there and report back your findings? If everything looks OK, we can push the change out everywhere on the cluster next week.

jakobunt wrote:

For other testers, I think http://simple.wikipedia.org/ was meant.
And it works for me there!

Whoops, thanks Jakob - you're correct!

Dave, Derk, Mark - can you please test this on simple.wikipedia.org and confirm if the problem is resolved there?

This is also confirmed working with ios6, android 4.1.1, android 2.3.6 (stock, opera mobile, opera mini)

This has now been deployed everywhere.

Add Comment