Updated mediawiki/extensions
Project: mediawiki/extensions/CentralNotice  df21c60241ced2f008c7935de2bd4ff683f0c65d

Clean up of random JS curiosities

* Access global variables as global variables.

  Some places whitelisted mediaWiki as global, other whitelisted
  mw as global, other whitelisted 'window' as global and accessed
  'window.mw'.

  Standardise on accessing globals directly. Using Window as a
  proxy has no purpose, it only obfuscates the code and makes it
  harder to statically detect mistakes (e.g. JSHint will no longer
  notice use of a global that doesn't exist, e.g. when misspelling
  'location', 'mw', or 'mediaWiki').

* Consistently use location as a global, too.

  Again, there is no point whatsoever in using 'window.location'.
  And no, half the internet using it is not an excuse, that's half
  the internet copying a moron from 10 years ago. Or, more likely,
  a smart guy using it 10 years ago with an if-statement around it
  and then half the internet copying it without the if-statement
  thus making it look not very smart or useful at all.

  All browser support location, and even if it were undefined
  somehow, window.location does not help one bit.

* Consistently use location.href or location.replace to navigate.

  It's the version that's been around the longest, supported
  widest, and standardised.

  Variations:

  location =
  location.assign()
  document.location =
  document.URI =
  document.documentURI =
  (and each with 'window.' in front)

  location.replace() is the only one worth keeping separate,
  because it is functionally different (does not produce a new
  history entry, so user can't navigate "Back" to the previous
  url). While I doubt whether this was on purpose, I won't change
  that in a clean up commit.

* Global confusion

  bannereditor.js whitelisted 'mw' but then used 'mediaWiki'
  inside somewhere.

  bannereditor.js used alert() as global variable but bypassed
  the detection for unknown global variables by using window.

* Document weird unexpected bitwise operations

  The mixin file return a boolean value, but this didn't seem
  to be used by anything. Turns out BannerRenderer.php includes
  this and uses the boolean value as a number in a bit field
  and then uses &= to assert all snippets returned true (well 1).

  Document this and remove the implicit casting by just using 0
  and 1 directly. This doesn't change the behaviour as &= was
  casting it to 0 or 1, so the end result will remain unchanged.

Change-Id: I09bf70f0e09382dbe816bf0bb96a42c632ab13be