608415 - redirect mozilla.com to mobile site when a user visits with a mobile browser

Status: RESOLVED FIXED

(www.mozilla.org :: General, defect)

Description

[Chris Beard]

right now when you visit mozilla.com from a mobile browser it doesn't provide you a mobile friendly version of the site.  there's working going on in bug 584905 to make our web sites more mobile friendly, but it's looking like that is going to take a few months months to complete.

that being the case, we should consider adding a simple redirect from mozilla.com/firefox.com to mozilla.com/m

this would be an immediate and short-term fix, but would dramatically improve the experience when visiting our web sites from a mobile browser
in particular, you would no longer be happily offered the *desktop* version of Firefox for Linux when you visit with an Android phone

Comment 1

[Alex Buchanan [:abuchanan]]

In order to do this, we need detection that we can count on being correct.  That's non-trivial and it could take a while to research/evaluate/implement.  

It's certainly shorter term than making our whole website mobile friendly (bug 584905), but it's not exactly immediate either.

Comment 2

[Michael Morgan [:morgamic]]

http://mobiforge.com/developing/story/lightweight-device-detection-php

Comment 3

[Michael Morgan [:morgamic]]

Alternatively we could just use a rewritecondition in apache to search for android if that's the big concern.

Comment 4

[Dave Miller [:justdave]]

As an owner of an Android device, I personally hate being forced to a mobile site because they're often designed for devices with incapable browsers and my phone's capable of using most of the real site anyway.  That said, I like having the option, especially when the main site uses complicated flash stuff that makes life miserable on a smaller screen even if you can see it.  My favorite sites with mobile sites are the ones that automatically redirect you to the mobile site the first time you hit it, but have a link back to the full site on them, which when clicked sets a cookie that prevents you from being redirected back to the mobile site again.

Comment 5

[Dave Miller [:justdave]]

The link with a cookie option also makes the site tolerable for people whose desktop browsers are mis-detected as a mobile device.

Comment 6

[Alex Buchanan [:abuchanan]]

(In reply to comment #3)
> Alternatively we could just use a rewritecondition in apache to search for
> android if that's the big concern.

I was assuming this meant *all* mobile devices.  If it's specific to Maemo/Android, that's likely a lot easier, and actually, that's probably a good place to start, just to get something running.

Comment 7

[Caitlin Looney]

> http://mobiforge.com/developing/story/lightweight-device-detection-php

This is what I sent to you this AM. Know anyone or anything about this service?
I'd like to lock down extra support for Alex and team asap. In the meantime,
I'd like to nail down this short-term fix that cbeard's proposing.

Comment 8

[Chris Beard]

Attachment: detect mobile browser and redirect js script

here's a script that when added to the top of mozilla.com would redirect mobile browsers to mozilla.com/m

this seems to work on my test setup (http://people.mozilla.com/~cbeard/608415/), but i've heard that we might have already tried this and it didn't work for some reason

attaching to the bug as a proof of concept

source: anant narayanan ([e-mail]) and the friendly folks over at http://detectmobilebrowser.com/

Comment 9

[Chris Beard]

why wouldn't this work?

Comment 10

[Michael Morgan [:morgamic]]

Why don't we just put that up on mozilla.com and see what happens?

Comment 11

[Michael Morgan [:morgamic]]

Let's just throw that out and see how it works.  I'll push it TODAY!!!

Comment 12

[Michael Morgan [:morgamic]]

Attachment: v1, adds mobile redirect to js group

Here's a patch for trunk.  Some questions:
- what do we do about mobile vs. non-mobile modality
- how would we persist user state and/or preferences
- what should the overall experience be for other pages (that aren't key landing pages)
- what's the complete end-to-end UX for a desktop user? hmmm.
- what's the complete end-to-end UX for a mobile user? hmmm.
- how will this affect the new design
- what happens if it's wrong
- what about dave's concern

If you guys okay not answering those questions, we can just push this and see what happens.  Otherwise, we might need someone with the right skillset to flesh out the overall user experience.  Storyboarding all this with a UX engineer probably wouldn't hurt; not sure if it's been tried yet.

Comment 13

[Alex Buchanan [:abuchanan]]

Comment on attachment 487094 [details] [diff] [review]
v1, adds mobile redirect to js group

If I understand correctly, this only needs to happen on the home page.  This patch would apply to every page.

Comment 14

[Michael Morgan [:morgamic]]

Attachment: v2, affecting only front page

Comment 15

[Alex Buchanan [:abuchanan]]

Comment on attachment 487099 [details] [diff] [review]
v2, affecting only front page

better, but since it's a redirection script, it should be the first thing to run.  Currently it's in the footer, where it'd be run only after loading the whole page.

Comment 16

[Michael Morgan [:morgamic]]

That's why it's probably better in apache or php.

Comment 17

[Alex Buchanan [:abuchanan]]

(In reply to comment #16)
> That's why it's probably better in apache or php.

Agreed.  We'd have to do it in Zeus though, to avoid the scenario where a request never hits the webheads because of the Zeus cache.

Comment 18

[Michael Morgan [:morgamic]]

Sigh.

Comment 19

[Alex Buchanan [:abuchanan]]

(In reply to comment #17)
> (In reply to comment #16)
> > That's why it's probably better in apache or php.
> 
> Agreed.  We'd have to do it in Zeus though, to avoid the scenario where a
> request never hits the webheads because of the Zeus cache.

Luckily zeus's trafficscript is pretty straightforward and we could convert the JS regex to zeus pretty easily I think

Comment 20

[Alex Buchanan [:abuchanan]]

(In reply to comment #19)
> (In reply to comment #17)
> > (In reply to comment #16)
> > > That's why it's probably better in apache or php.
> > 
> > Agreed.  We'd have to do it in Zeus though, to avoid the scenario where a
> > request never hits the webheads because of the Zeus cache.
> 
> Luckily zeus's trafficscript is pretty straightforward and we could convert the
> JS regex to zeus pretty easily I think

I'll just reply to myself 10 times, don't mind me :)

Also, doing it in Zeus would avoid any perf hit to desktop browsers that load that JS file and don't need it.

Comment 21

[Michael Morgan [:morgamic]]

What do we do for locale redirects?  Those aren't cached, right?

So if we cover the case were someone literally types in "mozilla.com" we could modify bootstrap and use a php regex since the l10n redirects don't get cached.

Comment 22

[Michael Morgan [:morgamic]]

So... js is out.  Zeus, Apache or PHP are in.  That leaves us with:
- Zeus: create custom traffic script to handle established regexes
- Apache: RewriteCond on user agent leading to a redirect, called before any other rules 
- PHP: modify bootstrap to supercede l10n redirects with UA detection

Comment 23

[Michael Morgan [:morgamic]]

Zeus: super fast, but won't be testable on dev or stage?
Apache: pain to maintain but fast and easy to deploy via .htaccess
PHP bootstrap: easier to maintain, potential to switch out with wurfl later but may require not caching content, which is bad for perf

Comment 24

[Alex Buchanan [:abuchanan]]

(In reply to comment #21)
> What do we do for locale redirects?  Those aren't cached, right?
> 
> So if we cover the case were someone literally types in "mozilla.com" we could
> modify bootstrap and use a php regex since the l10n redirects don't get cached.

Locale redirection happens in PHP.  It avoids the cache because if we're detecting a locale, we're on a URL that doesn't have content and therefore has never been cached.  

Yes, we could cover the case where someone doesn't have a locale yet, in PHP.  That doesn't cover someone clicking 'www.mozilla.com/en-US/' in Google search results.

Speaking of Google search results, I'd want to make sure this doesn't recognize any spiders as a mobile device.  That could have really bad impacts on our search ranking/content.

Side note, if we end up doing this in Zeus, we should keep in mind that dev setups don't have Zeus but need to act the same way, so we'd need a PHP version too.

Comment 25

[Michael Morgan [:morgamic]]

Well, that's a buzzkill.  Would be nice if we could solve it with a 1-line JS patch.

Comment 26

[Alex Buchanan [:abuchanan]]

At one point, I toyed with the idea of using Vary + a custom platform header.  For example, a Zeus trafficscript does some platform detection, and sets a custom header like 'X-Moz-Platform: Windows'.  Then, we Vary on that header, which has a small, finite set of possible values.

* Varying on User-Agent doesn't work.  With the variety of UAs out there, it would make our cache ineffective.  Varying on a custom header narrows that down.
* It would keep the redirect logic and any other platform handling code on the server, in PHP.  Good for maintenance.
* It would be easy to fake this header for dev setups.
* It would have the side benefit of improving our download button code.

I never really tested this, so it's still just a random idea, but I figured I'd throw it out there.

Comment 27

[Michael Morgan [:morgamic]]

Alex - what's the ETA on a traffic script, then?  Jeremy, is this something you could help with?

We want to be able to take https://bugzilla.mozilla.org/attachment.cgi?id=487060 and do it with Zeus.

Comment 28

[Jeremy Orem [:oremj]]

We are already running this:


$ua = http.getHeader("User-Agent");

$os_windows = 'windows';
$os_mac = 'mac';
$os_mac_osx = 'macosx';
$os_linus = 'linux';
$os_solaris = 'solaris';
$os_other = 'other';
$os = $os_other;

if (string.find("Win32", $ua) != -1 || string.find("Win64", $ua) != -1)
  $os = $os_windows;
else if (string.find("Linux", $ua) != -1)
  $os = $os_linux;
else if (string.find("Mac OS X", $ua) != -1)
  $os = $os_macosx;
else if (string.find("MSIE 5.2", $ua) != -1)
  $os = $os_macosx;
else if (string.find("Mac", $ua) != -1) {
  $os = $os_mac;

  # Special case for Opera on OS X emulating IE (bug 402113)
  if ((string.find("Opera", $ua) != -1) && (string.find("Opera 6", $ua) ==
-1))
    $os = $os_macosx;

} else if (string.find("SunOS", $ua) != -1)
  $os = $os_solaris;
else
  $os = $os_other;

http.addHeader('X-Moz-Platform', $os);

Comment 29

[Michael Morgan [:morgamic]]

Okay, so we need to just modify that script to work for mobile UAs.  Is that script somewhere in an RCS?  SVN or github?

Comment 30

[Jeremy Orem [:oremj]]

No, I have to use the Zeus GUI to edit it.

Comment 31

[Alex Buchanan [:abuchanan]]

Put it on github,
http://github.com/abuchanan/Zeus-Platform-Header/blob/master/script

Is Zeus/that script running on www-trunk.stage where we can test things safely?

Remember, I never tested that idea, so let's make sure it works like I imagine before we jump in.

Comment 32

[Jeremy Orem [:oremj]]

We could run some stats on the number of UAs that hit the front page.

Comment 33

[Alex Buchanan [:abuchanan]]

(In reply to comment #32)
> We could run some stats on the number of UAs that hit the front page.

I asked Blake, Webtrends doesn't have this readily accessible.  Probably easiest to get it from log files.

Could you grab some access log files and generate stats for a day?  Or, drop some on khan for me, and I can do the parsing, if you like.

Comment 34

[Jeremy Orem [:oremj]]

Looks like there are only about 100 commonly used User-Agents that hit www.mozilla.com. If we are only doing this for the front page we can probably just Vary on User-Agent and do detection in .htaccess.

Comment 35

[Alex Buchanan [:abuchanan]]

(In reply to comment #34)
> Looks like there are only about 100 commonly used User-Agents that hit
> www.mozilla.com. If we are only doing this for the front page we can probably
> just Vary on User-Agent and do detection in .htaccess.

That's helpful, thanks.  That's a lower variety than I thought, and considering how infrequently the home page changes, this sounds like a good option to me.

Comment 36

[Jeremy Orem [:oremj]]

Attachment: Better stats.

Here are some better stats. Used http://gist.github.com/660394 to calculate.

Comment 37

[Jeremy Orem [:oremj]]

That was for 1 hour throughout the entire site. Not limited to front-page.

Comment 38

[Alex Buchanan [:abuchanan]]

Attachment: .htaccess patch, v1

Here's what I have so far...

1) Adds a "Vary: User-Agent" header to the home page only

2) Redirects user agents containing Android, Maemo, Fennec, or Linux armv7l to /m/

3) All of this is en-US only

4) Adds a test case

Todo:

1) Figure out what to do about locales, need to coordinate with Pascal.  Also need to check the variety of user agents on localized landing pages.  Can we "Vary: User-Agent" on these?

2) Test more user agents

3) Add a couple minor things to the test case

Comment 39

[Chris Beard]

Comment on attachment 487060 [details]
detect mobile browser and redirect js script

sounds like this approach is a non-starter due to concerns about scalability

Comment 40

[Alex Buchanan [:abuchanan]]

Attachment: patch v2

version 2 includes...

* mechanism to allow people to view the full site on their mobile device without being redirected (by adding a ?mobile_no_redirect URL param)
* code to check for that param ^ and set a cookie to remember the preference.  cookie expires with the browser session
* test case updates

todo...

* add redirects for /firefox/
* figure out what to do with l10n users/pages

Comment 41

[Alex Buchanan [:abuchanan]]

(In reply to comment #36)
> Created attachment 487736 [details]
> Better stats.
> 
> Here are some better stats. Used http://gist.github.com/660394 to calculate.

Could you do this for /firefox/{ie,upgrade,firefox}.html ?

Comment 42

[Jeremy Orem [:oremj]]

Attachment: Stats for 1 hour of logs matching (?:/[^/]+)?/firefox/(?:firefox|ie|upgrade).html

Comment 44

[Caitlin Looney]

Feedback on testing: https://www-trunk.stage.mozilla.com/en-US/
mbrubeck says: 
>looks good on mobile Safari (iOS 3.0)
>Looks good in Android 1.6 on G1 also though for some reason "/" redirects to "/en-US/m" in desktop Firefox but *not* in Android
> the redirect works in Android 2.2 but not in 1.6

Comment 45

[Alex Buchanan [:abuchanan]]

We found an obscure issue, we a device doesn't get the expected page/redirect.  Working on figuring that out.

Comment 46

[Alex Buchanan [:abuchanan]]

(In reply to comment #45)
> We found an obscure issue, we a device doesn't get the expected page/redirect. 
> Working on figuring that out.

Tracked this down to the Netscalar caching, waiting on bug 615695 to fix

Comment 47

[Alex Buchanan [:abuchanan]]

I worked out the caching bug, and enabled redirection on en-US/firefox/(upgrade|firefox|personal).  Redirection is en-US only for now, until we get a couple strings localized (bug 614731)

Over to QA

Comment 48

[raymond [:retornam] (inactive)]

qa-verified-trunk  www-trunk.stage.mozilla.com using Firefox Mobile for Android

Comment 49

[Alex Buchanan [:abuchanan]]

r78876 on production

Comment 50

[Caitlin Looney]

Woot! Just tried and worked beautifully!

Comment 51

[Chris Beard]

not working for me on the Droid Pro using default browser, which is based upon Android 2.2

i tried both mozilla.com and firefox.com

Comment 52

[Alex Buchanan [:abuchanan]]

(In reply to comment #51)
> not working for me on the Droid Pro using default browser, which is based upon
> Android 2.2
> 
> i tried both mozilla.com and firefox.com

I'm going to need your user agent on that device.

I pulled a sample Droid Pro user agent from here,
http://deviceatlas.com/node/2144399

It's,
Mozilla/5.0 (Linux; U; Android 2.2; en-us; DROID PRO Build/V2_2.26.2) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1

When I test with that user agent, it works.

Comment 53

[Caitlin Looney]

I am on the nightlies. 

It worked for me fine, but now when I try it it goes back to desktop page. Only when I tap on the refresh button does it go to the new /m page.  Strange.

Comment 54

[Caitlin Looney]

Tacking on, the first time I went to Mozilla.com and Firefox.com it worked fine. Now that I am going there repeat times, it's reverting back to desktop format. Hope that helps.

Comment 55

[Alex Buchanan [:abuchanan]]

I think I've got firefox.com working.  Going to mozilla.com still seems broken.  However, going to the home page on the stage server (www-trunk.stage.mozilla.com) seems to work fine.  So, unless I'm missing something, this seems like a production only issue, which makes me think it's a cache-related problem.

I'll keep looking around.  Please keep testing, firefox.com should work now.

Comment 56

[Alex Buchanan [:abuchanan]]

I think everything is working now.

Comment 57

[raymond [:retornam] (inactive)]

qa-verified-trunk  www-trunk.stage.mozilla.com using Firefox Mobile for Android redirects work