ua-parser is now patched. Thank you for letting us know about this change; in the future, though, please appreciate that making these kinds of (breaking) changes with every new release necessitates a lot of effort from third-parties (and a lot of effort from you lot, to notify everyone!) - it's probably not the best way to spend time.
On 13 November 2014 01:01, Brion Vibber <[email protected]> wrote: > Ok I can confirm that video works in IE in Windows Tech Preview build 9879 > *if* Google's IE WebM plugin is installed, but our help links do a very > poor job of directing the user to install it -- and the default download > link is super unhelpful. > > On the plus side it doesn't seem to be a regression -- I get similarly > poor behavior on Windows 8.1 / IE 11, and the same improvements on our end > should help with it: > * deploy ogv.js player as a fallback that "just works" on a default > Windows install for 360p Ogg videos and Ogg audio > * make a _much_ clearer help link to the Google WebM plugin (once ogv.js > is live we'd still want to offer this to support HD playback) > > eg, clicking on the video play button should take the user directly to the > WebM plugin download page instead of downloading the .webm file. > > I've filed a bug as https://bugzilla.wikimedia.org/show_bug.cgi?id=73348 > -- if the Multimedia team doesn't have time to poke it I'll try patching > something up. > > -- brion > > > > On Wed, Nov 12, 2014 at 9:30 PM, Brion Vibber <[email protected]> > wrote: > >> I can take a peek at the video playback; I've got a Windows 10 Tech >> Preview install handy. >> >> With the experimental ogv.js JavaScript shim in playback seems fine on my >> test pages (eg <http://ogvjs-testing.wmflabs.org>) but we haven't >> deployed that to production yet as it needs a few more bug fixes. >> >> I'll test with the WebM IE plugin; that ought to "just work" on both IE >> 9/10/11 and the tech preview... but it sounds like we've got poor behavior >> when the plugin's not installed, where it *should* be prompting to install >> the plugin currently rather than giving a raw download. >> >> -- brion >> >> On Wed, Nov 12, 2014 at 4:18 PM, Roan Kattouw <[email protected]> >> wrote: >> >>> Actually copying in the multimedia mailing list correctly this time. >>> >>> Note: this mailing list is open to the public, and any emails you send >>> to it will be publicly archived forever at >>> https://lists.wikimedia.org/pipermail/multimedia . This is standard >>> fare for Wikimedians, but the Microsoft people on this thread may not >>> be used to this. >>> >>> On Wed, Nov 12, 2014 at 7:13 PM, Roan Kattouw <[email protected]> >>> wrote: >>> > Copying in: >>> > * Multimedia team because this concerns video playback >>> > * Oliver because he maintains ua-parser >>> > * Erik Z because he maintains browser statistics >>> > * Timo because he cares about browsers and relationships with the >>> browser >>> > communities >>> > >>> > On Wed, Nov 12, 2014 at 6:42 PM, Rob Macias (Axelerate) >>> > <[email protected]> wrote: >>> >> >>> >> Hello All, >>> >> >>> >> >>> >> >>> >> As you may have heard, we rolled out a new Windows 10 preview build >>> with >>> >> significant IE interoperability updates and wanted to make sure our >>> >> Wikipedia partners are in the loop. A major part of this update is the >>> >> “Edge” mode platform, which seems to affect how IE is being detected >>> – this >>> >> is leading to Video playback errors when visiting the wikimedia.org >>> domain. >>> >> More info on ‘living on the edge’ exists here >>> >> >>> http://blogs.msdn.com/b/ie/archive/2014/11/11/living-on-the-edge-our-next-step-in-interoperability.aspx >>> >> >>> >> >>> >> >>> >> To our Wikipedia folks: >>> >> >>> >> Mind taking a look at this? Bug detail has been pasted below including >>> >> steps to reproduce and developer notes. If you aren’t already a >>> member of >>> >> the Windows Insider Program, we recommend doing so OR you can download >>> >> RemoteIE, which provides another option for testing your site in the >>> latest >>> >> version of IE. >>> >> >>> >> >>> > >>> > >>> > I'm not aware of us being a member. Timo, could you look into whether >>> we >>> > are, and whether we should be? >>> > >>> > RemoteIE looks really useful. It doesn't seem to be available for >>> Ubuntu >>> > though? Our engineering staff is split roughly 50/50 between Mac OS and >>> > Ubuntu / other Linux flavors, so if RemoteIE is only available for >>> Windows >>> > and Mac OS on desktop, then it's only useful for about half our staff. >>> But >>> > that's still a heck of a lot better than passing a Windows laptop >>> around the >>> > office :) >>> > >>> >> >>> >> (Bug Specs) >>> >> >>> >> Reference #: 741977 >>> >> >>> >> Description of the Problem: commons.wikimedia.org: Video is not being >>> >> played >>> >> >>> >> Steps to Reproduce: >>> >> >>> >> 1. Navigate to URL: http://commons.wikimedia.org/wiki/Main_Page. >>> >> >>> >> 2. Scroll down to video window >>> >> >>> >> 3. Invoke Play button to play video/ audio on the page. >>> >> >>> >> >>> >> >>> >> Actual Result: >>> >> >>> >> Video is not being played only black screen is displayed and instead >>> of >>> >> playing video, it is asking to save the file. >>> >> >>> >> >>> >> >>> >> Expected Result: >>> >> >>> >> Video should load and play properly. >>> >> >>> >> >>> > >>> > >>> > Multimedia team, could you guys look into this? >>> > >>> >> >>> >> Developer Notes: >>> >> >>> >> With the introduction of the Edge mode platform, the site needs to >>> account >>> >> for the latest UA string changes. See below: >>> >> >>> >> >>> >> >>> >> Mozilla/5.0 (Windows NT 6.4; WOW64) AppleWebKit/537.36 (KHTML, like >>> Gecko) >>> >> Chrome/36.0.1985.143 Safari/537.36 Edge/12.0 >>> >> >>> >> >>> >> >>> >> These changes help prevent IE from being (incorrectly) identified as >>> an >>> >> earlier version. >>> >> >>> >> >>> > >>> > >>> > Thanks for letting us know that the UA string changed. >>> > >>> > Timo, Oliver and Erik Z: you guys should know about this UA string >>> change. >>> > It'll affect jquery.client, ua-parser, our browser stats, and probably >>> other >>> > bits of code here and there that will presumably identify this UA as >>> Chrome >>> > 36 rather than IE 12. >>> > >>> >> >>> >> Please let me know if you have an estimated timeframe to address this >>> >> issue, and if our team can further assist in this process. >>> >> >>> >> >>> > >>> > >>> > Most likely, someone on the multimedia team will file a ticket for >>> this in >>> > our public bug tracker, which you can subscribe to. >>> > >>> > Roan >>> >>> _______________________________________________ >>> Multimedia mailing list >>> [email protected] >>> https://lists.wikimedia.org/mailman/listinfo/multimedia >>> >> >> > > _______________________________________________ > Multimedia mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/multimedia > > -- Oliver Keyes Research Analyst Wikimedia Foundation
_______________________________________________ Multimedia mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/multimedia
