We could probably solve this by installing a crossdomain.xml on all our domains: Here is twitter's version of it.

http://twitter.com/crossdomain.xml

Note that Apple's Java 6 no longer seems to allow the browser plugin at all, either, and points at Oracle's JRE 7 download page. Bleeeeeeeh!

Hopefully TimedMediaHandler and MP4 transcoding will make this fully obsolete soon...

Specifically, I have JRE7 update 9 installed. I suspect this problem might not be Mac specific, but likely is depending on the JRE version/update you have installed.

@brion exactly why i was testing this today. The test used the oracle browser plugin.

(The oracle java plugin doesn't work with Chrome for Mac btw, since Chrome is 32bit only and JRE7 for mac is 64 bit only, but there we have built in support, so it doesn't really affect us.)

Actually, it seems we already have a crossdomain.xml....

http://upload.wikimedia.org/crossdomain.xml

The last message is "network: Encoding for http://upload.wikimedia.org/crossdomain.xml : null" so perhaps it's tripping over the lack of specified encoding or content-type... or it's just expecting xmlns attributes these days. can be many things I guess.

Note how it went from:

[INFO] trying to open https://upload.wikimedia.org/wikipedia/commons/3/36/Mirror-Induced-Behavior-in-the-Magpie-%28Pica-pica%29-Evidence-of-Self-Recognition-pbio.0060202.sv009.ogv at offset 0

to:

network: Cache entry found [url: http://upload.wikimedia.org/crossdomain.xml, version: null] prevalidated=false/0
cache: Resource http://upload.wikimedia.org/crossdomain.xml has expired.

https -> http, indeed if I open from http://commons.wikimedia.org then the cortado player functions.

Getting replaced by TMH very soon, so probably moot.

Tim tells me that this should probably be filed upstream anyway.

https://trac.xiph.org/report/24

(In reply to comment #8)

Tim tells me that this should probably be filed upstream anyway.

Upstreamed as https://trac.xiph.org/ticket/1911

Probably there are two issues here:

1: stupid isAbsolute check in Cortado...

isAbsolute = urlString.startsWith("http://");

2: Broken getDocumentBase() in Oracle JRE applet browser plugin. I don't see this property being set in the Cortado log, and it seems that the 'relative' document parsing of Cortado depends on the documentBase.

try {

  documentBase = getDocumentBase();
  Debug.log(Debug.INFO, "Document base: " + documentBase);
}
catch (Throwable t) {
  documentBase = null;
}

Both should be fixed upstream.

to clarify: 2 is what breaks playback, 1 is what accidentally makes it work on http:// urls due to a built in IE6 workaround, but the workaround is faulty and incomplete.

TimedMediaHandler was deployed at the beginning of November 2012, see
https://www.mediawiki.org/wiki/TimedMediaHandler and http://blog.wikimedia.org/2012/11/08/introducing-wikipedias-new-html5-video-player/ for more information.
It is based on HTML5 and supports closed captions, timed text, WebM, etc.

This bug report was reported about "Cortado". With TimedMediaHandler being in place, Cortado is now ONLY used as a fallback for web browsers that do not support any of the video codecs we offer but have Java installed. This currently is Apple Safari without XiphQt installed, or Microsoft Internet Explorer with Java applet installed.

Please add a comment here in case that you still face the problem described (now with Cortado inside of TimedMediaHandler) if using one of the browsers mentioned above. In that case, this report should be moved to product="MediaWiki extensions" and component="TimedMediaHandler" in this bug tracker.

Issues that also happen with Cortado without TimedMediaHandler should be reported to https://trac.xiph.org/ instead.

Wikimedia itself is currently not actively working on Cortado.
If you are still interested in seeing this / if this problem still happens, please follow https://trac.xiph.org/ticket/1911 instead.

Also see comment 12 in this report for more explanation which way Wikimedia Multimedia currently takes. Closing as WONTFIX for Wikimedia itself.