So, ua-parser isn't actually being used for our frontend at the moment.[0] That's, I think, a Timo Problem (yay! :P).
In terms of ua-parser generally and its application to analytics specifically, the example user agent reports as Chrome - which is unsurprising given that the user agent doesn't actually identify as IE. I'm going to write a patch for ua-parser now and, assuming it passes the tests and gets +2d, that'll solve the problem for post-hoc analytics. But, for the sake of every user agent-y person on the internet, please consider coming up with a user agent that actually explicitly identifies the browser.[1]
[0]We actually have three different user agent parsing solutions - one for site determination, one for feature determination, and one for post-hoc analytics. I'm pushing the ua-parser team towards building a cacheing layer and then hoping we can look at using ua-parser in production, thereby standardising: we'll see. [1] http://webaim.org/blog/user-agent-string-history/ should be confusing, not comedy.
On 12 November 2014 20:32, Rob Macias (Axelerate) v-romac@microsoft.com wrote:
Great! Thank you Roan.
-----Original Message----- From: roan.kattouw@gmail.com [mailto:roan.kattouw@gmail.com] On Behalf Of Roan Kattouw Sent: Wednesday, November 12, 2014 4:18 PM To: Rob Macias (Axelerate) Cc: James Forrester; Moriel Schottlender; Ecosystem Engineering IE; Colleen Williams; David Catuhe; Maria Naggaga Nakanwagi; Timo Tijhof; Oliver Keyes; Erik Zachte; multimedia@lists.wikimedia.org Subject: Re: IE & Wikipedia [Microsoft] (Ref# 741977)
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 rkattouw@wikimedia.org 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) v-romac@microsoft.com 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:
Navigate to URL: http://commons.wikimedia.org/wiki/Main_Page.
Scroll down to video window
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