Tests had incorrect URL for image, causing canvas 2d drawImage to throw an exception which the conformance tests weren't expecting.

That URL got changed in http://hg.mozilla.org/mozilla-central/rev/4a87e9b7cc96 and then in http://hg.mozilla.org/mozilla-central/rev/2fa42940442d . The second one doesn't look right -- that image doesn't exist on example.com, though maybe it exists on example.com that the test servers route to. Either way, this doesn't seem correct -- if these are supposed to be valid images, maybe we should just embed a data: URL? Changing them to connect to the actual sites won't work, because we can't rely on having network access.

(In reply to Vladimir Vukicevic [:vlad] [:vladv] from comment #2) > if these are supposed to be valid images, maybe we > should just embed a data: URL? The problem is we treat a data: URL as same origin while other browsers do not.

Does the test -want- a foreign-origin image? I didn't look too closely, honestly. I'm sure there is a canonical one we can use...

Vlad, yes. I don't know about example.com re-routing, but if you start a local web server in content/canvas/test/webgl and run all tests, those tests fails as I explained. The tests appears to take an image from another domain, drawImage into a canvas 2d and then try to load the content of the canvas into a WebGL texture. This is supposed to throw an exception. If I've done the wrong thing, let me know what I need to do to fix things.

(In reply to Vladimir Vukicevic [:vlad] [:vladv] from comment #2) > That URL got changed in > http://hg.mozilla.org/mozilla-central/rev/4a87e9b7cc96 and then in > http://hg.mozilla.org/mozilla-central/rev/2fa42940442d . The second one > doesn't look right -- that image doesn't exist on example.com, though maybe > it exists on example.com that the test servers route to. Either way, this > doesn't seem correct -- if these are supposed to be valid images, maybe we > should just embed a data: URL? Changing them to connect to the actual sites > won't work, because we can't rely on having network access. Looks like Benoit changed the URL and then, on upgrading the tests, forgot and copied over the URLs from the Khronos tests. Benoit, can you comment?

(In reply to Vladimir Vukicevic [:vlad] [:vladv] from comment #2) > That URL got changed in > http://hg.mozilla.org/mozilla-central/rev/4a87e9b7cc96 and then in > http://hg.mozilla.org/mozilla-central/rev/2fa42940442d . The second one > doesn't look right -- that image doesn't exist on example.com, though maybe > it exists on example.com that the test servers route to. In mochitests, example.com resolves to the mochitests http server, similar to mochi.test:8888, with the only difference that example.com is a different origin compared to mochi.test:8888. Since the mochitest scripts have the mochi.test:8888 origin, any resources from example.com are cross-origin. This is how we simulate loading cross-origin resources without requiring internet access or file URIs.

Comment on attachment 8355935 [details] [diff] [review] bug-956607-fix-cross-origin-webgl-texture-failures Review of attachment 8355935 [details] [diff] [review]: ----------------------------------------------------------------- It is intentional that we don't load any resource from internet origins in mochitests. Doing so is a major cause of intermittent oranges for obvious reasons. The way that we avoid loading resources from internet, is that we import a copy of these resources in our tree, and install them in the mochitests directory so we can get them served on mochi.test:8888 URLs. In cases (like here) where it matters that these resources are cross-origin, we simply refer to them with example.com URLs, as explained in my previous comment.

(In reply to Vladimir Vukicevic [:vlad] [:vladv] from comment #4) > Does the test -want- a foreign-origin image? I didn't look too closely, > honestly. I'm sure there is a canonical one we can use... Some of the tests want a cross-origin image, to check that e.g. texImage2D fails on it. (On the other hand there are no CORS tests in the conformance test suite, as that would require specific HTTP server support. We do have CORS/WebGL tests in content/canvas/test/crossorigin. These are using example.com URLs served with specific HTTP headers).