Last modified: 2014-02-25 19:29:22 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 58478 - Improve interface for MediaHandlers to add JavaScript
Improve interface for MediaHandlers to add JavaScript
Status: NEW
Product: MediaWiki
Classification: Unclassified
File management (Other open bugs)
1.23.0
All All
: Low enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks: code_quality 61924
  Show dependency treegraph
 
Reported: 2013-12-14 06:18 UTC by Bawolff (Brian Wolff)
Modified: 2014-02-25 19:29 UTC (History)
8 users (show)

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


Attachments

Description Bawolff (Brian Wolff) 2013-12-14 06:18:14 UTC
Currently MediaHandlers add JS using the method parserTransformHook, which one could either directly add modules to the $parser object, or add an OuputHook, to mess with $wgOut later on.

This is not that good an interface. Besides being rather indirect way to add resource loader modules, its (almost) impossible to trigger this from a special page where we call transform directly, and don't have a $parser object that is parsing something.

I'm not sure what a better interface would be. My first thought would be that responsibility for this should not be in MediaHandler, but instead be in the MediaTransformObject. The mto could at least have a method getModules() which special pages could call, or perhaps something like $mto->addModulesToOutput( $this->getOutput() ); Still less then ideal since people will be bound to forget to call it as most media types don't need js, but still would be much better than current situation.
Comment 1 Brion Vibber 2013-12-19 19:09:16 UTC
A couple possible scenarios:

1) Always load just enough code to check for if you need to do runtime JS transformations

In this scenario, every page that can show wikitext should have at least a tiny JS module loaded that hooks into an event that is called on load and again every time new parsed wikitext output is added to a page (such as by a preview, or a dialog box, or whatever).

This might be a very tiny piece of code that just asynchronously fires off a load of a fuller module, such as something that adds player controls to a video or sets up interactive rendering of a molecule on a canvas, or whatever, when it encounters its targets (and otherwise does nothing).

Advantages:
* can use same code & event for initial load and new loads?
* defers extra media modules until use
* doesn't require recording modules used per page


2) Implement any media viewers more complicated than a simple element without scripting via an <iframe>

Advantages:
* the iframe content rendering worries about module loading, the parent page can ignore it totally
* makes exposing those media for external embedding trivial, as we'd be doing the exact same thing we do in our content context
Comment 2 Tisza Gergő 2013-12-22 14:43:00 UTC
Using iframes would also decrease our attack surface significantly, if we use a separate domain for them. Plus it would make it simple to treat local and external files in a uniform way. That would restrict what the JS code is allowed to do, but a player probably doesn't need access to anything outside its own frame anyway.
Comment 3 Bawolff (Brian Wolff) 2014-01-20 19:54:11 UTC
(In reply to comment #2)
> Using iframes would also decrease our attack surface significantly, if we
> use a
> separate domain for them. Plus it would make it simple to treat local and
> external files in a uniform way. That would restrict what the JS code is
> allowed to do, but a player probably doesn't need access to anything outside
> its own frame anyway.

Hmm, that might get in the way of our current click the video and get a pop up dialog that has the video on it
Comment 4 Michael Dale 2014-01-20 21:45:02 UTC
Within kaltura proper we do sandbox the player in an iframe, but we still make use of parent javascript access for synchronous api ( postMessage is asynchronous ) Also HTML fullscreen on iPads and IE's we need parent page access to adjust the iframe layout to take up full browser page space.

The kaltura player uses a friendly ( same domain ) iframe, but this does not reduce attack surface, since you can just jump up to the parent frame and run any JS you want, furthermore you would have to structure things to server the player iframe from another domain, to have any effect on 'attack surface'. 

Also, you need to do tricky iframe injection strategies [1] to support one click play on mobile chrome and iOS ( assuming we ever care about single click to play user experience )
[1] https://github.com/kaltura/mwEmbed/blob/master/kWidget/kWidget.js#L935
Thouse injection strategies only work for same domain iframes. 

And finally safari blocks cross domain iframe cookies, so any personalization / customization / private media playback has to be structured post "click" in iframe, or via url parameterization.

Having a separate rendering / entry point, has its own sets of risks, that probably outweigh advantages of cross domain iframing the player. 


I recommend we use normal precautions of localization string and api based playback ( no more video payload injection )
Comment 5 Bawolff (Brian Wolff) 2014-01-20 21:49:28 UTC
(In reply to comment #4)
> Within kaltura proper we do sandbox the player in an iframe, but we still
> make
> use of parent javascript access for synchronous api ( postMessage is
> asynchronous ) Also HTML fullscreen on iPads and IE's we need parent page
> access to adjust the iframe layout to take up full browser page space.
> 
> The kaltura player uses a friendly ( same domain ) iframe, but this does not
> reduce attack surface, since you can just jump up to the parent frame and run
> any JS you want, furthermore you would have to structure things to server the
> player iframe from another domain, to have any effect on 'attack surface'.

The point here is more to centralize js - js gets loaded with the iframe so that we could avoid including the TMH loader js on all page loads, well at the same time not have to keep track of which pages have a video on them.

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


Navigation
Links