Wikimedia Bugzilla is closed!

We do have an <img> fallback, but it sets img.crossOrigin = true on certain browsers where the fallback would otherwise result in downloading the image twice. Just to be sure that is really the cause of the problem, is there a public wiki where this bug can be reproduced?

(In reply to Tisza Gergő from comment #1)
> We do have an <img> fallback, but it sets img.crossOrigin = true on certain
> browsers where the fallback would otherwise result in downloading the image
> twice. Just to be sure that is really the cause of the problem, is there a
> public wiki where this bug can be reproduced?

Yes, here is an example: http://dev.brickimedia.org/wiki/VisualEditor You'll have to make an account so you can enable it in Beta Features (I think) but that only takes a minute or so.

Tracked in Mingle as https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/295

Contents of the console:

XMLHttpRequest cannot load http://images.brickimedia.org/7/7d/Goodship1.jpg. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://dev.brickimedia.org' is therefore not allowed access. 

Uncaught TypeError: Cannot read property 'length' of null mmv.provider.Image.js:93
Image.binaryToDataURI mmv.provider.Image.js:93
(anonymous function) mmv.provider.Image.js:73
(...)
request.onreadystatechange mmv.performance.js:71

George: the MultimediaViewer version you use is outdated, the current version loads images differently. Do you want to give a shot at updating to the current version? (The tip of the 1.23wmf17 branch should be a safe choice.)

I expect it will still fail, but for an entirely different reason, and that will be easy to fix.

For now I am setting this back to unconfirmed, most of the image loading code has been replaced since then.

(In reply to Tisza Gergő from comment #5)
> George: the MultimediaViewer version you use is outdated, the current
> version loads images differently. Do you want to give a shot at updating to
> the current version? (The tip of the 1.23wmf17 branch should be a safe
> choice.)
> 
> I expect it will still fail, but for an entirely different reason, and that
> will be easy to fix.

Alright, I updated the extension. It works and does have the fallback, but the fallback also blurs the image a lot. I know why it's doing that, but maybe should it not upscale the img tag bigger than the image's thumbnail was?

There could be a flag (off by default) to enable AJAX image loading; when off, we could show a static (positionless) loading bar.

Created attachment 15895 [details]
Media Viewer handling of lack of CORS headers in Chrome

This seems to be the root cause of the chrome rendering problem of wikipedia images since media viewer is now enabled by default. I am quite surprised I couldn't find any other reference for media viewer simply not working for Chrome.

I have confirmed this behavior in Chrome Version 35.0.1916.153 m on windows XP, 7, & 8

Wikipedia images are served with correct CORS headers:


$ curl -vo/dev/null 'http://upload.wikimedia.org/wikipedia/commons/thumb/8/8a/Media_Viewer_-_View_Original_File_-_Mockup_1024px.jpg/1024px-Media_Viewer_-_View_Original_File_-_Mockup_1024px.jpg' 2>&1 | grep Access-Control

< Access-Control-Allow-Origin: *
< Access-Control-Expose-Headers: Age, Content-Length, Date, X-Cache, X-Varnish

$ curl -vo/dev/null 'https://upload.wikimedia.org/wikipedia/commons/thumb/8/8a/Media_Viewer_-_View_Original_File_-_Mockup_1024px.jpg/1024px-Media_Viewer_-_View_Original_File_-_Mockup_1024px.jpg' 2>&1 | grep Access-Control

< Access-Control-Allow-Origin: *
< Access-Control-Expose-Headers: Age, Content-Length, Date, X-Cache, X-Varnish


Maybe you are you behind some sort of proxy which messes with the headers?

Yes, while that is true (watchguard), it is far from an extraordinary configuration ( http://www.garysieling.com/blog/dont-use-access-control-allow-origin ) and the OP's comment was that the application should fail a bit more gracefully the headers don't exist. Web tech is far from my area of expertise but as a developer I would have to concur with the OP that it does make sense for Media Viewer to fail over to another mechanism to ensure a functional application in these situations.

An interesting note is that while Firefox & Chrome both exhibit the same failure mode, IE (11.0.9) does not appear to - making me assume that it either lacks similar security checks or is already using a different mechanism.

We do fail more gracefully now (there is an error message, not just a black screen of deatch which is what the OP was complaining about). Could look nicer (we have some design notes in https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/299 ) but that's very low priority.

I'll think about adding a fallover, but we have too many of them already (the image loading can fail in other ways) and the logic is getting way too complex for its own good. Also, while the image could be loaded without CORS, some of the metadata API requests could not (we could probably recover from those requests failing, though).

All that said, stripping CORS headers is horribly broken behavior and makes zero sense from a security point of view. You should probably complain to the manufacturer / whitelist Wikipedia domains.

I can't comment on the rational other than to say that the behavior is common enough to indicate it would be condition worth considering. Due to the fact that the CORS header is requesting a browser to relax its security level it does sort of make sense that peripheral security would flag that as dangerous in that regard.

The being said switching over to https does resolve the problem so offering that as an option to the user when the error screen shows up could be the easiest way to handle condition.