Page MenuHomePhabricator

Delayed redirect from main site for mobile users (1.17 regression)
Closed, ResolvedPublic

Description

Author: hcatlin

Description:
The mobile redirect script loads FAR after the rest of the page.

So, on the iphone, even the images in the page (after initial render) finish loading
before the redirect happens.

I have modified the redirect script to be MUCH, MUCH smaller and easier to compress.

After putting the new JS through the http://closure-compiler.appspot.com/home compiler. It ends up being like:

if(/(iPhone|iPod|Android.*Mobile|webOS|NetFront|Opera Mini|SEMC-Browser|PlayStation Portable|Nintendo Wii|BlackBerry)/.test(navigator.userAgent))if(document.cookie.indexOf("smr=t")<0&&wgNamespaceNumber>=0&&wgAction=="view"){if(wgPageName!=wgMainPageTitle.replace(/ /g,"_"))wgWikimediaMobileUrl+="/"+encodeURI(wgPageName);document.location=wgWikimediaMobileUrl};

That might work embedded. And we can certainly shorted the Regex to match with less bits.

However, you can solve this a more traditional way, if you like. ;)

-hampton.


Version: unspecified
Severity: major

Details

Reference
bz27690

Event Timeline

bzimport raised the priority of this task from to High.Nov 21 2014, 11:33 PM
bzimport set Reference to bz27690.

hcatlin wrote:

I'm upgrading this one. Right now, the mobile site experience is seriously degraded. We need a quick fix for this in soon....

On a 3G connection, you wait 15 seconds for the page to fully load... and by that point you are already reading it, when... POP... it redirects you and you have to wait again. :P

A terrible experience.

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

bugzilla.wikimedia.org wrote:

May I *strongly* suggest that you do not use JavaScript to perform the redirection. Any device detection should be done server-side.

Many mobile phones - especially those in the developing world - don't have JavaScript, or have non-compliant implementations, or have it switched off for performance reasons.

Even if a device does use JS, it still has to load the entire page of HTML which for many people will be a slow and costly experience. If people are paying per MB on a GPRS connection, they will not get a great experience.

Best practice would be to use a service like DeviceAtlas (http://deviceatlas.com/) or WURFL (http://wurfl.sourceforge.net/) to parse User Agent strings on the server, then 302 redirect them.

Alternatively, an .htaccess modification would work as well.

I don't know enough about Wikimedia architecture to know which is the best in this case. What I do know is relying on client-side redirection is not safe.

(In reply to comment #4)

May I *strongly* suggest that you do not use JavaScript to perform the
redirection. Any device detection should be done server-side.

Many mobile phones - especially those in the developing world - don't have
JavaScript, or have non-compliant implementations, or have it switched off for
performance reasons.

Even if a device does use JS, it still has to load the entire page of HTML
which for many people will be a slow and costly experience. If people are
paying per MB on a GPRS connection, they will not get a great experience.

Best practice would be to use a service like DeviceAtlas
(http://deviceatlas.com/) or WURFL (http://wurfl.sourceforge.net/) to parse
User Agent strings on the server, then 302 redirect them.

Alternatively, an .htaccess modification would work as well.

I don't know enough about Wikimedia architecture to know which is the best in
this case. What I do know is relying on client-side redirection is not safe.

See bug 24859

hcatlin wrote:

Lets not get distracted from the immediate issue here... we have a broken mobile site...

Its been broken now for 8 days!

-hampton.

This has already been mentioned in a couple of places but I'm adding it to the bug for thoroughness.

@Hampton: According to Trevor we need to modify the startup js file in order to get the redirect to happen early. The file in question is http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/resources/startup

We need you to coordinate with Trevor to find out how to combine the extension WikimediaMobile with this.

Long term we are still blocked on http://rt.wikimedia.org/Ticket/Display.html?id=196 for server side redirection.

(In reply to comment #7)

This has already been mentioned in a couple of places but I'm adding it to the
bug for thoroughness.

@Hampton: According to Trevor we need to modify the startup js file in order to
get the redirect to happen early. The file in question is
http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/resources/startup

We need you to coordinate with Trevor to find out how to combine the extension
WikimediaMobile with this.

I've live-hacked this, should be fixed now.

Long term we are still blocked on
http://rt.wikimedia.org/Ticket/Display.html?id=196 for server side redirection.

RT isn't public, only people who have an account there (certain WMF staff) can read tickets.

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