We got a report of permanent JS problems on IE 11 on ro.wp [1], which in theory [2] is still supported. See comment below for details on the console output. This seems to be different from the wikidata issue reported at [3] (at least I get a different error)
[1] https://ro.wikipedia.org/wiki/Wikipedia:Cafenea#Probleme_cu_interfa.C8.9Ba
[2] https://www.mediawiki.org/wiki/Compatibility#Browser_support_matrix
[3] https://www.wikidata.org/wiki/Wikidata:Contact_the_development_team#A_bug.3F
I also get this in debug mode. Blows up on this in /CentralNotice/resources/subscribing/ext.centralNotice.display.js:
/**
* Register that the current page view is included in a test.
* @param {string} identifier A string to identify the test. Should not contain
* commas.
*/
registerTest( identifier ) {
cn.internal.state.registerTest( identifier );
},This looks like obviously invalid syntax to me… perhaps it does something in ES6 that IE 11 doesn't support, but it probably doesn't do what the author intended.
Seems to be caused by https://gerrit.wikimedia.org/r/#/c/290361/4
(That patch introduces the same kind of mistake in resources/subscribing/ext.centralNotice.display.state.js, too. This is apparently ES6 "concise methods" syntax, so it actually does what the author intended, but it's only supported by some browsers, causing a syntax error in others.)
This is also affecting UploadWizard, which I maintain, and people are starting to blame it (https://commons.wikimedia.org/wiki/Commons:Upload_help#Can.27t_use_new_upload_wizard), and no one responsible for CentralNotice seems available (I think the whole team is in the US and probably still asleep). I'm going to see if I can fix it.
Change 291246 had a related patch set uploaded (by Alex Monk):
Revert "Update CentralNotice submodule"
Mentioned in SAL [2016-05-27T15:02:01Z] <krenair@tin> Synchronized php-1.28.0-wmf.3/extensions/CentralNotice/resources/subscribing: rv due to T136387 (duration: 00m 36s)
I can confirm JavaScript now works in IE 11. Waiting for confirmation on the other browsers.
It should be coincided with a change to CentralNotice's JSHint configuration to ensure ES6 syntax is considered invalid - as to avoid regressions in the future.
Yeah, T136408: Update CentralNotice JSHint config to restrict syntax to ES3 (disallow ES5 or ES6) was filed about that.
Change 291264 had a related patch set uploaded (by Ejegg):
jshint, gruntfile, and compatibility fixes
Change 292279 had a related patch set uploaded (by Bartosz Dziewoński):
Revert "Update CentralNotice submodule"
CentralNotice seems to have some unusual deployment method that I don't understand. Can you folks please take care of doing whatever needs to be done to ensure this doesn't regress again?
Change 292282 had a related patch set uploaded (by Ejegg):
Merge branch 'master' into wmf_deploy
Change 292285 had a related patch set uploaded (by Ejegg):
Revert "ext.centralNotice.display: API for registering tests"
Change 292285 merged by Ejegg:
Revert "ext.centralNotice.display: API for registering tests"
Sorry! https://gerrit.wikimedia.org/r/292285/ reverts it in the wmf_deploy branch, source of the -wmf.x branch submodules. Next merge into wmf_deploy will have ES3 enforcement in effect.
Change 292282 abandoned by Ejegg:
Merge branch 'master' into wmf_deploy
Reason:
too much, too soon
Change 292304 had a related patch set uploaded (by Awight):
Update extensions/CentralNotice submodule
Mentioned in SAL [2016-06-02T00:26:39Z] <awight@tin> Synchronized php-1.28.0-wmf.4/extensions/CentralNotice: Fix for T136387 (duration: 00m 38s)
Change 292368 had a related patch set uploaded (by AndyRussG):
jshint, gruntfile, and compatibility fixes (partial, wmf_deploy branch only)
Change 292401 had a related patch set uploaded (by AndyRussG):
Revert "jshint, gruntfile, and compatibility fixes"
Change 292402 had a related patch set uploaded (by AndyRussG):
Re-apply "jshint, gruntfile, and compatibility fixes" (part 1)
Change 292403 had a related patch set uploaded (by AndyRussG):
Re-apply "jshint, gruntfile, and compatibility fixes" (part 2)
Change 292404 had a related patch set uploaded (by AndyRussG):
Re-apply "jshint, gruntfile, and compatibility fixes" (part 1)
50b7a37df47a1ef798efdfc1186d66c9d75c1d51 is the current rev deployed for CentralNotice. A spot check shows that it is the version that is live on the application servers.
Can this be removed as a wmf.4 blocker?
Change 292368 abandoned by AndyRussG:
jshint, gruntfile, and compatibility fixes (partial, wmf_deploy branch only)
Reason:
See instead I91de8b2dfa
Change 292401 abandoned by AndyRussG:
Revert "jshint, gruntfile, and compatibility fixes"
Reason:
Unneeded, was part of planned administrative curiosities
Change 292402 abandoned by AndyRussG:
Re-apply "jshint, gruntfile, and compatibility fixes" (part 1)
Reason:
Unneeded, was part of planned administrative curiosities
Change 292403 abandoned by AndyRussG:
Re-apply "jshint, gruntfile, and compatibility fixes" (part 2)
Reason:
Unneeded, was part of planned administrative curiosities
Change 292404 merged by jenkins-bot:
Re-apply "jshint, gruntfile, and compatibility fixes" (part 1)
Change 292503 had a related patch set uploaded (by Awight):
Update extensions/CentralNotice submodule
Mentioned in SAL [2016-06-02T23:59:36Z] <awight@tin> Started scap: Deploying labtestwiki AuthManager config; Enabling Popups experiment; CentralNotice fixes for T136408, T136387; Special:Notifications fixes
Mentioned in SAL [2016-06-03T00:24:45Z] <awight@tin> Finished scap: Deploying labtestwiki AuthManager config; Enabling Popups experiment; CentralNotice fixes for T136408, T136387; Special:Notifications fixes (duration: 25m 08s)