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-st...
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
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
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
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 rkattouw@wikimedia.org 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 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-st...
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
Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia
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 bvibber@wikimedia.org 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 rkattouw@wikimedia.org 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 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-st...
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
Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia
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 bvibber@wikimedia.org 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 bvibber@wikimedia.org 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 rkattouw@wikimedia.org 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 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-st...
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
Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia
Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia
multimedia@lists.wikimedia.org