Last modified: 2013-07-30 10:26:12 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T21043, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 19043 - Instant commons video can't be played by cortado
Instant commons video can't be played by cortado
Status: RESOLVED WONTFIX
Product: MediaWiki extensions
Classification: Unclassified
OggHandler (Other open bugs)
unspecified
All All
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-06-01 06:40 UTC by Gregory Maxwell
Modified: 2013-07-30 10:26 UTC (History)
1 user (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Gregory Maxwell 2009-06-01 06:40:58 UTC
Because of the java security policy cortado is unable to fetch remote video files. OggHandler enabled sites play instant commons video fine for video tag users but fails ungracefully for cortado: Clicking play just makes the player vanish and nothing happens.

Ogghandler should probably attempt to always use cortado from the same hostname as the media file. Failing that it should simply act as though Java were not available.
Comment 1 Bawolff (Brian Wolff) 2011-02-10 03:33:34 UTC
Would signing the jar allow it to go around same origin policies and thus fix this bug?
Comment 2 Gregory Maxwell 2011-02-10 03:48:25 UTC
Only in exchange for a nasty security warning (since, after all, if you sign it and the user accepts the sig they are giving it run of their machine).  If thats done, it should only be done for cases(??) where the unsigned jar will not work.

There is a centrally maintained and signed jar of cortado on theora.org (since the permission is cached using the central copy has some benefits).
Comment 3 Brion Vibber 2011-09-23 00:15:00 UTC
The ideal way to handle this is probably to do an iframe export for things that don't render to simple images.

The actual hosting site (Commons in this case) can provide an iframe-friendly embedding view, which encapsulates any JS library & java applet loading that may be needed to make the actual video play.

This also keeps the receiving site from needing to know anything about how the files actually work, just as you don't need to know what SVG or TIFF or PDF renderer is being used -- you only need to know that they give you a thumbnail image URL that will be in a format that a browser can display.

See also bug 25854 (expose oEmbed embedding API for media files), which dovetails nicely with the iframe-style export. (Standard oEmbed has you ship around a chunk of HTML for the foreign site to use directly, but ideally this is just the <iframe> element pointing at our embeddable page.)
Comment 4 Brion Vibber 2011-10-03 22:46:22 UTC
Starting to collect some notes for further work at [[mw:Requests for comment/Refactor on File-FileRepo-MediaHandler]].
Comment 5 Andre Klapper 2013-07-30 10:26:12 UTC
The OggHandler extension is not under active development anymore. It is unlikely that there will be any further active development.

OggHandler has been superseded by TimedMediaHandler:

          http://www.mediawiki.org/wiki/Extension:TimedMediaHandler

Please use TimedMediaHandler instead.

Closing this report as WONTFIX as part of Bugzilla Housekeeping.

Please feel free to reopen this bug report in the future if either anyone takes the responsibility for active development of OggHandler again; or move this bug report from the "OggHandler" to the "TimedMediaHandler" component in Bugzilla if the same problem still happens when using TimedMediaHandler. Thanks.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links