Wikimedia Bugzilla is closed!

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

https://doc.wikimedia.org/mediawiki-core/master/js/#!/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 ("window.mw.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 http://stackoverflow.com/questions/2238030/).

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.loader.using(
['mw.MwEmbedSupport', 'mw.EmbedPlayer'],
  function() { console.log( 'OK' ); },
  function() { console.log( 'Load error' ); }
);

Any ideas?

If you take a look at the loader handles the embedding of players against a video tag:
 
https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FTimedMediaHandler/57dcd0b56e2fc6701514ea9fdc4be36cec980774/MwEmbedModules%2FEmbedPlayer%2FEmbedPlayer.loader.js#L40 

$.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.

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

https://gerrit.wikimedia.org/r/172421

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.

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

https://gerrit.wikimedia.org/r/172556

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.