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
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
