This is really a workaround for an issue in a completely different place:
JS RadioSelectInputWidget internally uses `<input type="hidden">`
rather than real radio buttons, which does not work correctly with the
code in mediawiki.special.preferences.confirmClose.js. Ideally we would
change RadioSelectInputWidget to not do such weird things.
However, I think this is actually a good thing to do in general.
From the user's perspective, PHP RadioSelectInputWidget and JS
RadioSelectInputWidget look and behave the same, so there's no reason
to infuse and rebuild them.
This behavior was implemented in f50cee1375
in which unfortunately I did not document the reason for it. For other
fields it makes obvious sense (the JS widgets have improvements like
autocompletion, or at least look "pretty"), but I have no idea why
I did it for this one.
Bug: T180643
Change-Id: I53e50f8cda39466b2396b374e642c154487888bb
'Mediawiki\Widget\SelectWithInputWidget' is the only one that shows up
in the logs, but I tidied up a few others I came across.
Change-Id: I700dec858007a8013e6d7b9e37ddf518f223d8b7
Release notes:
https://phabricator.wikimedia.org/diffusion/GOJU/browse/master/History.md;v0.23.5
Also, replace uses of `OOUI\TextInputWidget( [ 'multiline' => true ] )`
with `OOUI\MultilineTextInputWidget()` to avoid deprecation warnings
(which cause unit tests to fail).
Depends-on: I990b14982ffb72fe981040d02c7023d13f721aaa
Change-Id: If8312c60e1547a6177f5491011badb6576f54b21
The resulting HTML makes very little sense semantically, but no
worries, because so does the existing one for non-OOUI forms.
Change-Id: I99bf6341c58869f6322b9d9c780d9c66739d00b6
Set the ID on the main widget (mw.widgets.SelectWithInputWidget), so
that it can be infused by ID.
The dropdown/textbox by themselves can't be infused individually,
therefore IDs on them are pretty useless; remove those where they're
not necessary.
Follow-up to 8bd6605736.
Change-Id: If54dd48f1000e3e0f5a978428a5b622797b4f765
HTMLRestrictionsFieldTest::provideValidate only provide test cases with
\n, which fails on windows machine.
I see no reason to use the system depending constant here
Change-Id: I7caf2c4d06c84cac69e20e03d00a93bcd8e7d405
Some items in an HTMLCheckMatrix form field can be forced to be
on or off, in which case they're disabled. This adds three new
class names, so that (for example) Javascript can identify these
checkboxes. There are not currently any classes assigned to them.
Bug: T172585
Change-Id: I984020ce2437effb3ff5f186470105fd80d4a00f
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
No idea why this was using content language to begin with, but it seems
like it should clearly use the user language instead.
Bug: T171817
Change-Id: I1763ffd8ee037dbb5dd94c410cb6a82e0f6b27e9
If the string value is '' (empty string), the array
value should be [] (empty array), not [''] (array of one element
which is an empty string).
Bug: T169384
Change-Id: I558f3890af05efb6eaa18403467c0a05f44af12a
The used phpcs has a bug, so the version 0.9.0 could not be enforced at the moment.
Will be fixed in next version, see T167168
Changed:
- Remove duplicate newline at end of file
- Add space between function and ( for closures
- and -> &&, or -> ||
Change-Id: I4172fb08861729bccd55aecbd07e029e2638d311
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
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
Previously, you could pass 'cssclass' => 'mw-chosen' in the form
descriptor for a 'multiselect' field, and it'd be automatically
converted to a text field with a dropdown allowing values to be
selected. This is not very intuitive (unless you know what the Chosen
library is) and was not documented anywhere except for release notes.
The new recommended and documented way to achieve this is by passing
'dropdown' => true. Old way is supported for backwards compatibility.
Also, add the 'jquery.chosen' module to the page server-side.
Change-Id: I3a025e1c3c7571e930a35e020d73d558fdc433d0
Rather than have a master list in autoinfuse.js (duplicated in
hide-if.js), we put this information in each field class and put it
in the generated HTML as a separate 'data-' attribute. This also
allows new fields defined by extensions to be correctly autoinfused.
Change-Id: I3da75706209cbc16b19cc3f02b355e58ca75fec9
This is not really what we had in mind when developing the infusion
feature and I think it's not helpful. Most of the time there is just
no benefit; a ButtonWidget generated in PHP and in JS behaves and
looks pretty much the same, and rebuilding it through infusion is a
small performance hit. If you're not adding any event handlers, it only
makes sense for various dropdowns, which have themed styling.
For the primary use case of adding JS behaviors to PHP widgets you
need to call OO.ui.infuse() anyway to get a reference to the JS
widget, and not infusing automatically should make it easier to reason
about your code. Infusion tries to be very transparent, but it can't
hide the fact that the DOM is re-built, making your references to DOM
nodes from before infusion useless and losing anything from PHP that
wasn't included in the config (e.g. custom attributes).
This commit removes automated infusion from mediawiki.page.ready
and adds some custom code in mediawiki.special.movePage and
mediawiki.htmlform. I see only two extensions using infusable OOjs UI
widgets in Gerrit (ArticlePlaceholder and ExtensionDistributor) and
neither should be affected by this change.
Change-Id: I56608c537fc57c5c54960b0603694f2612f45618
I was a bit fast with merging I18edfcb62f7b21f2c1990c73944ee6a956fd4901,
because I think, type hinting the type of the parameter would make sense,
too.
Bug: T142912
Change-Id: Id397847c6c078047f3daa84db68ccf3e629ca531
It's getting more difficult to navigate the files in includes/htmlform/
with every new field and every new helper class that is being added.
Change-Id: I92ce2356baf6151f17b2440970d5abdf86503820
