Deprecate the unnamespaced version and move it to includes/compat.
Bug: T147167
Depends-On: I39c805bfb98b32f32f3d0dc1eee9e823afe1c21a
Change-Id: I3780c7adf51683f3f7adb35a88f9a25a0a2e2530
This affects Special:Preferences, where there will no longer be an
empty <table class="mw-htmlform-nolabel"><tbody></tbody></table>
after every toplevel section heading.
Change-Id: Icb6fe957024843f2b08720715054b9afb657f395
For some varargs a variable name is added with suffix ,... as seen for
many other varargs
Some @param are swapped, because there are in the wrong order
Enable Sniff MediaWiki.Commenting.FunctionComment.ParamNameNoMatch
Change-Id: I60fec6025bce824d5c67563ab7b65ad6cd628ad8
It adds the ability to replace the current section ID escaping
schema (.C0.DE) with a HTML5-compliant escaping schema that is
displayed as Unicode in many modern browsers.
See the linked bug for discussion of various options that were
considered before the implementation. A few remarks:
* Because Sanitizer::escapeId() is used in a bunch of places without
escaping, I'm deprecating it without altering its behavior.
* The bug described in comments for Parser::guessLegacySectionNameFromWikiText()
is still there in some Edge versions that display mojibake.
Bug: T152540
Change-Id: Id304010a0342efbb7ef2d56c5b8b244f2e4fb2c5
And auto-fix all errors.
The `<exclude-pattern>` stanzas are now included in the default ruleset
and don't need to be repeated.
Change-Id: I928af549dc88ac2c6cb82058f64c7c7f3111598a
I was bored. What? Don't look at me that way.
I mostly targetted mixed tabs and spaces, but others were not spared.
Note that some of the whitespace changes are inside HTML output,
extended regexps or SQL snippets.
Change-Id: Ie206cc946459f6befcfc2d520e35ad3ea3c0f1e0
New widget and html form field, which allows selecting multiple
users using convenient single-line input (CapsuleMultiselectWidget)
Bug: T131492
Change-Id: I7b6ffe7fb47e0a7083e2a956156ab0f142444398
Our 'hide-if' fields are fundamentally incompatible with HTML5 form
validation attributes. If you have a checkbox field A, and field B
that is required, but hidden if A is unchecked - that's impossible to
express with HTML5 form validation. The only thing you can do is
remove the validation on B (or on the entire form).
The field contents are still validated server-side, just like if the
browser did not support HTML5 forms. The validation is also re-enabled
in JavaScript, since we have extra support for 'hide-if' field that
makes them work.
Change-Id: Ia7ffa76965a7c14af9b6d2db007b6255498398d9
It mostly already worked. HTMLForm::trySubmit() needed a little
adjustment to handle things properly.
Change-Id: Ibb17bb61ac0b2d41953249980bc2f23b8a3ae5b6
The conversion of SpecialNewpages to HTMLForm seems to be half-finished.
It's not using HTMLForm to read in the request query, which means we have
to roll our own logic. Kind of defeats the purpose of using HTMLForm in
the first place.
When ProtectedPages is converted to HTMLForm (T117722), it can use this new
field type.
Bug: T12817
Change-Id: I069609fbb37b18c3df25156779ad7ac7cd5d6813
Replacing deprecated `constructive` mediawiki.UI CSS class and OOjs UI
flag with `progressive`.
Bug: T146923
Change-Id: I524b9722ee49692c55bb1f97d34d8a28068716ee
This commit changes the way how HTMLForm handles a Status object
when executed from a request. It now handles, beside the errors,
also the warnings of a Status object and prints them out, wrapped
in a warning box.
The LoginSignupPage uses this feature to show informative warnings
actually as warnings and not as more disturbing error messages.
Error messages should be reserved for errors and only for erros. An
AuthenticationProvider, which returns an UI AuthenticationResponse
can choose, if the given message is an error or a warning message.
This commit also addds a new function to Status, which allows a
developer to split the object into two new Status objects, where one only
contains the errors and the other only the warnings of the origin
Status object (splitByErrorType). StatusValue also has a new function,
splitByErrorType(), to support this.
Bug: T139179
Change-Id: I9a27911613e62b5c4cb86bea40696cb37c4f49c2
ObjectFactory has a hack that constructs an object directly if there are
less than 10 parameters, which there typically is for HTMLForm classes.
This is faster than using ReflectionClass, and whenever ObjectFactory is
updated to take advantage of the splat operator, this will automatically
use it as well.
And use ::class while we're at it.
Change-Id: I7a696c127c237713448b165b9b4faee13f4ff88e
Calling HTMLForm::setFormIdentifier() will set an internal identifier
for this form. It will be submitted as a hidden form field, allowing
HTMLForm to determine whether the form was submitted (or just viewed).
Setting this serves two purposes:
* If you use two or more forms on one page, it allows HTMLForm to
identify which of the forms was submitted, and not attempt to
validate the other ones. (T102114)
* If you use checkbox or multiselect fields inside a form using the
GET method, it allows HTMLForm to distinguish between the initial
page view and a form submission with all checkboxes or select
options unchecked. (T29676)
Bug: T102114
Bug: T29676
Change-Id: Ib6ce3fd8941be86211cff5c6932b5e84982490fa
Add two new HTMLForm methods:
* showCancel( [bool] ) to display a cancel button
* setCancelTarget( Title|string ) to set where it should take
the user.
The cancel button is a simple link formatted as a button.
This is faster than a real button (skips an unnecessary
submit and redirect) and avoids some UX problems:
* when clicking on a real button, HTML5 or JS validators
might prevent submission, which does not make sense for cancel
* form field values might get saved by the brower, which again
does not make sense for cancelling
Use the cancel button for Special:ChangeCredentials.
Bug: T136809
Change-Id: Ieb80e2ff36751abc6f00e2a02926fe9800666a8b
'notice', 'notice-message' and 'notice-messages' can be used
as a parameter to the HTMLForm field to show the notices.
Only added implementation for OOUI forms because I'm not sure
what to do for others.
Bug: T104423
Change-Id: I512f3936bc3335df1bdf76505cfc39da6be99bed
Improves Ida647973a which unified message handling for form fields
but did not make the functionality available to HTMLForm itself.
Change-Id: I2e6195ba13afbd8b993acb47409fab1be91c547e
Fix a test in If4e0dfb : in the unlikely but valid case when
some form field object returns null from loadDataFromRequest,
handle it correctly and do not replace it with the default value.
Bug: T133163
Change-Id: Id8b48cfc6288d11a79a5838e72bb80b14137a7b0
Visually, this only affects OOUIHTMLForm, in other kinds of forms
the element has no height anyway.
Change-Id: I90e73c49fbefec23532368848bb30b2e7b69075c
- do not return anything when the button was not clicked
- return boolean true (instead of the button text) when it was clicked
Unbreaks submit fields which currently don't return anything so there is
no easy way to tell whether they have been clicked.
Change-Id: If4e0dfb6ee6674f0dace80a01850e2d0cbbdb47a
*-message(s) settings were documented as message key strings or arrays
of message key strings, but some actually accepted [key, params...]
arrays as well. They did not accept Message objects, which would be
the cleanest and most flexible method of message passing.
The patch adds a new method to process these settings (which accepts
a messages key, a [key, params...] array or a Message object), and
makes all *-message(s) usage call that.
Change-Id: Ida647973a58bea83fdbd53335e63b5a8615c16e4
This change adds a new method setAutocomplete to the class HTMLForm.
This method allows to set the HTML attribute autocomplete for the form.
This change uses this method to set autocomplete="off" for the preferences form.
Without autocomplete="off" the selections in the preferences get cached in
the browser. This can lead to wrong selected options when the settings get
changed on an other way, for example via API.
Bug: T131047
Change-Id: I2920383b5b8cfca3f1d546315f202985edf417d8
This reverts commit bc9b2162cb.
Just in case, this change[1] isn't merged before the next wmf-release (12 January) to unbreak the form.
[1] I3e0c02155428ae400bc3a6d3ed2e66e69ee441fa
Change-Id: I1a594485fbf8c75b4199df2e255dedc7fb90e74d
It already used HTMLForm for the main form, but the form, which asked for
the username didn't.
Converted the "Enter username" form to use HTMLForm and show it, if no user-
name was passed to the form, show the main "Send e-mail" form, instead.
Extra points:
- Let HTMLForm::setSubmit*() function return it's own HTMLForm instance
Bug: T117791
Change-Id: I6231577047c93781496e0f8af6809e2ef49e662a
Extra points:
* Add error message, when $input was not fiven (previous behaviour was, that
the form was simply displayed again.
Bug: T117748
Change-Id: Ibe4e010fe9d0b2520c2d6964bd66cb2bca3b0bc7
Submit buttons, whether via HTMLForm::addButton() or HTMLSubmitField,
are difficult to use effectively when the submitted value has to match
the internationalized display label. HTML5 (and HTML4 for that matter)
already has <button> that does what we need, we just need to actually
use it.
But for IE6 and IE7, we can't use <button> because the browser doesn't
handle them correctly. Sniff those browsers to avoid their bugginess
(which the OOUI version should have been doing already for IE6, but
wasn't).
Bug: T121584
Change-Id: I7e15331efb162275c4116bcae61f19d6b884cbe3
It's a dropdown select with the ability to add custom options, or a
text field with input suggestions, whichever you prefer.
This is meant to be a replacement for HTMLSelectOrOtherField and
HTMLAutoCompleteSelectField.
In regular HTML mode, it uses HTML5 `<datalist>` element with no
custom JavaScript. This is supported by a wide range of browsers
(IE 10+, modern Firefox and Chrome, Opera 12+).
In OOUI mode, it uses a ComboBoxInputWidget.
Depends on: I14b40884f185fb4e5
Bug: T118119
Change-Id: I954d3d24ed4efe90be9596a1bd9586ba3aee1e23
Hidden elements doesn't need an extra element in the DOM, but OOUIHTMLForm
would render one, wrapped into a fieldLayout div.
Fix this by adding the possibility to bypass the output, and only construct
a HTMLFormField element and run the output method.
Bug: T117768
Change-Id: I8c9d2ff862f1b14d72a9bb9e1a51e8745af6d1f4
HTMLFormField subclasses are supposed to handle error display but
some (like hidden fields) have no means of doing this. Add
a HTMLFormField::canDisplayErrors() method which can be overridden
to return false, in which case HTMLForm will take care of the
error display.
Also adds a 'rawmessage' message which can be used to wrap
arbitrary text. This can be passed to methods which expect a message
specifier array but do not allow a message object (so the RawMessage
class cannot be used), such as HTMLFormField::trySubmit().
Bug: T112635
Change-Id: I5d73536805774ff2ee0ec64b5442650c4888dc84
* Introduce a getter getHeaderText() and override it in OOUIHTMLForm.
* While we're at it, also introduce getFooterText() (although right
now we have no need to override this one).
* Use both in HTMLForm where appropriate.
Change-Id: I9a7234ed75b024f24e0a087c9c000bb2024b405f
* Introduce a new helper function formatSection() and override it
in OOUIHTMLForm.
* Bonus: Properly construct the form's FieldsetLayout,
thanks to I860a96858c4fcac62d63b46e35a9153f22c0a9c9.
* Bonus: Don't pass silly HTMLForm's classes which don't make
sense in OOUI mode.
Change-Id: I91af6efa8762e9676efea532381292e221255862
Issues with spacing (T107311), probably shouldn't have
been merged right before the branch cut.
This reverts commit 9508c5bd57.
Change-Id: Ibf2ca5a33b8ab0f7381c720c6c92fbfd7a7c819d
Just skip validation if it is a GET form and the current input is an
empty string. Callers will need to check that it is not the empty string
though.
Also make sure HTMLForm::mMethod is always lowercase.
Change-Id: I605f32048fe97eebd7e04b6ffd799759aeb7f31e
Currently, every submit button generated by HTMLForm itself (not via
the descriptor) doesn't have the primary flag and there is no (easy) way
to add it, although this generated submit button is most likely the primary
one.
Add a new function HTMLForm::setSubmitPrimary() to allow a form to set
add the primary flag to this submit button.
Change-Id: I3ce363f995389a87764edb586b4b64ab2b77b0db
To use OOUI for forms with user name autocomplete, the new widget
UserInputWidget interacts like the jQuery pendant (working with css
class "mw-autocomplete-user").
It is also available in HTMLForm as "user".
Example usage: Iaeff912e6437d6ebef0d5b1919ce8cf53a7fd5f1
Change-Id: I9501c85f4288c255bbe3a5284e99b57b6169916f
Changed FormSpecialPage not to call setWrapperLegend() for OOUI
forms to preserve current default behavior.
Bonus:
* Correct documentation of setWrapperLegend() to state that it
HTML-escapes legend text.
* Remove hard-coded class="visualClear" in getFormAttributes().
* Allow setWrapperLegend( true ) to display the wrapper without
legend text.
* Rejigger things so that we can put the legend and "header HTML"
into correct order.
Bug: T103026
Change-Id: I847c5e18ae5469aa3a68cc9fa37b2a6614476ca2
HTMLTitleTextField will automatically validate title input, can
optionally ensure the title is in a specific namespace, is creatable, or
already exists.
The field currently doesn't support GET requests since validation on
empty strings fails.
Bug: T104420
Change-Id: I45718462570d0a523a148c3830b1116b634df050
Rejigger some HTMLForm internals to remove the hardcoded assumption of
using 'mw-ui' classes.
Bug: T98903
Change-Id: Icc20453c999c761b87e19a71ccd43d93b9c1bfa7
* Transform all input fields to use HtmlForm as preparation for enabling
MediaWiki UI eveywhere.
* Remove protected whitespace for HTMLCheckField (adds empty line to div-layout)
* Add a new HTMLForm input field "Text with Button" and "Namespaceselector with Button"
Bug: T73434
Change-Id: I53cc019c3ca94cec8f3c05500d0c604c1af7f688
* Convert Special:LinkSearch to use HTMLForm for preparation of MediaWiki
UI everywhere
* Add support for dir= tag in HTMLTextField
Bug: T73439
Change-Id: I8503c391a40f1654f8570578a9de9015d86c9845
* Prepare the usage of MediaWiki UI.
* Add new HTMLForm output mode "inline" (very close to "raw")
Bug: 71436
Change-Id: I12240aaf624dff5219b344648b20373594b5ec46
…and in general, work with the existing HTMLForm design for defining
display formats, rather than against it.
Breaking changes:
* HTMLForm::isVForm() is now deprecated.
* You can no longer do this:
$form = new HTMLForm( … );
$form->setDisplayFormat( 'vform' ); // throws exception
Instead, do this:
$form = HTMLForm::factory( 'vform', … );
When using FormSpecialPage, override the new getDisplayFormat() method
instead of calling $form->setDisplayFormat() in the alterForm() method.
(Other display formats are not affected, only 'vform'.)
Bug fixes:
* Correctly suppress empty labels for VForm fields
* Correctly disable <fieldset/> wrappers for VForms
Other benefits:
* Reduce code duplication related to $getFieldHtmlMethod
* Introduce HTMLForm::factory() method for constructing HTMLForms
Related cleanup:
* Correctly style 'reset' buttons in MediaWiki UI mode
* Label $wgHTMLFormAllowTableFormat as a mobile-specific hack
* Display checkboxes normally in MediaWiki UI mode (removed weird
override that only broke things). Also, always render checkboxes
in VForms as .mw-ui-checkbox.
* self:: → static::
Bug: T85285
Change-Id: I086a84f1c8cc6a16710709b7806c7f5f96462b32
One call in core already called it non-static
Avoid:
[GlobalTitleFail] MessageCache::parse called by
Message::toString/Message::parseText/MessageCache::parse with no title
set
Change-Id: Ic91e715177c0a4578825640a31ec68ecba3176e0
Pass the HTMLForm parent instance in the constructor so context
is available when parsing a message.
Change-Id: I532c0d95698cbcc57294b9bd2725f33838f393a9
Use HTMLForm instead of self-built table structure, to be
prepared for use with MediaWiki UI.
Bug: 71446
Change-Id: I5c03dc543b910aab27a26a5a223341be50893cf3
Although the classes (e.g. mw-ui-input) are still there,
the style module was not being loaded.
This affects forms that deliberately use VForm even without
wgUseMediaWikiUIEverywhere (since they pre-date it).
This applies at least to PasswordReset, which was added in
d32891d99f (last October).
Bug: 71448
Change-Id: Ieca36c0036d4c93244c533237eddd678564dd3c0
* Apply mw-ui-destructive to Special:Preferences/Reset
when $wgUseMediaWikiUIEverywhere is enabled
Introduces HTMLForm->setSubmitDestructive()
Bug: 65317
Change-Id: I1d6691dce3e7dab662bda9a718e16c5caee6c041
Check for isVForm() and apply styling matching the default submit button
when generating alternate form submit buttons.
Change-Id: Ia3313087248af1537ac4740694846b6ff1187b1a
- Added space after reserved words: function, foreach, if
- Combined 'else if' into elseif
- Added braces to one-line statements
- Added spaces after comma, before parentheses
Change-Id: Ie5bbf680d6fbe0f0872dab2700c16b1394906a72
This is much like the one OAuth has in
Special:OAuthConsumerRegistration/propose, except it stores the
autocompletion options in a data property rather than a global and uses
jquery.suggestions rather than jquery.ui.autocomplete.
Change-Id: I42473cea75f3706cc0125167f9191275ca6cb3b0
