Closed Bug 1222509 Opened 5 years ago Closed 4 years ago

Content partially fails to load on


(Web Compatibility :: Mobile, defect)

Firefox 41
Not set


(firefox41 wontfix, firefox42- wontfix, firefox43 affected, firefox44 affected, firefox45 affected)

Tracking Status
firefox41 --- wontfix
firefox42 - wontfix
firefox43 --- affected
firefox44 --- affected
firefox45 --- affected


(Reporter: rift1994raahim, Assigned: karlcow)




(Whiteboard: [sitewait] [webp] [country-bd])


(1 file)

Attached image Untitled-1.jpg
user agent: Mozilla/5.0 (Android 4.4.2; Mobile; rv:42.0) Gecko/42.0 Firefox/42.0
Build ID 	20151029024147

Steps to reproduce:
try to open this website and wait until it load properly.

Actual results:

After full loaded ,I can't see main image on this website with firefox 41.0.2 
but i see other images on add bar
I can reproduce this on my Nexus 6 on Android 5.1.1 with Fennec 42. I'm not sure if any other versions are affected at this point.
Ever confirmed: true
[Tracking Requested - why for this release]: nominating to track since this is a regression.

Upon further testing it looks like this started in Fennec 41 as reverting to Fennec 40 resolves the issue.
Version: Firefox 42 → Firefox 41
Summary: page doesn't loaded with image → Content partially fails to load on
Kevin, do you know who would typically look at these issues on Android?
Flags: needinfo?(kbrosnan)
The main page of the site is broken for me on all browsers I have access to Firefox for Android 45, Firefox on Linux 45 and Chromium on Linux 46. 

Browsing to page 20 does result in the image not loading on Firefox for Android 45. Removing the Android version from user agent results in the page rendering correctly. So this is fallout from bug 1169772.
Component: Graphics, Panning and Zooming → Mobile
Flags: needinfo?(kbrosnan)
Keywords: regression
Product: Firefox for Android → Tech Evangelism
Whiteboard: [needscontact]
Switching to needsdiagnosis.

We know that the user agent version number has an impact, but we don't have yet the part of the code which might break the site.
Flags: needinfo?(miket)
Whiteboard: [needscontact] → [needsdiagnosis]
The image sent to Firefox Android with a version number is WebP format.

When there is no version number, we receive the image, because it's not… WebP.

So dependency on Bug 856375

I see pagespeed in the URI so I wonder if pagespeed optimizes images on the fly for Firefox with WebP. 
If it's the case the service to contact would be Google and not necessary this content site.

To investigate a bit more.
Depends on: 856375
Whiteboard: [needsdiagnosis] → [needsdiagnosis] [webp]

> When PageSpeed rewrites an <img> tag in HTML or a background-url in CSS in response to a request from a WebP-capable browser, it will often transcode the image to WebP format, and rewrite the URL using a .webp extension. If a site visitor then copies the image URL and shares it with a friend, the URL won't work in all browsers. This is because, by default, PageSpeed will respond to that .webp URL with the WebP image payload independent of the Accept or User-Agent header in the HTTP request headers. 

So it sounds like PageSpeed tries to use content negotiation and do the right thing by default (unless you're pointing to .webp assets directly).

> This filter converts JPEG to lossily-encoded WebP if the latter format is supported by the browser (see list of browsers supporting webp); otherwise, this filter is ignored. is the link for "list of browsers supporting webp".

I somewhat suspect this is a site issue -- they have some kind of UA parsing code that determines when to serve webp. I would guess they look for "Android X.X" to determine "isAndroid" (or similar) and assume all Android browsers can handle it.

Karl, I think we need to ask the site how they've configured pagespeed on their server to respond with WebP. I don't see anything in PageSpeed to indicate this is a problem there (and we would have seen wayyyy more issues were that the case, I think).
Flags: needinfo?(miket) → needinfo?(kdubost)
Whiteboard: [needsdiagnosis] [webp] → [contactready] [webp]
From the headers, they probably use Apache

HTTP/1.1 200 OK
Accept-Ranges: bytes
Cache-Control: max-age=31536000
Connection: close
Content-Length: 132144
Content-Type: image/webp
Date: Tue, 02 Aug 2016 23:54:31 GMT
Etag: W/"0"
Expires: Wed, 02 Aug 2017 23:45:01 GMT
Last-Modified: Tue, 02 Aug 2016 23:45:01 GMT
Server: Apache
Set-Cookie: visid_incap_666065=UsjSiHB2SYakyIh4/HQSyh4soVcAAAAAQUIPAAAAAAAXgGnpKwinoLnQm5axpBUM; expires=Wed, 02 Aug 2017 14:06:26 GMT; path=/;
Set-Cookie: incap_ses_218_666065=kI5uCFZxDgUxZxa9En8GAx4soVcAAAAAkCWQvAF3dXAF5u4Y9mo6sQ==; path=/;
X-CDN: Incapsula
X-Iinfo: 9-230299582-230299584 NNNN CT(1 -1 0) RT(1470180382667 6) q(0 0 0 0) r(0 0) U6

So there is high chances they use

The devices are profiles into starting line 44.

The user agent matcher is defined in and "Oh boy!"

For Mobile Android, we get

const char UserAgentMatcherTestBase::kFirefox42AndroidUserAgent[] =
"Mozilla/5.0 (Android 5.0.1; Mobile; rv:42.0) Gecko/42.0 Firefox/42.0";


const char UserAgentMatcherTestBase::kFirefoxMobileUserAgent[] =
"Mozilla/5.0 (Android; Mobile; rv:38.0) Gecko/38.0 Firefox/38.0";

In the FAQ, they say, for example: 
> Google Chrome for iOS version 29+

But in the mod_pagespeed

Let's see " recompress_images filter breaks Firefox on Android #1160 "

which was closed by

Ah here it is

> // Webp support for most devices should be triggered on Accept:image/webp.
> // However we special-case Android 4.0 browsers which are fairly commonly
> // used, support webp, and don't send Accept:image/webp.  Very old versions
> // of Chrome may support webp without Accept:image/webp, but it is safe to
> // ignore them because they are extremely rare.
> //
> // For legacy webp rewriting, we whitelist Android, but blacklist
> // older versions and Firefox, which includes 'Android' in its UA.
> // We do this in 2 stages in order to exclude the following category 1 but
> // include category 2.
> //  1. Firefox on Android does not support WebP, and it has "Android" and
> //     "Firefox" in the user agent.
> //  2. Recent Opera support WebP, and some Opera have both "Opera" and
> //     "Firefox" in the user agent.
> const char* kLegacyWebpWhitelist[] = {
>   "*Android *",
> };
Flags: needinfo?(kdubost)
So probably the right course of action is to ask indeed the site to update mod_pagespeed to the latest version.

The fix for Firefox on Android which will be invalid again if Mozilla comes to support WebP in the future.
is in mod_pagespeed Release

 Issue 1160 Don't serve WebP to Firefox on Android 

The latest mod_pagespeed is Release
we can find the address 

Trying to contact this address.
Assignee: nobody → kdubost
Whiteboard: [contactready] [webp] → [sitewait] [webp] [country-bd]
Good find, Karl.
Contacted the email provided by  WHOIS.
Re tested today and still not fixed. I didn't receive any replies from them.
There is a new issue on webcompat for a different section of the site.
Contacted by email
>  Sorry for delay response. Thanks for your mail. 
> Pagespeed updated version installed on server now. 
> You can browse the site through mozilla browser.

Closed: 4 years ago
Resolution: --- → FIXED
See Also: → WebP
Product: Tech Evangelism → Web Compatibility
You need to log in before you can comment on or make changes to this bug.