Page MenuHomePhabricator

Dynamically loading TimedMediaHandler for new content (preview)
Closed, ResolvedPublic


I would like to dynamically load TimedMediaHandler for new content (i.e. previews in wikEd). So far I kind of got it to work with:

mw.loader.load( ['mw.MwEmbedSupport', 'mw.EmbedPlayer', 'mw.PopUpMediaTransform'] );

However, when clicking a video clip thumb, the running on-page media player is missing its controls and duplicate player with complete controls is run in a new window.

How is it done correctly and completely?

Version: unspecified
Severity: normal

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 3:44 AM
bzimport set Reference to bz72675.
bzimport added a subscriber: Unknown Object (MLST).

Ideally, TimedMediaHandler should always at runtime install a small JS hook with mw.hook('wikipage.content'):!/api/mw.hook

and that hook should handle loading the necessary modules and applying the transforms. Then as long as your preview is calling the hook, that and other stuff should work.

But TMH needs to be fixed to do that properly so you don't have to special-case it. :)

Thanks Brion. I am already running that hook (" 'wikipage.content' ).fire( $( '#wikEdPreviewArticle' ) );") but as far as I can tell, it doesn't do anything at all for video clips. Do you have a workaround (e.g. a missing load call) or have an idea how to figure this out?

This *might* work for now if I'm reading correctly:

$( previewElement ).find('video,audio').embedPlayer();

Hopefully it won't double-apply things or anything. :D

The following combination actually works, but unfortunately only for the first call. For repeated previews, the same symptoms as described in the original post above appear:

$( '#wikEdPreviewArticle' ).find( 'video,audio' ).embedPlayer();
mw.loader.load( 'mw.PopUpMediaTransform' );

(Is this because the code in /mediawiki/extensions/TimedMediaHandler/resources/mw.PopUpThumbVideo.js uses $(document).ready?)

I think that encapsulation of the PopUpMediaTransform in a load event handler is indeed the problem here (see also

Please could somebody more familiar with this code check into it? Maybe the code could simply be made into a function that could be called from MediaWiki LivePreview and custom preview handlers.

I have spent two days on a workaround and I am stuck. The problem seems to be related to mw.EmbedPlayer and mw.TimedText giving loading errors, so that load handlers such as .embedPlayer() are not executed properly. I have tested this in the browser console, e.g with:

['mw.MwEmbedSupport', 'mw.EmbedPlayer'],

function() { console.log( 'OK' ); },
function() { console.log( 'Load error' ); }


Any ideas?

mdale wrote:

If you take a look at the loader handles the embedding of players against a video tag:

$.embedPlayer .. should work. you would have to manually apply the popup logic, but the embedPlayer calls should be fine.

Thanks Michael! Unfortunately, because of the problem described in comment 6, embedPlayer does not work, because mw.EmbedPlayer and mw.TimedText are in the dependencySet but give load errors, so that the actual mw.processEmbedPlayers will never be executed.

Do the request and process the playerElements with updated dependency set
mw.loader.using( dependencySet, function() {
Setup the enhanced language:
mw.processEmbedPlayers( playerSet, readyCallback );
}, function( e ) {
throw new Error( 'Error loading EmbedPlayer dependency set: ' + e.message );
} );

I am testing on en.wikipedia on a "Show changes" edit page with an embedded video (so that the media player is not loaded with the page) and wikEd local preview using the Firefox console.

For this reason, the code from mw.PopUpThumbVideo.js never reaches "return false", the default click action is not suppressed, and a new player window opens always.

It's easy, workarounds should not be needed. TimedMediaHandler should be fixed and get in line with the rest of the tools.

K, done some further investigation.

The biggest problem here is that the parser output for a page with TMH content simply DOESN'T have any modules. That means that the parser is not even aware of which modules TimedMediaHandler is using (thus it can also not notify any JS of these additional modules that the content requires.

gerritadmin wrote:

Change 172421 had a related patch set uploaded by TheDJ:
[WIP] Improve live loading

Added the improvements we did for SyntaxHighlighting (registering modules on the parser output instead of on the output page).

The patch requires some further work to rewrite the loader script logic however. I don't fully understand yet how MwEmbedSupport takes care of registering modules, so I left that out for now.

gerritadmin wrote:

Change 172556 had a related patch set uploaded by TheDJ:
[WIP] Turn MwEmbed loaderscripts into modules

Did some more work on this, but I don't have a full picture of the exact dependencies of the mw modules yet, and i'm quite certain that they are also a bit 'sloppy' right now, so some stuff isn't working 100%.

On a normal page transclusion, it works without the dreaded loaderScripts param now though.

Change 172421 had a related patch set uploaded (by TheDJ):
[WIP] Improve live loading


I've been experimenting more with this.

Current problems.

  • Sometimes it seems in debug mode, a module is missing. This is likely due to an undeclared dependency, but i have trouble finding out what is erroring/missing
  • When executing a second setup call (live preview, preview again), it almost always fails to setup the player. I suspect that this is because the player keeps some global context/state somewhere, but it might also be because it is trying to render while not yet attached to the dom. or both....

The patches should be working now.

There is still further cleanup work to do, in the form of renaming and namespacing the mwEmbedModules, and with redoing mwEmbed's module registration system, but they can be handled separately.

Patches deployed at so we can play a bit with it.

I noticed I had to action=purge the page after deploying the patch, so that would seem to be a bit of a concern and I don't immediately have ideas about how to counter that.
I also see that audio players in the category page don't seem to properly load for some reason... Will further investigate this.

Change 172556 had a related patch set uploaded (by TheDJ):
Turn MwEmbed loaderscripts into modules

The only outstanding problem is the parser cache.

The current TMH version is triggered by RL modules that use loaderScripts. These will be moved to parser output. When we deploy this, the startup module will refresh in 5 minutes, but the pages that are currently in the parser cache are not yet refreshed and still have the old and now no longer working setup.

We thus need to actively refresh all these pages. A promising candidate for this seems to be RejectParserCacheValue hook. However there are no identifying marks that currently distinguish TMH cached pages from non TMH pages, let alone identify 'old' TMH pages from non-TMH pages.

We would also need a strategy for this if we would want to introduce VideoJS, so we might as well figure one out now.

[edit] latest thought. Add a marker module to the 'old setup', let everything settle for 30 days, then use RejectParserCacheValue from the 'new code'.

TheDJ set Security to None.
TheDJ removed a subscriber: wikibugs-l-list.

Change 172556 merged by Brion VIBBER:
Turn MwEmbed loaderscripts into modules

Change 172421 merged by jenkins-bot:
Improve live loading and ResourceLoader behavior

TheDJ claimed this task.
TheDJ removed a project: Patch-For-Review.