Last modified: 2013-11-21 21:52:49 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T54536, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 52536 - Can't switch from Zero to desktop
Can't switch from Zero to desktop
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
ZeroPortal (Other open bugs)
master
All All
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-05 01:00 UTC by Max Semenik
Modified: 2013-11-21 21:52 UTC (History)
5 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Max Semenik 2013-08-05 01:00:55 UTC
After answering yes to "Standard data charges may apply. Do you want to continue?" you still get mobile site.
Comment 1 dr0ptp4kt 2013-08-12 22:02:10 UTC
Would you please add some steps to reproduce for production?
Comment 2 Max Semenik 2013-08-15 17:08:38 UTC
Set X-CS e.g. to 250-99, go to mobile site, click on desktop version.
Comment 3 dr0ptp4kt 2013-08-19 17:29:02 UTC
Confirmed. Upon a click on Yes, ZeroRatedMobileAccess normally examines the returnto parameter and sends the user to the URL-decoded version of it. But it seems that either (a) ZeroRatedMobileAccess isn't invoked or (b) something is rewriting its 301 on the fly. Will research.

A forthcoming version of ZeroRatedMobileAccess will also introduce a JavaScript-driven interception of the click, which will allow bypass of any server roundtrip for most UAs. For UAs with poor or nonexistent JS support, I'm not sure what it will mean for this specific case, but we'll need to look into it.
Comment 4 dr0ptp4kt 2013-08-19 23:04:27 UTC
It seems that the onBeforePageRedirect hook implementation in MobileFrontend.hooks.php checks whether the host of the redirect target and the local server are the same.

In that case, it mobile-izes the target URL.

If I understand correctly, because the destination redirect target (the returnto parameter that ZeroRatedMobileAccess uses to redirect()) is en.wikipedia.org and because $wgServer will evaluate to en.wikipedia.org as well, MobileContext::isLocalUrl( $redirect ) will yield a value of true, and thus $redirect will be changed to be a URL with a host of en.m.wikipedia.org via the $context->getMobileUrl( $redirect ) call within the if() ($this>updateMobileUrlHost( $parsedUrl ) and $this->updateMobileUrlQueryString( $parsedUrl ) ).

Does that match your understanding?

It's very hard to troubleshoot this in production, but you can see by visiting http://en.zero.wikipedia.org/w/index.php?title=Main_Page&renderZeroRatedBanner=true&renderwarning=yes&returnto=http%3A%2F%2Fen.wikipedia.org%2Fw%2Findex.php%3Ftitle%3DMain_Page%26mobileaction%3Dtoggle_view_desktop (notice, it's on a ZERODOT subdomain), that upon clicking Yes you get redirected to the MDOT Main_Page.
Comment 5 Max Semenik 2013-08-23 22:02:32 UTC
Yes, and the solution is to lead people directly to the destination upon clicking yes, instead of making them go through a special page for this - that's how MF takes people to desktop.
Comment 6 dr0ptp4kt 2013-08-23 22:06:28 UTC
Okay, looks like this will need to be changed along with the other link rewriting. The solution there will give users direct links in the interstitial / overlay.
Comment 7 Gerrit Notification Bot 2013-10-11 23:44:15 UTC
Change 89366 had a related patch set uploaded by Dr0ptp4kt:
Reinstate interstitial warning for switch to Desktop. See bug 52536.

https://gerrit.wikimedia.org/r/89366
Comment 8 Gerrit Notification Bot 2013-10-13 09:23:59 UTC
Change 89366 merged by jenkins-bot:
Reinstate interstitial warning for switch to Desktop. See bug 52536.

https://gerrit.wikimedia.org/r/89366
Comment 9 dr0ptp4kt 2013-10-23 19:48:20 UTC
The patchset didn't result in an interstitial'd link that gets the user to Desktop. We'll work on another patch. The current patch merely ends up with the user getting a 404 when clicking 'Yes' from the interstitial, like before. This is actually preferable to the user being charged without warning, but it's still not ideal, so this is in the active work queue.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links