MultimediaViewer should work (or at least fail more gracefully) on wikis where the images have no CORS headers
Open, LowestPublic

Description

Some MediaWiki installations have images hosted on a different domain than the wiki, and in some cases do not have an 'Access-Control-Allow-Origin' header on the image server domain. This causes the XMLHttpRequest for MultimediaViewer to fail, and nothing but a black screen appears. So that the usability isn't completely broken in these (and similar) situations, if the XMLHttpRequest to get the image fails for any reason, MultimediaViewer should fall back to simply displaying the image using an <img> tag.


Version: unspecified
Severity: major

Details

Reference
bz62469
bzimport raised the priority of this task from to Normal.
bzimport set Reference to bz62469.
bzimport added a subscriber: Unknown Object (MLST).
Tgr added a comment.Mar 10 2014, 5:04 PM

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.

Tgr added a comment.Mar 10 2014, 8:10 PM

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

Tgr added a comment.Mar 10 2014, 9:21 PM

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.

Tgr added a comment.Mar 10 2014, 9:26 PM

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?

Tgr added a comment.Jun 26 2014, 10:44 PM

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

bryanhunt wrote:

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

Attached:

Tgr added a comment.Jul 11 2014, 12:54 AM

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?

bryanhunt wrote:

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.

Tgr added a comment.Jul 11 2014, 8:58 PM

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.

bryanhunt wrote:

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.

Jdforrester-WMF moved this task from Untriaged to Backlog on the Multimedia board.Sep 4 2015, 6:36 PM
Restricted Application added a subscriber: Matanya. · View Herald TranscriptSep 4 2015, 6:36 PM

Mass-removing the Multimedia tag from MediaViewer tasks, as this is now being worked on by the Reading department, not Editing's Multimedia team.

Jdlrobson lowered the priority of this task from Normal to Lowest.Feb 2 2016, 6:31 PM
Jdlrobson added a subscriber: Jdlrobson.