Closed Bug 1144028 Opened 9 years ago Closed 9 years ago serves different mobile content to Firefox Android and Chrome Android


(Web Compatibility :: Site Reports, defect)

Not set


(Not tracked)



(Reporter: karlcow, Unassigned)




(Whiteboard: [mobile-compat-form] [serversniff] [country-fr])

+++ This bug was initially created as a clone of Bug #946380 +++

Site: serves desktop content to Firefox for Android and Firefox OS

:: Steps To Reproduce

1. Use Firefox on Android
2. Go to
3. The user is redirected to

When accessing the Home page with Chrome on Android
The users are redirected to
Which seems to be a better version of the site.
No longer blocks: Woodduck
Whiteboard: [mobile-compat-form] [serversniff] [sitewait] [country-fr] → [mobile-compat-form] [serversniff] [country-fr]
When loading directly
with Firefox Android (or Firefox OS), we received a desktop version of this site.

Orange has clearly server side sniffing which doesn't give the right assets on

If we were receiving the same things than what Chrome UA receives, we would for example get this dedicated script to manage the responsive mobile site when coming with a Chrome UA.

which contains among many things this piece.

var navig = {
  isIE: /MSIE/.test(navigator.userAgent) || /Trident/.test(navigator.userAgent),
  isFF: /Firefox/.test(navigator.userAgent),
  isChrome: /Chrome/.test(navigator.userAgent),
  isIpad: /iPad/.test(navigator.userAgent),
  isIphone: /iPhone/.test(navigator.userAgent),
  isIpod: /iPod/.test(navigator.userAgent),
  isOpera: /Opera/.test(navigator.userAgent),
  isSafari: /Safari/.test(navigator.userAgent),
  isAndroid: /Android/.test(navigator.userAgent),
  getVersion: function () {
    var a,
    b = navigator.appName,
    c = navigator.userAgent,
    d = c.match(/(opera|chrome|safari|firefox|msie|Trident)\/?\s*(\.?\d+(\.\d+)*)/i);
    return d && null !== c.match(/version\/([\.\d]+)/i) && /Trident/.test(navigator.userAgent) !== !0 ? (a = c.match(/version\/([\.\d]+)/i), d[2] = a[1])  : d && /Trident/.test(navigator.userAgent) === !0 && c.match(/rv:([0-9]+)/i) && (a = c.match(/rv:([0-9]+)/i), d[2] = a[1]),
    d = d ? [
    ] : [
    parseInt(d[1], 10)
  isTouchDevice: function () {
    return s_confCommon && 'test' === s_confCommon.typeEnv ? !1 : 'ontouchstart' in window || navigator.MaxTouchPoints > 0 || navigator.msMaxTouchPoints > 0

To note also that 
* Opera Mobile Blink is not redirected at all to any mobile site.
These are tests with Chrome Android UA.

First of all it takes to 175 requests in ~30s and 1816 Kb before reaching the landing page of France Telecom for Chrome Android. Most of these resources are NOT cached.

Redirection sequence for Chrome Android:
'User-Agent: Mozilla/5.0 (Linux; Android 4.3; HTCONE Build/JSS15J) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.59 Mobile Safari/537.36' 

It starts with a series of redirects to an interstitial:

18:06:26.181 GET [HTTP/1.1 301 Moved Permanently 877ms]
18:06:27.049 GET [HTTP/1.1 302 Found 1532ms]
18:06:28.590 GET [HTTP/1.1 302 Moved Temporarily 815ms]
18:06:29.405 GET [HTTP/1.1 302 Moved Temporarily 507ms]
18:06:29.916 GET [HTTP/1.1 302 Moved Temporarily 490ms]
18:06:30.416 GET [HTTP/1.1 200 OK 423ms]

Then restart a series of redirects

18:06:32.692 GET [HTTP/1.1 302 Moved Temporarily 333ms]
18:06:33.024 GET [HTTP/1.1 302 Moved Temporarily 357ms]
18:06:33.384 GET [HTTP/1.1 200 OK 763ms]

This final URI is
the content of this page is highly dependent on the User Agent too. 

From there if I access the Boutique for example,

18:15:38.981 GET [HTTP/1.1 302 Moved Temporarily 665ms]
18:15:39.695 GET [HTTP/1.1 200 OK 754ms]

I receive a site which is totally broken in Gecko (using Chrome Android UA string )
due to the usage of old Flexbox such as

From the previous context if I tap on Espace Client

18:19:47.235 GET [HTTP/1.1 301 Moved Permanently 740ms]
18:19:48.124 GET [HTTP/1.1 302 Moved Temporarily 686ms]
18:19:48.819 GET [HTTP/1.1 302 Moved Temporarily 327ms]
18:19:49.123 GET [HTTP/1.1 200 OK 2130ms]

Which leads to a broken mobile Web site in Gecko (using Chrome Android UA string )

CONCLUSION: I would NOT recommend a Chrome Android UA override for Firefox OS Bug 946380
The sites are really tailored for Chrome (Blink/WebKit).
These are tests with Firefox Android UA.

First of all it takes to 31 requests in ~37s and 217 Kb before reaching the landing page of France Telecom for Firefox Android. Most of these resources are NOT cached.

18:39:15.434 GET [HTTP/1.1 301 Moved Permanently 885ms]
18:39:16.367 GET [HTTP/1.1 302 Found 1188ms]
18:39:17.621 GET [HTTP/1.1 302 Moved Temporarily 1021ms]
18:39:18.740 GET [HTTP/1.1 302 Moved Temporarily 1249ms]
18:39:20.042 GET [HTTP/1.1 302 Moved Temporarily 3696ms]
18:39:23.799 GET [HTTP/1.1 200 OK 378ms]

18:39:26.498 GET [HTTP/1.1 302 Moved Temporarily 4499ms]
18:39:31.123 GET [HTTP/1.1 200 OK 1120ms]

The site is less polished than the one for Chrome but is working well on Gecko.

Every options I have tried be boutique, espace client, assistance are working well on Firefox Android.

If we were doing UA override on Firefox OS, that would be with Firefox Android UA to reach that Web site which is working well on Gecko.
I'm closing this as WORKSFORME.
We receive a different site from Chrome Android, but it is working better than if we were asking the one Chrome is receiving.
Closed: 9 years ago
Resolution: --- → WORKSFORME
Product: Tech Evangelism → Web Compatibility
Component: Mobile → Site Reports
You need to log in before you can comment on or make changes to this bug.