1222509 - Content partially fails to load on http://epaper.prothom-alo.com/

Status: RESOLVED FIXED

(Web Compatibility :: Site Reports, defect)

Description

[Md. Rahimul Islam]

Attachment: 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 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

Comment 1

[u279076]

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.

Comment 2

[u279076]

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

Comment 3

[u279076]

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

Comment 4

[u279076]

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

Comment 5

[Kevin Brosnan [Ex-Mozilla]]

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.

Comment 6

[Karl Dubost💡 :karlcow]

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.

Comment 7

[Karl Dubost💡 :karlcow]

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.

Comment 8

[Mike Taylor [:miketaylr]]

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

Comment 9

[Karl Dubost💡 :karlcow]

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 *",
> };
>

Comment 10

[Karl Dubost💡 :karlcow]

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

Comment 11

[Karl Dubost💡 :karlcow]

On http://en.prothom-alo.com/
we can find the address [e-mail] 

Trying to contact this address.

Comment 12

[Mike Taylor [:miketaylr]]

Good find, Karl.

Comment 13

[Karl Dubost💡 :karlcow]

Contacted the email provided by  WHOIS.

Comment 14

[Karl Dubost💡 :karlcow]

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

Comment 15

[Karl Dubost💡 :karlcow]

Contacted https://github.com/debclop by email

Comment 16

[Karl Dubost💡 :karlcow]

>  Sorry for delay response. Thanks for your mail. 
> Pagespeed updated version installed on server now. 
> You can browse the site through mozilla browser.

CONFIRMED.