I've never liked how HTMLForm guesses the method names that return
each field's HTML based on the $displayFormat property, for example
`$displayFormat === 'div'` resulting in using `->getDiv()`. Recently
this mechanism resulted in CodexHTMLForm lying about its display
format to get the desired result. Instead, explicitly switch based
on the display format and call the appropriate method, and override
this in subclasses when using subclasses.
Change-Id: I91b802ac63622e3b592be589d89ea11117a616f8
This is mostly so that I can add nice type hints. (But also, this is
one of the main things that this class does, I think it deserves its
own method instead of being sandwiched in that ugly loop.)
Change-Id: I621b839a8079cee1198c4250686e378ff7006c75
Some of these classes are really huge, up to 2000 lines and more. I
hope this makes the source code a little more readable.
Change-Id: I3d4b2a042a34c14e6ea0ea30ea31ca53448d8d59
Make phan stricter about array keys
Remaining false positive issues are suppressed.
The suppression and the setting change can only be done together
Bug: T304887
Depends-On: I3105a5fd4826f8667b5232834defc5ec93be32a1
Depends-On: Ie9610a6e83731468311edb3ed17f80fc509de385
Change-Id: I701f12ab94478c3b8e7fd82110ade74a8e6b04ef
Rename HTMLForm::[get|set|add][Pre|Post|Header|Footer]Text() to
HTMLForm::[get|set|add][Pre|Post|Header|Footer]Html() and
deprecate the old methods. Their arguments are rendered as raw
HTML so the old name was misleading.
Some of these are marked as stable to override and theoretically
the renaming could cause problems if callers are updated to the
new name while the overriding class is still using the old name,
but the only case known to codesearch is OOUIHTMLForm which is
also updated here.
Bug: T290771
Change-Id: I2c269eb6ab2b320fa2eef4ee8a226e96ad05fbe2
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
single string is raw html,
not a message key as documented on HTMLForm::trySubmit
Also remove is_string, any truthy value would be implicit string casted
in HtmlForm::getErrorsOrWarnings
Reorder the if in HtmlForm to look similar to OOUI
Change-Id: I5b78b0df2cca695f8f5c6b08aa4d6c015d1fa1fe
When there's an error in one of the fields "below the fold" or in
another tab, it's hard notice that it wasn't saved, especially since
the success message is very subtle.
In normal forms, there's a red error message at the top (in addition
to messages next to invalid fields), which was missing from the
preferences form.
I ran into this while experimenting with signature field validation.
Change-Id: If365e35d15a52939397f2093b1b8f5113a62e22b
Previously the form was only collapsible/expandable using the small
link-button on the far right. Now you can click on the entire header
to do it, and it has an appropriate pretty icon.
We add appropriate ARIA `role` and textual labels. Together with
recently added `toggleARIA` option of jquery.makeCollapsible in
Ic457bda58e56f we feature a screen reader workable output.
Bug: T222904
Change-Id: I6964296bc6870550478de662d21f12a1fc084c15
Also minor tweaks:
* Fix @since tags, this did not make it into 1.33
* Fix usage of FieldsetLayout 'group' in OOUIHTMLForm
* Documentation changes
Follow-up to 2896e87a10,
per my post-merge review on that commit.
Change-Id: Ib93375cde19730a46e4929878d6e472d3ac8f631
* Title: phan false positive
* McrUndoAction: fixed improper use of @param
* UploadSourceAdapter: fixed wrong type
* XmlTypeCheck: Use null so phan doesn't think we're trying to call the
function ''
* Database: phan false positive
* SpecialBlock: Use phan's advanced type documentation so phan knows
specifically what's being returned
* ChangesListSpecialPage: phan false positive
* BatchRowUpdate: Have default callback take a parameter so phan doesn't
think too many arguments are being passed
* MimeAnalyzer: left FIXME for relying on PHP 7.1 unpack() signature
* LanguageConverter: Specify types for $mTables since phan couldn't
determine it automatically
* preprocessorFuzzTest: Implement User::load() method signature
Change-Id: I08080ab636c5fe67ea6a4e14b2212d7523606e21
The code in formatSection() assumed it was only called for the
toplevel section (the whole form), while it's actually called
for every subsection too. I think it was written before we added
support for subsections in OOUIHTMLForm.
Move code for toplevel section wrapping to wrapForm().
As a bonus, this also fixes display of custom headers and error
or warning messages for forms with subsections.
Bug: T180535
Change-Id: I6a88184d302a951be78387490404137acde3fa1a
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
