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
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
Values returned by `Linker::tooltipAndAccesskeyAttribs()` and
`Linker::titleAttrib( ..., 'withaccess' )` include an accesskey
hint in the title text. This is unnecessary when used for OOjs UI
widgets, since after the changes from T168408 they display an
accesskey hint automatically.
Also fixed some other accesskey bugs in HTMLForm which probably
no one ever ran into.
Bug: T168408
Change-Id: I63285b5bce3341875a6d82eba059623bf105ca62
HTMLForm when using OOUI mode was not adding errors to the resulting
HTML, if depending on message arrays, as previously used before
Status.
This exposed additional problems. Aligned the function a bit closer to
HTMLForm's getErrorsOrWarnings()
Bug: T158492
Change-Id: I8765a025dd441676e35a7c183c67b37036643c1e
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
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
The hidden element is only needed if either a header is set or the form
has errors. If both does not apply, the element isn't needed and should
be omitted instead of hidden with `display:none`.
It's also not needed to add a LabelWidget for the header, if the form has
errors, only, but no header (which would result in an empty space between
the header and the fieldset legend).
Follow up: Ifbf38878d41906184f97169b22002f788711a311
Change-Id: I4ffefdc50d435590d25a7dfc202228920dd801ae
Improves Ida647973a which unified message handling for form fields
but did not make the functionality available to HTMLForm itself.
Change-Id: I2e6195ba13afbd8b993acb47409fab1be91c547e
Visually, this only affects OOUIHTMLForm, in other kinds of forms
the element has no height anyway.
Change-Id: I90e73c49fbefec23532368848bb30b2e7b69075c
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
In order to work with OOUI properly, SpecialChangePassword::attemptReset() doesn't
throw PasswordErrors anymore. It now returns a Status object which
is set to fatal, if some requirement doesn't meet.
In OOUIHTMLForm: Handle Message objects as errors correctly. It's a valid parameter
for fatal to use a Message object instead of a message key, so OOUIHTMLForm needs
to handle Mesage objects as Message objects (can be parsed directly) instead of using
it as a message key (which usually doesn't exist).
Bug: T78373
Change-Id: Id768833bbd966cdeadd5a13fdb64b636ea2062ef
Now we also handle the form-wide errors, putting them in the FieldLayout
that contains the form's header.
Follow-up to I860a96858c4fcac62d63b46e35a9153f22c0a9c9.
Bug: T98894
Change-Id: Ifbf38878d41906184f97169b22002f788711a311
* 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
Depends on Ie14a35fac70d62ff7d102caaa56654ebde11d7dd in OOUI.
Part 2 follows after some cleanup in intermediary commits
in Ifbf38878d41906184f97169b22002f788711a311.
As a bonus, HTMLFormField::getOOUI() now always produces a
OOUI\FieldLayout in OOUI mode. This will let us clean up some code
where we had to take errors HTML from HTMLForm
(I91af6efa8762e9676efea532381292e221255862).
Bug: T98894
Change-Id: I860a96858c4fcac62d63b46e35a9153f22c0a9c9
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
This avoids "ContextSource::getContext (OOUIHTMLForm): called and $context
is null. Using RequestContext::getMain() for sanity"
Change-Id: I20c2bb58b3a0e5e259241a3715ee8fdf4b57e148
