Added test for parsing &nbsp; in wikilinks.

Change-Id: I3aa2c76e6fb03c3acaf2edb9fbeca6fd70c556c2
Bug 40668 - "Return to Array." when logging in

Change-Id: I847684cdc474d0694bf4fa5eddaa0d0b19e7be4e
Merge "Added test for parsing &nbsp; in wikilinks."
(bug 40448) Replace legacy mwsuggest with mediawiki.searchSuggest

The module has been broken for a while now, but nobody noticed
because in plain core it is disabled by default, and in the
bundle we ship with Extension:Vector (and its SimpleSearch).

This commit removed the mediawiki.legacy.mwsuggest module (and
related components that become obsolete with its deletion) and
replaces it with the new mediawiki.searchSuggest module, which is
based on SimpleSearch from Extension:Vector (where it will be
removed soon).

The following and all references to it in core have been removed,
I also made sure that they weren't used in any of extensions/*.
Only matches in extensions/Settings and some file that dumped the startup module, and in extensions/Vector which are addressed in
I1d5bf81a8a0266c51c99d41eefacc0f4b3ae4b76.

Had to make a few updates to jquery.suggestions to make it work
in other skins. So far it was only used in Vector, but now that
it is used in mediawiki.searchSuggest, I noticed several issues
in other skins. Most importantly the fact that it assumed the
default offset was from the right corner, which isn't the case in
Monobook where the search bar is on the left (in the sidebar).

It now detects the appropiate origin corner automatically, and
also takes directionality of the page into account.

It also uses the correct font-size automatically. Previously it
used font-size: 0.8; but that only works in Vector. Every skin
seems to have its own way of making a sane font-size. In Monobook
the <body> has an extra small font-size which is then fixed in
div#globalWrapper, and in Vector it is extra large, which is then
fixed as well deeper in the document. Either way, the size on
<body> can't be used, and since this suggestions box is appended
to the <body> (it is a generic jQuery plugin without knowledge of
the document, and even if we could give it knowledge inside
the configuration, it'd have to be per-skin). So I removed the
Vector specific font-size and let it handle it automatically.
This was needed because it is now used in all skins.

Removed modules:
* mediawiki.legacy.mwsuggest:
  > Replaced with mediawiki.searchSuggest.

Removed messages:
* search-mwsuggest-enabled
* search-mwsuggest-disabled
  > No longer used.

Removed mw.config.values:
* wgMWSuggestTemplate
  > Obsolete.

* wgSearchNamespaces
  > Obsolete.

Removed server-side settings:
* $wgEnableMWSuggest
  > Suggestions are now enabled by default and can be disabled
    through the user preference `disablesuggest` still.
    They can be disabled by default site-wide or hidden from
    prefs through the standard mechanisms for that.

* $wgMWSuggestTemplate
  > Obsolete.

Removed methods
* SearchEngine::getMWSuggestTemplate()
  > Obsolete.

Filters:
 $ ack mwsuggest -i -Q --ignore-dir=languages/messages
 $ ack wgSearchNamespaces -Q

Message changes:
* vector-simplesearch-preference
  > It was wrong, it didn't activate search suggestions, that
    was handled by the Vector extension. This preference in
    MediaWiki core controls whether the SimpleSearch bar HTML
    and CSS will be used (e.g. the rectangle search box with
    the magnifying class instead of the browser-default input
    field with the plain submit buttons).

* searchsuggest-search
* searchsuggest-containing
  These come from Extension:Vector message and should be imported
  by translatewiki:
  - vector-simplesearch-search
  - vector-simplesearch-containing

Change-Id: Icd721011b40bb8d2c20aefa8b359a3e45413a07f
jquery.byteLimit: Rewrite (fix bug 38158, bug 38163)

It used to be fairly simply and that seemed good enough. Listen
on keypress, get current value, add character from key code in
event object, and calculate the byteLength. If it is too long,
preventDefault().

However there were so many edge cases (too many of them to be
considered edge cases) where this failed whereas the native
maxLength handling was fine.

For example:
 - Cut and paste
 - Selecting text and replacing or removing it (by any of the
   methods on this list)
 - Custom javascript input methods (e.g. Narayam)
 - Spelling suggestions and corrections
 - Drag and drop
 - etc.

Now it acts on changes after the fact.

I considered building in a timeout loop in addition to this so
that when javascript gadgets change the input value it would
detect it, however I'd like to hold that off for now. We can
add that later if needed. For now scripts are expected to fire
the 'change' event if they change it, which seems reasonable.

The only challenge that it creates, however, is the need for
basic history reconstruction. Figure out what was already there
and what is new, and cut down the new part until the total sum
satisfies the limit.

This is the same behavior that WebKit browsers (and others) have.
e.g. of "barbaz" is pasted between "f" and "o" in "foo" with a
maxLength of 5, then the resulting string will be "fbaoo".

Also fixed bug 38158 while at it. Filed an upstream bug against
webkit/Chrome but was wont fixed. Either way, we'd have to be
compatible for a little while with old WebKit builds out there
(iOS 3, Safari 5, etc.).
http://code.google.com/p/chromium/issues/detail?id=136004

Use removeAttribute('maxlength') to let the browser internally
reset the maxLength property. Resetting it directly (to undefined
or with `delete el.maxLength') does not work and casts it to 0,
which blocks the input field entirely.

Updated unit tests, and also removed the "type=text" code
afterwards which that doesn't work in IE (Internet Explorer does
not support dynamic changing of input types), needs to be in the
HTML directly. So far it was passing in IE because 'text' is the
default. Tests now use attr('maxlength') everywhere for
consistency, though properties work the same. Browsers
synchronize these things (just like the "class" attribute and
"className" property).

References:
* Fixes bug 38158: Unexpected 0 maxLength.
* Fixes bug 38163: Incorrect limiting of input when using input
  methods other than basic per-char typing.
* Follows-up: 39cb0c19
* Supersedes: I70d09aae

Change-Id: I9c204243d0bdf7158aa86a62b591ce717a36fe27
Merge "(bug 40448) Replace legacy mwsuggest with mediawiki.searchSuggest"
Additional indent-pre and template interaction tests.

Change-Id: I445247130dea266beb8b94e2fa1f039f1886446a
Merge "Bug 40668 - "Return to Array." when logging in"
Merge "Additional indent-pre and template interaction tests."
Fixup release notes

* This section shouldn'tve been moved to the 1.21 file, because
  the change that added it (4d4bfc27a1bedf6b0d1670707ac812fe36fe85ad)
  added it to REL1_20 for back porting (which happened).

Change-Id: I1128691e330bf816cd1bb7d8c8e3e665f919272c
Removed __NOHEADER__ magic word

Followup that was not done by anybody in 4 years, see r41994
Reported in http://translatewiki.net/wiki/Thread:Support/MediaWiki_magic_word_"noheader"

Change-Id: Ieded9ca281762c2c42e26c7cfe7669580cbbac62
Sane whitespace

Change-Id: I849e9e672e50f033a24b5b42db93659d6e5fe899
Merge "Removed __NOHEADER__ magic word"