Same random finds while working on something else. I carefully
checked and made sure these methods are actually called without the
optional parameter.
Change-Id: Iab36fd130258322985b5d6e7f8e1f7b4ee235ba2
Parsing it in the RL module caused the module cache key to depend
on the parse, which is slow and makes ResourceLoader sad. The usual
approach for solving this (I206bb05d28) can't be used, because of
how EditPage generates this message.
Bonus #1:
Generate the message for the correct page title. MediaWiki allows
customizing it per-namespace or even per-title, which we haven't
supported before.
Bonus #2:
Pass the context for message localisation (depends on I5f7c77970d).
EditPage::getCopyrightWarning() was parsing messages without the
interface flag, causing some needless processing elsewhere.
Depends-On: I5f7c77970d0525c0ff394f8bd72c69dcb5d00623
Bug: T298822
Change-Id: Iaa626f0e6379a5a370f9c465cea8528bb5bde7f7
Prevents accidentally treating plain text or user input
as HTML, which could be an XSS vulnerability.
Change-Id: Id4af48447a0907962a57340cb60aca08df9cc505
This was used when we used to pass API errors to showMessage, but
is now unused by the two remaining users (missing edit summary, and
"press ctrl+enter to submit").
Change-Id: I8a6b4db78d4e451cf3ec85fcdfd8293328aaaa3c
Bring in ve.dm.MWInternalLinkAnnotation.static.getTargetDataFromHref
and ve.resolveUrl, so that the file has no dependencies on VE.
Change-Id: I03bc455d5484a6c51f3fa2397c64936b829fe7e3
Once upon a time, we added code to filter <style> and <link> elements
from the rendering of templates in visual editor, because attempting
to cut them would crash Chrome (T52043).
There are at least three reasons why that is not needed here:
* The preview is not editable text, so you can't cut from it
* The Chrome bug was fixed 7 years ago anyway
* We now use TemplateStyles in articles and they work just fine
The code was added here in 9dd638a5ab
without explanation, I think it was just done for consistency.
Bug: T212085
Change-Id: I0712e3a081f04d0b74cda47652fa6eb118dfe7b2
* Add a postWikitext method and split out postContent
from postHtml
* Move saveSuccess handling into postContent promise
* Connect promise directly to saveComplete instead
* Pass whole response.visualeditoredit object, instead
of splitting into variadic arguments for saveComplete.
* [DEPRECATION] Make serialize return the postHtml promise
and deprecate passing a callback.
Change-Id: I905737515578000b2b87214c92e8b9fe9e82f6b7
A @method annotation is only necessary when the docblock is not
directly followed by a function declaration (in which case JSDuck
assumes it documents a property), e.g. when defining an abstract
function or referencing a function from another library.
I verified that JSDuck generates exactly the same output before and
after this change (docs/data-<hash>.js files are identical).
Change-Id: I7edf51a8560ab9978b42800ab1026f0b5555c3bf
Since I7f6fd7ee9 it is now possible for the options bar to be
completely empty if the user is logged out. In this case hide
it and only show it again when the character limit needs to be
show.
Ideally we wouldn't have the height change, but it is quite rare
that a user gets to 400 chars and is logged out.
Bug: T228165
Change-Id: Ifbdf352afcbf4e549889e04fdb70fd30ce233aad
When previewing/reviewing changes, the "Return to save form" button
now replaces the "Resume editing" button in the top-left corner (and
receives the 'back' flag). Effectively, you tap 'back' once to go back
to the edit summary, and twice to go back to editing. This seems to me
like a much more natural interaction than two separate buttons.
Bug: T225021
Bug: T227049
Bug: T227857
Change-Id: Id27ccf06923c8aa86b1c1a9292bc43bb825ce6c8
Same thing as Ifb49ede450cabdcd8303b298b62f2ac632809b53, for
a slightly different case that we missed.
Bug: T221289
Change-Id: I0ca287af87e1058620fbed75a50d40f01513a567
Incorrect order of operations caused all metadata to be removed before
we looked for the 'mw:PageProp/redirect' metadata item.
Bug: T221686
Change-Id: Ifcf210ad772babe1019fd0cfbaa7bd60d0e7e5fe
No idea what causes it, but I've seen a similar issue when working on
Ic35f084d019afd1782292c831765ceb1444fb14a (in OOUI) and this hack
worked there too.
Bug: T219680
Change-Id: Ifb49ede450cabdcd8303b298b62f2ac632809b53