Closed Bug 1181379 Opened 4 years ago Closed 4 years ago

Image onload doesn't run if src attribute is data: on a facebook page due to a CSP that forbids data: loads

Categories

(Web Compatibility :: Desktop, defect)

Firefox 40
Unspecified
macOS
defect
Not set

Tracking

(firefox40+ fixed, firefox41+ fixed, firefox42+ fixed)

RESOLVED FIXED
Tracking Status
firefox40 + fixed
firefox41 + fixed
firefox42 + fixed

People

(Reporter: salazarm, Unassigned)

References

Details

(Keywords: site-compat)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.130 Safari/537.36

Steps to reproduce:

On any page add the following html:

<img src="data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=" onload="console.log(this)"/>
<img src="https://bugzilla.mozilla.org/extensions/GuidedBugEntry/web/images/advanced.png" onload="console.log(this)"/>


Actual results:

You see only the second image's console.log in FireFox beta


Expected results:

You should see both images' console.log. (This works in previous versions of FireFox)
Severity: normal → blocker
OS: Unspecified → Mac OS X
Priority: -- → P1
Severity: blocker → normal
Priority: P1 → --
Duplicate of this bug: 1181374
> This works in previous versions of FireFox

I don't know which version of Firefox you're using (you didn't say), but I see both images in the console log in both Firefox 39 and a current nightly when I put your HTML into a file and load that file.  Which exact Firefox version are you using?  Is there a specific page where you're seeing this problem?
Flags: needinfo?(salazarm)
It's in the Beta version 40.0
Flags: needinfo?(salazarm)
OK, just tried a Beta 40.0 build on Mac, and I can't reproduce the problem there either....

Do you see the problem in safe mode?  What about in a clean profile?
Try on facebook.com
The facebook.com front page doesn't have any data: images.

Look, I'm happy to help sort out what's going on here if you're willing to work with me a bit.  But you need to give me _something_ useful to work with.
The onload event for the first image doesn't fire when inserted into the DOM while logged into facebook.com

Insert the images anywhere in the DOM to reproduce:
<img src="data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=" onload="console.log(this)"/>
<img src="https://bugzilla.mozilla.org/extensions/GuidedBugEntry/web/images/advanced.png" onload="console.log(this)"/>

This doesn't happen on previous versions of FireFox or other browsers, just this beta v40.
[Tracking Requested - why for this release]: Might break faceboook

Oh, you're injecting images like that into facebook?

Facebook (at least the front page) has the following content-security-policy header:

  default-src *;script-src https://*.facebook.com http://*.facebook.com https://*.fbcdn.net http://*.fbcdn.net *.facebook.net *.google-analytics.com *.virtualearth.net *.google.com 127.0.0.1:* *.spotilocal.com:* 'unsafe-inline' 'unsafe-eval' https://*.akamaihd.net http://*.akamaihd.net *.atlassolutions.com;style-src * 'unsafe-inline';connect-src https://*.facebook.com http://*.facebook.com https://*.fbcdn.net http://*.fbcdn.net *.facebook.net *.spotilocal.com:* https://*.akamaihd.net wss://*.facebook.com:* ws://*.facebook.com:* http://*.akamaihd.net https://fb.scanandcleanlocal.com:* *.atlassolutions.com http://attachment.fbsbx.com https://attachment.fbsbx.com;

Per the CSP specification (informative text at <http://www.w3.org/TR/CSP/#source-list-guid-matching>):

  As defined above, special URL schemes that refer to specific pieces of unique content,
  such as "data:", "blob:" and "filesystem:" are excluded from matching a policy of * and
  must be explicitly listed.

The normative bit is http://www.w3.org/TR/CSP/#match-source-expression step 2 which explicitly excludes "data:" URIs from matching *.

So Facebook's policy explicitly prohibits loading anything from data:.

We didn't use to implement the specification correctly here, but fixed that in bug 1086999.  Chrome is working on fixing a similar bug they have; see https://code.google.com/p/chromium/issues/detail?id=473904

All that said, I'm seeing some logs on facebook about font loads from data: being blocked too.  So it sounds like we should at least talk to facebook about this before shipping 40...
Status: UNCONFIRMED → NEW
Component: DOM: Core & HTML → Desktop
Ever confirmed: true
Product: Core → Tech Evangelism
Summary: Image onload doesn't run if src attribute is base64 encoded image → Image onload doesn't run if src attribute is data: on a facebook page due to a CSP that forbids data: loads
Version: 40 Branch → Firefox 40
I'll pass this information along -- I'm an engineer at Facebook. Thanks for helping me debug this.
No problem.  I wonder why there weren't clear console messages about CSP blocking this when I first tried it on facebook.com....
Flags: needinfo?(mozilla)
(In reply to Boris Zbarsky [:bz] from comment #10)
> No problem.  I wonder why there weren't clear console messages about CSP
> blocking this when I first tried it on facebook.com....

Hey Boris, I can take a closer look tomorrow, but I think we (as you) have identified the problem within Bug 970790. In particular your comment here [1] explains it best. It is on my to do list, but not very high up in my priority list at the moment. If you think we should prioritize a fix for that, please let me.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=970790#c14
Flags: needinfo?(mozilla)
Oh, right, that.  Well, it would have made salazarm@mit.edu's job much easier if we'd just had a console message telling him what was up...

I do think we should up the priority if we're going to ship bug 1086999 because otherwise people will have their sites failing for mysterious reasons and be very very confused.  :(
(In reply to Boris Zbarsky [:bz] from comment #12)
> Oh, right, that.  Well, it would have made salazarm@mit.edu's job much
> easier if we'd just had a console message telling him what was up...
> 
> I do think we should up the priority if we're going to ship bug 1086999
> because otherwise people will have their sites failing for mysterious
> reasons and be very very confused.  :(

Agreed, we should get that fixed. As a consolidation, the error should at least pop up in the browser console, no? At least I would hope so, see:
http://mxr.mozilla.org/mozilla-central/source/dom/security/nsCSPUtils.cpp#87
I didn't obviously see it in the browser console....
Ah, looks like I get things in the browser console in non-e10s mode.  Doesn't seem to happen in e10s.
It is said above that this didn't happen in earlier versions, so can we get info on what version/s it works in, so we can identify this as a regression, if appropriate?

Do we want tracking for 41 and 42?

I'll enable tracking for 40 so we find a way to resolve either the issue or how it is communicated.
[Tracking Requested - why for this release]:

[Tracking Requested - why for this release]:

> so can we get info on what version/s it works in

See the "affected" flags and comment 8.

> Do we want tracking for 41 and 42?

Probably.
Hi. There is a similar problem with the Social Fixer addon (images that are links are invisible but the links work).  The problem does not exist in 39.0.  I don't know about 41, but it also affects Nightly.
Tracking, see Comment 8
Hi.  I've just been notified that the problem does not exist in 40 64 bit, as it does in 30 32 bit.
We've resolved the issue on our end, thanks again for helping debug this.
Thanks for fixing this!
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Updating the status flags because of Comment 21.
Product: Tech Evangelism → Web Compatibility
You need to log in before you can comment on or make changes to this bug.