1155792 - cnn.com home page shows low-resolution placeholder image until window is resized

Status: RESOLVED WORKSFORME

(Core :: Security, defect)

Description

[Chris Peterson [:cpeterson]]

Attachment: cnn-screenshot.png

The low-resolution placeholder image is supposed to be quickly replaced by a high-resolution image. In Nightly 40, the image is now replaced until I resize the window or (sometimes) wait 10+ seconds. See attached screenshot. I am using OS X 10.10.

This seems to be a recent regression. mozregression bisected to this mozilla-central pushlog:

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=883e17fc475f&tochange=ab0490972e1e

and then narrowed to libvpx bug 1137614. This seems like an unlikely cause, so I don't trust this regression range.

Comment 1

[Chris Peterson [:cpeterson]]

Christoph, now that I better understand this bug's STR, I bisected this regression again and landed on this pushlog:

https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=2e0ebba4a766&tochange=183190289b9c

Could this bug be a regression from your fix for CSP bug 1086999?

Comment 2

[Daniel Holbert [:dholbert]]

(Do you see any Content Security Policy messages in the Browser Console, when you hit this bug? [and are those messages missing in pre-regression builds?]  If so, that'd be a strong sign that comment 1 is correct.)

Comment 3

[Alice0775 White]

via local build:
Last Good: 8bd316ad33c6
First Bad: 3aaf3cccabac

Triggered by
	3aaf3cccabac	Christoph Kerschbaumer — Bug 1086999 - CSP: Asterisk (*) wildcard should not allow blob:, data:, or filesystem: when matching source expressions (r=sstamm)

Comment 4

[Chris Peterson [:cpeterson]]

(In reply to Daniel Holbert [:dholbert] from comment #2)
> (Do you see any Content Security Policy messages in the Browser Console,
> when you hit this bug? [and are those messages missing in pre-regression
> builds?]  If so, that'd be a strong sign that comment 1 is correct.)

Yes. I see this CSP error that I don't see with Aurora 39:

Content Security Policy: The page's settings blocked the loading of a resource at data:image/gif;base64,R0lGODlhEAAJAJEAAAAAAP///////wAAACH5BAEAAAIALAAAAAAQAAkAAAIKlI+py+0Po5yUFQA7 ("img-src http://www.cnn.com *").

Comment 5

[Daniel Holbert [:dholbert]]

(I see that, too, though I can't reproduce this bug [on linux] -- and more importantly, that particular data URL seems to just be a 16x9 blank spacer GIF. So I think that error may be a red herring. I wonder where the real high-res content is getting blocked.)

Comment 6

[Daniel Holbert [:dholbert]]

Anyway -- reclassifying in Security, given comment 1 and comment 3.

Comment 7

[Boris Zbarsky [:bzbarsky]]

[Tracking Requested - why for this release]: Web compat regression.

Sounds like technically a bug in the site, helped along by the fact that absolutely no browser implemented the spec correctly until we landed that patch, no? 

Which might just mean the spec is not web-compatible and needs to change; we've had a number of regression reports about this now.

Comment 8

[Jim Jeffery not reading bug-mail 1/2/11]

Any chance that https://bugzilla.mozilla.org/show_bug.cgi?id=1086999 could be backed out while its decided what is best course of action, whether file a Evangelism bug with CNN, or waiting for re-write/clarification of the spec ?  

Looking at blurry images is getting tiresome on eyes.

Comment 9

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #5)
> (I see that, too, though I can't reproduce this bug [on linux]

Ah, I can repro now, using a fresh profile.

(I think I wasn't seeing this in my main browsing profile because of NoScript or one of my other add-ons modifying the page load behavior.)

> I wonder where the real
> high-res content is getting blocked.

Following up on this -- when we fail, the img "src" attribute has been left pointing to a small image. Its "src" attribute is a URL that ends with "small-169.jpg".  When I resize the window, the <img> src attribute changes to the same URL but with "exlarge-169.jpg" at the end.

Also: I can work around this bug by toggling the about:config pref "security.csp.enable" to false, which confirms (if it wasn't already clear) that this issue is caused by CNN's CSP.  (Not sure how that influences the setting of "src" attributes -- the spacer-gif load failure might cause them to take a different code-path through their loading JS code, I guess.)

Jim, if this is *really* bothering you, you could conceivably use that as a temporary local workaround. :)

Christoph, could you chime in here and take a look?

Comment 10

[Jim Jeffery not reading bug-mail 1/2/11]

@Daniel - thanks, flipping pref as noted in #comment 9 clears it up for now.

Comment 11

[Christoph Kerschbaumer [:ckerschb]]

(In reply to Daniel Holbert [:dholbert] from comment #9)
> Christoph, could you chime in here and take a look?

Yes, our CSP implementation blocks loading of data: schemes if not explicitly whitelisted. At the moment we have three pages that break because of the changes in Bug 1086999. We summarized our options here [1] and we will decide later this week.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1086999#c34

Comment 12

[Liz Henry (:lizzard) (relman/hg->git project)]

Christoph, can you find an owner for this bug over the next week or so? Thanks!

Comment 13

[Mike Taylor [:miketaylr]]

A CNN engineer is now aware of this bug: https://twitter.com/ADSlaton/status/593829225058213889

> Thank you for the heads up. We will take a look.

Comment 14

[Christoph Kerschbaumer [:ckerschb]]

Thanks Mike for reaching out to CNN. Also, I will assign the bug to myself.

Comment 15

[Jim Jeffery not reading bug-mail 1/2/11]

I re-checked this bug today using latest m-c win32 Nightly and the issue still exists.  Any words on when CNN will fix this ?

Comment 16

[Christoph Kerschbaumer [:ckerschb]]

(In reply to Jim Jeffery not reading bug-mail 1/2/11 from comment #15)
> I re-checked this bug today using latest m-c win32 Nightly and the issue
> still exists.  Any words on when CNN will fix this ?

We are in contact with engineers at CNN and they are about to resolve the problem. I can't promise any timeline, but should happen fairly soon.

Comment 17

[Javaun Moradi [:javaun]]

Just heard from the CNN site technical director: "we will work on our CSP implementation and if we have any questions we will reach out."

Let's give them some time.

Comment 18

[Jim Jeffery not reading bug-mail 1/2/11]

Seems with the recent re-design of CNN's web site, the issue stated in this bug of images being displayed in 'place-holder' size has been fixed.  

I've not seen any issues with images for past 2-3 days after setting the pref:
"security.csp.enable" back to default 'true' value.


Tested in win32 m-c build from today's Nightly.

Comment 19

[Christoph Kerschbaumer [:ckerschb]]

(In reply to Jim Jeffery not reading bug-mail 1/2/11 from comment #18)
> Seems with the recent re-design of CNN's web site, the issue stated in this
> bug of images being displayed in 'place-holder' size has been fixed.  

Confirmed, this page works again. Not only have they restructured their page but also updated their CSP to explicitly whitelist 'data:', see:
> img-src 'self' * data:;

Thanks CNN!