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
Use the cancreateerror returned from list=users&usprop=cancreate for
username validation.
Use the new action=validatepassword to validate entered passwords.
This also injects the resulting errors in the style of HTMLForm's field
validation rather than at the top of the form.
Change-Id: Ie8c1270eb605367556fe36b0b2080eb3f957dc54
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
No longer needed after I08244addcf9b6eb96137895f28e7b750914fef5c.
Also remove datetime.js from mediawiki.htmlform module.
Change-Id: Ic2410c689de3f70f573fa1c71456e6d3f334f80b
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
Otherwise, after we allow HTML5 form validation attributes, these
buttons wouldn't work for non-JS users (unless the whole form was
otherwise valid).
Change-Id: Ia9c16849774c186b991280ea60fc5608ddd4cf42
Most of these are simply changing annotations to reflect
reality. If a function can return false to indicate failure
the @return should indicate it.
Some are fixing preg_match calls, preg match returns 1, 0 or false,
but the functions all claim to return booleans.
This is far from all the incorrect return types in mediawiki, there
are around 250 detected by phan, but have to start somewhere.
Change-Id: I1bbdfee6190747bde460f8a7084212ccafe169ef
Otherwise, in browsers that support HTML5 form validation, it
would be impossible to submit the form if a field failing
validation was hidden (e.g. because it's marked as required).
Note that disabled fields are not submitted with the form. This
should be okay, as server-side validation ignores them entirely.
(I37e50799ba1f0e0e64a197818b58444f5b056bf0 fixes a corner case.)
For cloner fields, 'hide-if' rules of the parent are now copied
to the children, to make handling such nested fields simpler.
Bug: T145440
Change-Id: I81d04dca6cbb499a15828fd33b01746b68c694da
Follow-up to 788526c2d1.
To test: try to create a SecurePoll of type "Approval vote". Without this
patch, but with I81d04dca6cbb499a15828fd33b01746b68c694da, an invisible
field (only applicable for "Range voting (plurality)") will fail validation.
Change-Id: I37e50799ba1f0e0e64a197818b58444f5b056bf0
Adds support for the 'autocomplete' HTML attribute to HTMLTextField
(mainly for turning it off, but other values are supported as well).
Renames 'autocomplete' to 'autocomplete-data' (with temporary B/C)
in HTMLAutoCompleteSelectField to make space.
Change-Id: Ic0539d5a61d9862e670d10686adc1e41f65d908e
It mostly already worked. HTMLForm::trySubmit() needed a little
adjustment to handle things properly.
Change-Id: Ibb17bb61ac0b2d41953249980bc2f23b8a3ae5b6
Use HTTPS instead of HTTP where the HTTP link is a redirect to the HTTPS link.
Also update some defect links.
Change-Id: Ic3a5eac910d098ed5c2a21e9f47c9b6ee06b2643
It looks like there is something missing after the last statement
Also remove some other empty lines at begin of functions, ifs or loops
while at these files
Change-Id: Ib00b5cfd31ca4dcd0c32ce33754d3c80bae70641
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
