Following up on disabling JavaScript support for IE6 [1], here is some additional research on other browsers. I'd appreciate if people with experience testing/developing for/with these browsers would jump in with additional observations. I think we should wait with adding other browsers to the blacklist until the IE6 change has been rolled out, which may expose unanticipated consequences (it already exposed that Common.js causes errors in blacklisted browsers, which should be fixed once [2] is reviewed and merged).
As a reminder, the current blacklist is in <resources/src/startup.js>.
As a quick test, I tested basic browsing/editing operation on English Wikipedia with various browsers. Negative results don't necessarily indicate that we should disable JS support for these browsers, but they do indicate the quality of testing that currently occurs for those browsers. Based on a combination of test results, unpatched vulnerabilities and usage share, an initial recommendation for each browser follows.
Note that due to the heavy customization through gadgets/site scripts, there are often site-specific issues which may not be uncovered through naive testing.
== Microsoft Internet Explorer 7.x ==
Last release in series: April 2009
- Browsing: Most pages work fine (some styling issues), but pages with audio files cause JavaScript errors (problem in TMH). - Editing: Throws JS error immediately (problem in RefToolbar)
Both of these errors don't occur in IE8.
Security vulnerabilities:
Secunia reports 15 out of 87 vulnerabilities as unpatched, with the most serious one being rated as "moderately critical" (which is the same as IE6, while the most serious IE8 vulnerability is rated "less critical").
Usage: <1%
Recommendation: Add to blacklist
== Opera 8.x ==
Last release in series: September 2005
Browsing/editing: Works fine, but all JS fails due to a script execution error (which at least doesn't cause a pop-up).
Security: Secunia reports 0 unpatched vulnerabilities (out of 26).
Usage: <0.25%
Recommendation: Add to blacklist
== Opera 10.x-12.x ==
Last release in series: April 2014
Browsing/editing: Works fine, including advanced features like MediaViewer (except for 10.x)
Security: No unpatched vulnerabilities in 12.x series according to Secunia, 2 unpatched vulnerabilities in 11.x ("less critical") and 1 unpatched vulnerability in 10.x ("moderately critical")
Usage: <1%
Recommendation: Maintain basic JS support, but monitor situation re: 10.x and add that series to blacklist if maintenance cost too high
== Firefox 3.6.* ==
Last release in series: March 2012
Browsing/editing: Works fine (MediaViewer disables itself)
Security: 0 unpatched vulnerabilities according to Secunia
Recommendation: Maintain basic JS support
== Firefox 3.5.* ==
Last release in series: April 2011
Browsing/editing: Works fine (MediaViewer disables itself)
Security: 0 unpatched vulnerabilities according to Secunia
Recommendation: Maintain basic JS support
== Safari 4.x ==
Last release in series: November 2010
Browsing/editing: Works fine
Security: 1 unpatched "highly critical" vulnerability according to Secunia ("exposure of sensitive information")
Recommendation: Maintain basic JS support, but monitor
== Safari 3.x ==
Last release in series: May 2009
Browsing/editing: Completely messed up, looks like CSS doesn't get loaded at all
Security: 2 unpatched vulnerabilities, "highly critical"
Usage share: Usage reports for Safari in [3] are broken, all Safari versions are reported as "0.0". However, [4] suggests that Safari 3 usage is negligible/non-existent.
Recommendation: Styling issue may be worth investigating in case it affects other browsers and/or is JS-caused. Otherwise probably can be safely ignored.
[1] http://lists.wikimedia.org/pipermail/wikitech-l/2014-August/077952.html [2] https://gerrit.wikimedia.org/r/#/c/152122/ [3] http://stats.wikimedia.org/wikimedia/squids/SquidReportClients.htm [4] http://stackoverflow.com/questions/12655363/what-is-the-most-old-safari-vers...
On Wed, Aug 6, 2014 at 11:52 AM, Erik Moeller erik@wikimedia.org wrote:
== Microsoft Internet Explorer 7.x ==
Last release in series: April 2009
- Browsing: Most pages work fine (some styling issues), but pages with
audio files cause JavaScript errors (problem in TMH).
- Editing: Throws JS error immediately (problem in RefToolbar)
Both of these errors don't occur in IE8.
Security vulnerabilities:
Secunia reports 15 out of 87 vulnerabilities as unpatched, with the most serious one being rated as "moderately critical" (which is the same as IE6, while the most serious IE8 vulnerability is rated "less critical").
Usage: <1%
Recommendation: Add to blacklist
The IE6 disable patch is in prod now. I've tested on a few wikis and have not noticed any issues - if anything, IE6 actually feels usable now when before it kept throwing errors or was just slowing to a crawl. If there are no objections, I'll do the same with IE7 after wmf19 lands on mw.org (to give us a little bit more time for any issues to be reported).
Erik
[...]
Are there changes affecting only JavaScript, or also CSS?
CSS is another beast that needs effort to support in browsers properly.
svetlana
On 08/23/2014 11:23 PM, Legoktm wrote:
On 8/23/14, 6:38 PM, svetlana wrote:
[...]
Are there changes affecting only JavaScript, or also CSS?
CSS is another beast that needs effort to support in browsers properly.
Just JavaScript, as the subject line indicates :-)
It's a little more complicated, though, since a lot of CSS is loaded via JavaScript (this is how our ResourceLoader works for performance reasons). Mainly, this is CSS that is only useful in conjunction with JavaScript.
However, due to oversights, CSS that works fine without JavaScript is sometimes unintentionally loaded via JavaScript. If you think you see this, you can report it as a bug.
Matt Flaschen
On Sat, Aug 23, 2014 at 11:22 AM, Erik Moeller erik@wikimedia.org wrote:
The IE6 disable patch is in prod now. I've tested on a few wikis and have not noticed any issues - if anything, IE6 actually feels usable now when before it kept throwing errors or was just slowing to a crawl. If there are no objections, I'll do the same with IE7 after wmf19 lands on mw.org (to give us a little bit more time for any issues to be reported).
This is ready to be merged unless folks have final concerns: https://gerrit.wikimedia.org/r/#/c/157774/
IE7 is pretty badly broken in prod (and has been for a long time), so AFAICT this will be a clear net improvement.
Erik
On 10 September 2014 13:45, Erik Moeller erik@wikimedia.org wrote:
On Sat, Aug 23, 2014 at 11:22 AM, Erik Moeller erik@wikimedia.org wrote:
The IE6 disable patch is in prod now. I've tested on a few wikis and have not noticed any issues - if anything, IE6 actually feels usable now when before it kept throwing errors or was just slowing to a crawl. If there are no objections, I'll do the same with IE7 after wmf19 lands on mw.org (to give us a little bit more time for any issues to be reported).
This is ready to be merged unless folks have final concerns: https://gerrit.wikimedia.org/r/#/c/157774/
IE7 is pretty badly broken in prod (and has been for a long time), so AFAICT this will be a clear net improvement.
This is now done.
J.
Opera < 12 has already been dropped by jQuery for a while now[1], and was also removed from Grade A support for MediaWiki core[2] since MediaWiki 1.17.
That is to say, we've not tested or prioritised anything pertaining Opera 11 or below for several years now. It wasn't blacklisted yet from the startup module because we didn't yet know whether it could pass as Grade X and apparently there hasn't been enough traffic/interest from anyone to bother adding the blacklist for it. I mean, we don't (and aren't going to) blacklist Netscape either.
But I'd say old Opera is significant enough that it's worth blacklisting < 12.
Firefox 3.5 and 3.6 was dropped in MediaWiki 1.22.0 (from Grade A to Grade B; we blacklisted Firefox < 4), but we changed that to Firefox < 3 because we found that (despite Firefox 3.6 not being officially supported by Mozilla and jQuery) it's feature set was good enough to just give it everything (Grade X instead of Grade B) per a Village Pump thread requesting it.[3]
— Krinkle
[1] https://jquery.com/browser-support/ [2] https://www.mediawiki.org/w/index.php?title=Compatibility&oldid=1119439#... [3] https://github.com/wikimedia/mediawiki-core/commit/ceaa7ddada7d1426cab2b76b9...
On 6 Aug 2014, at 20:52, Erik Moeller erik@wikimedia.org wrote:
Following up on disabling JavaScript support for IE6 [1], here is some additional research on other browsers. I'd appreciate if people with experience testing/developing for/with these browsers would jump in with additional observations. I think we should wait with adding other browsers to the blacklist until the IE6 change has been rolled out, which may expose unanticipated consequences (it already exposed that Common.js causes errors in blacklisted browsers, which should be fixed once [2] is reviewed and merged).
As a reminder, the current blacklist is in <resources/src/startup.js>.
As a quick test, I tested basic browsing/editing operation on English Wikipedia with various browsers. Negative results don't necessarily indicate that we should disable JS support for these browsers, but they do indicate the quality of testing that currently occurs for those browsers. Based on a combination of test results, unpatched vulnerabilities and usage share, an initial recommendation for each browser follows.
Note that due to the heavy customization through gadgets/site scripts, there are often site-specific issues which may not be uncovered through naive testing.
== Microsoft Internet Explorer 7.x ==
Last release in series: April 2009
- Browsing: Most pages work fine (some styling issues), but pages with
audio files cause JavaScript errors (problem in TMH).
- Editing: Throws JS error immediately (problem in RefToolbar)
Both of these errors don't occur in IE8.
Security vulnerabilities:
Secunia reports 15 out of 87 vulnerabilities as unpatched, with the most serious one being rated as "moderately critical" (which is the same as IE6, while the most serious IE8 vulnerability is rated "less critical").
Usage: <1%
Recommendation: Add to blacklist
== Opera 8.x ==
Last release in series: September 2005
Browsing/editing: Works fine, but all JS fails due to a script execution error (which at least doesn't cause a pop-up).
Security: Secunia reports 0 unpatched vulnerabilities (out of 26).
Usage: <0.25%
Recommendation: Add to blacklist
== Opera 10.x-12.x ==
Last release in series: April 2014
Browsing/editing: Works fine, including advanced features like MediaViewer (except for 10.x)
Security: No unpatched vulnerabilities in 12.x series according to Secunia, 2 unpatched vulnerabilities in 11.x ("less critical") and 1 unpatched vulnerability in 10.x ("moderately critical")
Usage: <1%
Recommendation: Maintain basic JS support, but monitor situation re: 10.x and add that series to blacklist if maintenance cost too high
== Firefox 3.6.* ==
Last release in series: March 2012
Browsing/editing: Works fine (MediaViewer disables itself)
Security: 0 unpatched vulnerabilities according to Secunia
Recommendation: Maintain basic JS support
== Firefox 3.5.* ==
Last release in series: April 2011
Browsing/editing: Works fine (MediaViewer disables itself)
Security: 0 unpatched vulnerabilities according to Secunia
Recommendation: Maintain basic JS support
== Safari 4.x ==
Last release in series: November 2010
Browsing/editing: Works fine
Security: 1 unpatched "highly critical" vulnerability according to Secunia ("exposure of sensitive information")
Recommendation: Maintain basic JS support, but monitor
== Safari 3.x ==
Last release in series: May 2009
Browsing/editing: Completely messed up, looks like CSS doesn't get loaded at all
Security: 2 unpatched vulnerabilities, "highly critical"
Usage share: Usage reports for Safari in [3] are broken, all Safari versions are reported as "0.0". However, [4] suggests that Safari 3 usage is negligible/non-existent.
Recommendation: Styling issue may be worth investigating in case it affects other browsers and/or is JS-caused. Otherwise probably can be safely ignored.
[1] http://lists.wikimedia.org/pipermail/wikitech-l/2014-August/077952.html [2] https://gerrit.wikimedia.org/r/#/c/152122/ [3] http://stats.wikimedia.org/wikimedia/squids/SquidReportClients.htm [4] http://stackoverflow.com/questions/12655363/what-is-the-most-old-safari-vers... -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
One thing that comes to mind is that CentralNotice is dependent on JS. Blacklisting browsers means they won't see CentralNotice banners at all.
This isn't really a big concern for Fundraising: it's a small percentage of views, and not having to support these browsers in our increasingly sophisticated banners is probably a blessing. However I wonder about other uses of CentralNotice e.g. letting people know about the recent Privacy Policy and Terms of Use changes. Where we not only want to reach as many users as possible, but may also have legal obligations to.
I'm not really sure how big an issue this is, or how to solve it.
On 6 August 2014 19:52, Erik Moeller erik@wikimedia.org wrote:
Following up on disabling JavaScript support for IE6 [1], here is some additional research on other browsers. I'd appreciate if people with experience testing/developing for/with these browsers would jump in with additional observations. I think we should wait with adding other browsers to the blacklist until the IE6 change has been rolled out, which may expose unanticipated consequences (it already exposed that Common.js causes errors in blacklisted browsers, which should be fixed once [2] is reviewed and merged).
As a reminder, the current blacklist is in <resources/src/startup.js>.
As a quick test, I tested basic browsing/editing operation on English Wikipedia with various browsers. Negative results don't necessarily indicate that we should disable JS support for these browsers, but they do indicate the quality of testing that currently occurs for those browsers. Based on a combination of test results, unpatched vulnerabilities and usage share, an initial recommendation for each browser follows.
Note that due to the heavy customization through gadgets/site scripts, there are often site-specific issues which may not be uncovered through naive testing.
== Microsoft Internet Explorer 7.x ==
Last release in series: April 2009
- Browsing: Most pages work fine (some styling issues), but pages with
audio files cause JavaScript errors (problem in TMH).
- Editing: Throws JS error immediately (problem in RefToolbar)
Both of these errors don't occur in IE8.
Security vulnerabilities:
Secunia reports 15 out of 87 vulnerabilities as unpatched, with the most serious one being rated as "moderately critical" (which is the same as IE6, while the most serious IE8 vulnerability is rated "less critical").
Usage: <1%
Recommendation: Add to blacklist
== Opera 8.x ==
Last release in series: September 2005
Browsing/editing: Works fine, but all JS fails due to a script execution error (which at least doesn't cause a pop-up).
Security: Secunia reports 0 unpatched vulnerabilities (out of 26).
Usage: <0.25%
Recommendation: Add to blacklist
== Opera 10.x-12.x ==
Last release in series: April 2014
Browsing/editing: Works fine, including advanced features like MediaViewer (except for 10.x)
Security: No unpatched vulnerabilities in 12.x series according to Secunia, 2 unpatched vulnerabilities in 11.x ("less critical") and 1 unpatched vulnerability in 10.x ("moderately critical")
Usage: <1%
Recommendation: Maintain basic JS support, but monitor situation re: 10.x and add that series to blacklist if maintenance cost too high
== Firefox 3.6.* ==
Last release in series: March 2012
Browsing/editing: Works fine (MediaViewer disables itself)
Security: 0 unpatched vulnerabilities according to Secunia
Recommendation: Maintain basic JS support
== Firefox 3.5.* ==
Last release in series: April 2011
Browsing/editing: Works fine (MediaViewer disables itself)
Security: 0 unpatched vulnerabilities according to Secunia
Recommendation: Maintain basic JS support
== Safari 4.x ==
Last release in series: November 2010
Browsing/editing: Works fine
Security: 1 unpatched "highly critical" vulnerability according to Secunia ("exposure of sensitive information")
Recommendation: Maintain basic JS support, but monitor
== Safari 3.x ==
Last release in series: May 2009
Browsing/editing: Completely messed up, looks like CSS doesn't get loaded at all
Security: 2 unpatched vulnerabilities, "highly critical"
Usage share: Usage reports for Safari in [3] are broken, all Safari versions are reported as "0.0". However, [4] suggests that Safari 3 usage is negligible/non-existent.
Recommendation: Styling issue may be worth investigating in case it affects other browsers and/or is JS-caused. Otherwise probably can be safely ignored.
[1] http://lists.wikimedia.org/pipermail/wikitech-l/2014-August/077952.html [2] https://gerrit.wikimedia.org/r/#/c/152122/ [3] http://stats.wikimedia.org/wikimedia/squids/SquidReportClients.htm [4] http://stackoverflow.com/questions/12655363/what-is-the-most-old-safari-vers... -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 26 Aug 2014, at 16:34, Peter Coombe pcoombe@wikimedia.org wrote:
One thing that comes to mind is that CentralNotice is dependent on JS. Blacklisting browsers means they won't see CentralNotice banners at all.
This isn't really a big concern for Fundraising: it's a small percentage of views, and not having to support these browsers in our increasingly sophisticated banners is probably a blessing. However I wonder about other uses of CentralNotice e.g. letting people know about the recent Privacy Policy and Terms of Use changes. Where we not only want to reach as many users as possible, but may also have legal obligations to.
I'm not really sure how big an issue this is, or how to solve it.
I don't have a legal-relevant answer, but for what it's worth, this isn't new.
We've always blacklisted older browsers. This is just our annual updating of what that blacklist is.
This in order to prevent maintenance costs from increasing exponentially. Because, new browsers are coming out continuously, keeping support for old browsers means we're supporting more, not the same, as last year. And it allows us to start using newer technologies and stop having to account for older browser bugs in new features we develop. This includes usage of existing features, such as CentralNotice banners indeed. Each banner that's made is paying a small human-resources price ensuring it works in all supported browsers.
As for the legal part, I'm not a lawyer, but in my limited knowledge two things come to mind:
* Is announcing policy changes legally required? Or is it a recommended courtesy? Many policies contain stuff like "We reserve the right to change this at any time.". Does ours? And either way, visitors didn't explicitly agree to the version that applied to them either, so one would think that whatever legal mechanism allows that, also means we can't be required to inform them about changes.
* These kind of announcements probably shouldn't require javascript if that's the case. Remember, even if we'd support every single browser ever, if they don't have javascript or if they disabled javascript, the banners won't appear either. Would we be required to display the banner in a way that doesn't require javascript? Quite a few extremist (sorry) out there have javascript disabled in their browser. We use javascript at all due to technical restrictions related to site performance (changing the banners without purging every single article on every wiki from cache, js seems the only way to project changed content separately).
-- Krinkle
Interesting read: http://www.theverge.com/2014/8/19/6044679/the-six-lawsuits-that-shaped-the-i...
wikitech-l@lists.wikimedia.org