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]
should be confusing,
not comedy.
On 12 November 2014 20:32, Rob Macias (Axelerate) <v-romac(a)microsoft.com>
wrote:
Great! Thank you Roan.
-----Original Message-----
From: roan.kattouw(a)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(a)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(a)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(a)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:
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