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 http://epaper.prothom-alo.com/ 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.

[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.

Last Good: 2015-06-19 First Bad: 2015-06-20 https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2694ff2ace6a&tochange=c319f262ce3e

Kevin, do you know who would typically look at these issues on Android?

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 http://epaper.prothom-alo.com/view/dhaka/2015-11-12/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.

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.

The image sent to Firefox Android with a version number is WebP format. http://epaper.prothom-alo.com/contents/2016/2016_07_28/pages/x2016_07_28_1.jpg.pagespeed.ic.e0q0CuDewi.webp When there is no version number, we receive the image, because it's not… WebP. http://epaper.prothom-alo.com/contents/2016/2016_07_28/pages/x2016_07_28_1.jpg.pagespeed.ic.pBK4_3erkv.jpg 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.

https://developers.google.com/speed/pagespeed/module/reference-image-optimize#serve_webp_urls > 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). https://developers.google.com/speed/pagespeed/module/reference-image-optimize#convert_jpeg_to_webp > 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. https://developers.google.com/speed/webp/faq 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).

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=/; Domain=.prothom-alo.com Set-Cookie: incap_ses_218_666065=kI5uCFZxDgUxZxa9En8GAx4soVcAAAAAkCWQvAF3dXAF5u4Y9mo6sQ==; path=/; Domain=.prothom-alo.com 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 https://github.com/pagespeed/mod_pagespeed The devices are profiles into device_properties_test.cc starting line 44. https://github.com/pagespeed/mod_pagespeed/blob/b98bf9a12bfe54528efe294a8117bc34c6d8e610/net/instaweb/rewriter/device_properties_test.cc#L44 The user agent matcher is defined in user_agent_matcher_test_base.cc and "Oh boy!" https://github.com/pagespeed/mod_pagespeed/blob/8184c8f99ff06f35f923da4b0d41336bd72fbe42/pagespeed/kernel/http/user_agent_matcher_test_base.cc For Mobile Android, we get https://github.com/pagespeed/mod_pagespeed/blob/8184c8f99ff06f35f923da4b0d41336bd72fbe42/pagespeed/kernel/http/user_agent_matcher_test_base.cc#L121 const char UserAgentMatcherTestBase::kFirefox42AndroidUserAgent[] = "Mozilla/5.0 (Android 5.0.1; Mobile; rv:42.0) Gecko/42.0 Firefox/42.0"; and 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 https://github.com/pagespeed/mod_pagespeed/blob/8184c8f99ff06f35f923da4b0d41336bd72fbe42/pagespeed/kernel/http/user_agent_matcher_test_base.cc#L182 Let's see " recompress_images filter breaks Firefox on Android #1160 " https://github.com/pagespeed/mod_pagespeed/issues/1160#issuecomment-156456808 which was closed by https://github.com/pagespeed/mod_pagespeed/commit/41871f9e0ac97a177dd188b40c8e48c991e4f575 Ah here it is https://github.com/pagespeed/mod_pagespeed/blob/8184c8f99ff06f35f923da4b0d41336bd72fbe42/pagespeed/kernel/http/user_agent_matcher.cc#L121-L134 > // 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 *", > }; >

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 1.10.33.0-beta https://developers.google.com/speed/pagespeed/module/release_notes#release_1.10.33.0-beta Issue 1160 Don't serve WebP to Firefox on Android The latest mod_pagespeed is Release 1.11.33.2-stable https://developers.google.com/speed/pagespeed/module/release_notes#release_1.11.33.2-stable

On http://en.prothom-alo.com/ we can find the address info@prothom-alo.info Trying to contact this address.

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. https://webcompat.com/issues/3378

Contacted https://github.com/debclop 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. CONFIRMED.