Page MenuHomePhabricator

Can't switch from Zero to desktop
Closed, ResolvedPublic


After answering yes to "Standard data charges may apply. Do you want to continue?" you still get mobile site.

Version: master
Severity: normal



Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 1:52 AM
bzimport added a project: ZeroPortal.
bzimport set Reference to bz52536.
bzimport added a subscriber: Unknown Object (MLST).

Would you please add some steps to reproduce for production?

Set X-CS e.g. to 250-99, go to mobile site, click on desktop version.

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.

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 and because $wgServer will evaluate to 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 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 (notice, it's on a ZERODOT subdomain), that upon clicking Yes you get redirected to the MDOT Main_Page.

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.

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.

Change 89366 had a related patch set uploaded by Dr0ptp4kt:
Reinstate interstitial warning for switch to Desktop. See bug 52536.

Change 89366 merged by jenkins-bot:
Reinstate interstitial warning for switch to Desktop. See bug 52536.

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.