Closed Bug 922416 Opened 7 years ago Closed 7 years ago

images on no longer load


(Tech Evangelism Graveyard :: English US, defect)

Not set


(firefox26 unaffected, firefox27 fixed)

Tracking Status
firefox26 --- unaffected
firefox27 --- fixed


(Reporter: Gavin, Unassigned)




- Load

Expected: image displayed in the middle of the screen
Actual: image fails to load, JS error is thrown:
19:58:08.325 ReferenceError: require is not defined cFr4vWhteZP:25

The scripts seem to be hosted on

This works for me in a release build, but not on Nightly.

Bisecting locally points to:
The first bad revision is:
changeset:   149035:e39d4f589f10
user:        Patrick McManus <>
date:        Fri Sep 27 13:55:24 2013 -0400
summary:     bug 912550 - remove spdy/2 r=hurley
tl;dr - server side CORS bug not putting Access-Control-Allow-Origin response header on CORS response. code generating the reference to the XHR URI appears to generate different URIs depending on whether or not itself was fetched with spdy (cloudup) - at no point is the cors resource (on using spdy.

full version:

You can happily reproduce this on aurora or greater too by disabling spdy there through about:config.

The troublesome resource is:

it is loaded via XHR and CORS and triggered by a script element in the base HTML from cloudup. It is failing because there is no Access-Control-Allow-Origin response header. There is an Origin request header.

When is fetched via spdy it doesn't generate a reference to that url in the HTML. Instead it references (note there is no gz in the url).[*] That URL has the appropriate ACAO response header and everything loads fine.

I'll see if I can reachout to cloudup with a reference to this bug.

[*] This is an interesting choice - I presume that's because spdy is defined as always being gzip capable so the code is designed to let the transport take care of the compression.. that's pretty cool, however in this case the reference is to another origin that never spoke spdy :( (on the other hand firefox successfully compressed it in http/1 anyhow - so no harm done.)
I don't see any reason to track this based on comment 1
Assignee: nobody → english-us
Component: Networking → English US
Product: Core → Tech Evangelism
Target Milestone: --- → Oct
I'm getting the same error now (and a blank page as a result) on the homepage:
Just tweeted at Guillermo and Nate who work at Cloudup. If you guys are reading this, feel free to point me in the direction of a better bug reporting mechanism. ^_^
None of the credit belongs to me, but Cloudup support just emailed this to me:

Hi Mike,

You rock! Thanks so much for digging in a bit and reporting the issue. The
folks at Mozilla have been just awesome in alerting us to FF-specific
issues that sneak by our QA, and for that we're truly grateful. The Nightly
issue is logged - expect a fix shortly.

Have a wonderful week, and keep sharing the #CloudupLove!

Hey everyone, just wanted to say thanks so much for reaching out. <3 the community.

Also, sorry for the delay in fixing this! It's been fixed for a few days actually on our staging environment but just now finally pushed it into production. Firefox Nightly works splendidly for me :)

Reach out again if you ever need. Thanks again everyone!
Thanks Nathan!
Closed: 7 years ago
Resolution: --- → FIXED
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.