ConfirmEdit should be added as a phan dependency, so thing like this no
longer happen in the future.
Bug: T296287
Change-Id: Ic9942b3a6d872c0d3c0e3a53d9462df6f82b06c6
This isn't strictly WikiEditor business, but other logging is done
here, and soon real-time previewing will be built in WikiEditor,
so it makes sense to keep all the logging for the different types
of preview together.
Bug: T290521
Change-Id: If42697e43c1bec95d743244d0acf96c47df8b681
Refactor the code for selecting the first match, so it can also
be called from the look-like button method — this will be changed
once the whole link-inserter dialog is OOUI.
Bug: T295517
Change-Id: I56b289dbf07707b0391b263464bdfd6307142574
Use CacheKeyHelper to get a status from SimpleCaptcha instead of it.
Bug: T275710
Depends-On: I7942ccd6b58584f436f872bf7c9deb63ab84482a
Change-Id: Id35ef3bcf30ddc0581c79cc10fa80e54d5352758
This change replaces in the HTML
<input type="hidden" name="wikieditorJavascriptSupport" id="wikieditorJavascriptSupport" value="" />
by
<input id="wikieditorJavascriptSupport" type="hidden" name="wikieditorJavascriptSupport"/>
but the behavior is still the same.
Change-Id: Icc9b9c9480be3b220148466d3f93746e14de280a
The UTF-8 normalization of getVal is not needed here.
Also explicit check for !== null instead of truthy because in PHP is
"0" != true.
Change-Id: I77a8a2c149045f677ff2a1f0e42d9ca9dccde321
The latter is deprecated, and the former is just a wrapper for
UserEditTracker::getUserEditCount().
Bug: T290521
Change-Id: Id3f2b9a007fe299d74d5957cbd3e31b11adb2790
Log on every click (by any means, including accesskey) of the
main editing preview button.
Bug: T290521
Change-Id: I67d821445c5e39034bcb121beccf17a765a311ed
* #wikieditor-toolbar-link-int-text was removed in I17f34a8cbf72b80f3916581867e5828d9b129789
* .wikiEditor-template-dialog-fields was removed in I47119d6cfdde4b40ff5b07be0c7d327b80598142
Change-Id: If669eb3fa8e1401d640c879f808c097682c30f31
The HTML template is no longer required, as all three fields are
now OOUI and so provide their own HTML.
Bug: T289214
Change-Id: Id7e02119f00e30244b8dc2048c1f694500151b25
Added in https://phabricator.wikimedia.org/rSVN56198 in 2009
It seems to have no user-visible effect, and resizing is still working
as expected for the dialogs that use it.
OTOH, this logic is broken, since it doesn't account for elements hidden
via classes or anything other than inline style. For instance, if there
are OOUI text fields inside the dialog, the logic in resize() will add
style="display:inline"
to the empty icon elements, which would then cover part of the input
field.
Bug: T293065
Change-Id: If53937dd9e80835774ef936c5aa19f78c7266ca7
Following-up on I9fb7e66bf925eb9a8260d6245d2a7db54a7a2fec
this converts the link-text field to OOUI.
Bug: T289214
Change-Id: I17f34a8cbf72b80f3916581867e5828d9b129789
In order to get a better look-up experience (images, description,
redirects, and disambigutation pages listed last), swich from
a custom title-autocomplete input (that used jquery.suggestions)
to OOUI's standard one (which is used in a bunch of other places
in MediaWiki).
This means a fair bit of code can be deleted from
jquery.wikiEditor.dialogs.config.js, and some of it moved to
the new OOUI classes.
This patch aims to be the minimum required, and so leaves a few
things for subsequent patches (such as converting the other parts
of the insert-link dialog to OOUI).
Bug: T289214
Change-Id: I9fb7e66bf925eb9a8260d6245d2a7db54a7a2fec
