Last modified: 2013-11-07 20:31:50 UTC
Ni! I am experiencing an unresponsive black box when embedding videos using the iframe option given with "Use this file on the Internet" of Wikimedia Commons. See for example this blog post: http://www.cienciaaberta.net/videos-do-encontro-nacional-do-grupo-de-trabalho-2013/ It's been like this for over a week, I also confirmed with other people whom I asked to open that link. I imagine a lot of other material out there that's broken because of this. Thanks for looking into this, Solstag
Thanks for taking the time to report this! Confirming that https://commons.wikimedia.org/wiki/File%3ACienciaaberta_gt2013_abertura.webm?embedplayer=yes remains blank. I can reproduce this with Firefox 24, Chrome 30 and Opera 12.16. Thumbnail at https://upload.wikimedia.org/wikipedia/commons/thumb/d/d5/Cienciaaberta_gt2013_abertura.webm/mid-Cienciaaberta_gt2013_abertura.webm.jpg is a 304 and 0 bytes. Firefox error console says: [12:46:14.877] Expected declaration but found 'url(//bits.wikimedia.org/static-1.23wmf1/resources/jquery.ui/themes/vector/images/ui-bg_inset-hard_100_f0f0f0_1x100.png?2013-10-24T17:28:20Z)'. Skipped to next declaration. @ https://commons.wikimedia.org/wiki/File%3ACienciaaberta_gt2013_abertura.webm?embedplayer=yes:2 [12:46:14.877] Expected declaration but found 'url(//bits.wikimedia.org/static-1.23wmf1/resources/jquery.ui/themes/vector/images/ui-bg_highlight-soft_25_ffef8f_1x100.png?2013-10-24T17:28:20Z)'. Skipped to next declaration. @ https://commons.wikimedia.org/wiki/File%3ACienciaaberta_gt2013_abertura.webm?embedplayer=yes:2 [12:46:14.877] Expected declaration but found 'url(//bits.wikimedia.org/static-1.23wmf1/resources/jquery.ui/themes/vector/images/ui-bg_flat_15_cd0a0a_40x100.png?2013-10-24T17:28:20Z)'. Skipped to next declaration. @ https://commons.wikimedia.org/wiki/File%3ACienciaaberta_gt2013_abertura.webm?embedplayer=yes:2
This is the second time something like this happened. We really need automated (selinium?) Tests for this
(In reply to comment #2) > This is the second time something like this happened. We really need > automated > (selinium?) Tests for this To clarify, I mean that embed broke, not neccesarily in this way. --- I get the black box. However the thumb link above loads fine for me
(In reply to comment #2 by bawolff) > This is the second time something like this happened. We really need > automated (selinium?) Tests for this Couldn't quickly find a "wishlist for tests" linked from or on https://www.mediawiki.org/wiki/Selenium_Framework (which was the first good result on Google for "mediawiki selenium tests"), hence Chris & Željko are CC'ed now (please feel free to remove yourself from CC again).
It does not seem be broken for all embedplayer=yes embeds: https://commons.wikimedia.org/wiki/File:Diastata_costata_-_2013-09-26.webm?embedplayer=yes Could it be something else that broke ? Debug log does not look that useful: https://commons.wikimedia.org/wiki/File:Cienciaaberta_gt2013_abertura.webm?embedplayer=yes&debug=true Would have to look into this in more detail.
Andre, are you still able to reproduce this problem? Do we know how widespread it is? If it is widespread, how can we work together to resolve this in coming days? Michael, do you have any recommendations besides the ones you have posted so far?
I can still reproduce it right here: https://commons.wikimedia.org/wiki/File%3ACienciaaberta_gt2013_abertura.webm?embedplayer=yes Tested in Firefox 25 and Chrome 30 on OS X 10.9. Big black box.
Created attachment 13692 [details] Unrepresentative testcase (In reply to comment #6) > Do we know how > widespread > it is? https://commons.wikimedia.org/wiki/Category:Featured_videos gives 15 fails [color black in attachement] 18 good [color white in attachemnt] ---- 33 total which is approx. 45% fails
Thanks for confirming this is widespread. We can confirm this issue on our end. Michael Dale, let's make this our highest priority, and get both your team and ours to try to fix this problem ASAP. I'm sending you an email now, so we can troubleshoot offline, then post our next steps here.
Here is a note from Guillaume Paumier that may help identify the source of the problem, as one of the video is playing, but not the other ones. https://blog.wikimedia.org/2013/10/21/scientific-multimedia-files-get-a-second-life-on-wikipedia/ What is the difference between these videos that might explain our problem? On Nov 6, 2013, at 1:55 AM, Guillaume Paumier wrote: Hello Fabrice, We're having a bit of a problem with posts on the Wikimedia blog that embed videos from Commons, for example this one: https://blog.wikimedia.org/2013/10/21/scientific-multimedia-files-get-a-second-life-on-wikipedia/ As you can see, it contains 4 media elements : 3 videos and a sound. All of them were displaying properly when we published the post, but as of around October 25, some of the videos aren't showing any more; we just see a black box. Yet, one of the videos is showing fine. The syntax used to embed the posts is the same used for all videos; I've posted the HTML of the post at https://dpaste.de/DYvr I was wondering if you knew of any deployment or change on Commons that might have happened around that time and caused this issue. I've triple-checked the syntax and re-created the iframe snippets from the videos on Commons, yet the result is the same, so I can't find the source of the problem. Of course, it's possible that I'm missing something obvious, in which case please feel free to tell me :) Any guidance you might be able to provide would be most welcome! Thanks -- Guillaume Paumier
It appears the pop up media code is incompatible with the embed view. This issue seems to appear for any video narrower than $wgMinimumVideoPlayerSize (Recently increased to 800px). Thus files like [[File:Basketball-Basic_Types_of_Dribbling.webm]] would be ok since it is really wide, but most videos suffer from this issue.
For reference, the setting change I'm referring to is https://gerrit.wikimedia.org/r/#/c/91342/ , so it took a week to notice, which implies we really need to do better automated testing of the feature, or something
A possible short-term workaround is that we could change $wgMinimumVideoPlayerSize back to 200px specifically for Commons. That would eliminate the problem for the majority of embedded videos, but still keep the pop-up behavior on Wikipedias. It should be emphasized, though, that this is just a workaround and the underlying bug would still need to be fixed at some point.
I would welcome this workaround, as it gives us time to find and fix the underlying bug.
Change 93999 had a related patch set uploaded by Brian Wolff: Don't use the "Pop-up" video viewer thing during iframe embed. https://gerrit.wikimedia.org/r/93999
(In reply to comment #13) > A possible short-term workaround is that we could change > $wgMinimumVideoPlayerSize back to 200px specifically for Commons. That would > eliminate the problem for the majority of embedded videos, but still keep the > pop-up behavior on Wikipedias. It should be emphasized, though, that this is > just a workaround and the underlying bug would still need to be fixed at some > point. I submitted a patch. Somewhat of a semi-cop out (Just disabling the feature for embeds). However on the other hand, that feature wouldn't look good in an iframe even if it did work. I agree that if it takes a while for that patch to be reviewed (or if people don't like my patch) that we should revert the config change until all this is sorted. The iframe embedding code itself is a bit on the scary side (After looking at it, I'm really unclear how the media player js even seems to get loaded at all. If you enable ?debug=yes, the entire thing falls apart), so it could perhaps do with a strong look at how to make it more robust. But that's a separate issue.
Change 93999 merged by Mdale: Don't use the "Pop-up" video viewer thing during iframe embed. https://gerrit.wikimedia.org/r/93999
I reviewed the patch. Makes sense to merge. I don't know if its nice behavior to have the popup on commons or file pages anyway. I have already suggested this in the thread where we universally enabled the popup. The popup really does not make sense on commons or file pages, the asset is already the principally displayed thing on the page, and its already displayed at its natural size or up to 800px. So putting it back to 200px specifically for commons does not make sense, as the popup does not win you anything since the page already displayed the asset at its natural size or a "large enough" ( 800px ) size.
Mark deployed the fix, everything should work now. If anyone encounters any more problems of this nature, please let us know.
Many thanks to Brian and Mark for their fine work in fixing this bug! It appears that this embed bug has been fixed on the URLs above, including this one: https://blog.wikimedia.org/2013/10/21/scientific-multimedia-files-get-a-second-life-on-wikipedia/ Please let us know if it works for you as well -- and thanks for your patience :)
> So putting it back to 200px specifically for commons does not make sense @Mdale: This conclusion doesn't seem to match your argument. Are you sure you meant to include the 'not' in that sentence?
Ni! =) Thanks everyone for helping verify and resolve this. I'd like to reinforce the idea that we need more thorough tests for the media embedding feature - and not just video. Cheers, Solstag .~´
@Ryan, I just mean you will still get the popup on a page if the natural size of the asset was 199px wide. And that popup won't do much for you since the popup will just re-display the asset at its natural size. What we really want to fix, is disable the popup for the main asset on File pages. But yes, in the mean time setting popup size back to 200px for commons, would be good.
