Note that this changes the effective type of the protected mCancelTarget
field. This fields has no declared type, and does not seem to be used in
any subclass. The type of mTitle is not changed at this time, but
nothing seems to rely on that either.
Bug: T278459
Change-Id: I4bf0d46c74b53ffc9cb3e6e497c789ef6b3bab6a
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
Visually, this only affects OOUIHTMLForm, in other kinds of forms
the element has no height anyway.
Change-Id: I90e73c49fbefec23532368848bb30b2e7b69075c
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
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
Rejigger some HTMLForm internals to remove the hardcoded assumption of
using 'mw-ui' classes.
Bug: T98903
Change-Id: Icc20453c999c761b87e19a71ccd43d93b9c1bfa7
…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
