This refactors the bindToggleOnSpaceEnter function to use keydown and
keyup listeners to provide the space/enter key functionality. This
provides the following benefits:
* A click event is triggered when pressing the space or enter key on the
passed in "button" element. This simulates native button behavior which
triggers a click event when these keys are pressed.
* Checkboxhack menus will no longer toggle rapidly when holding down the
space/enter keys.
Bug: T291096
Change-Id: I1ea65112fa6b527f1bd9118212838298399996aa
Before this commit, each bind function would return an object containing
a reference to the function used in the event listener creation with the
intention that this could later be used to cleanup the event listeners.
This is problematic for the following reasons:
* In order to cleanup the event listener, it forces the client to know
which element the event listener was added to (button, checkbox,
document, window, etc.),. the event type that was used ('click',
'focusin', etc), and whether or not the "useCapture" param was also
used. The `removeEventListener` API won't remove the correct event
listener unless these three pieces of info are known by the client [1].
* Because the above point is tricky to get right, numerous potential
memory leaks were possible with the `unbind` function as the
`useCapture` param wasn't being passed in some cases.
This commit aims to simplify the cleanup API by returning an anonymous
function in each bind function that the client can call to cleanup the
relevant event listeners without knowing any of the implementation
details. This also makes the `unbind` function unnecessary.
** This is a breaking change to the checkboxHack API ** but because
there aren't any known clients of the return values [2], a formal
deprecation process was assumed to be unnecessary. Note gadgets should
not be using the internal function mw.loader.require so these were
not considered.
[1] https://developer.mozilla.org/en-US/docs/Web/API/EventTarget/removeEventListener#matching_event_listeners_for_removal
[2] https://codesearch.wmcloud.org/search/?q=checkboxHack&i=nope&files=&excludeFiles=&repos=
Bug: T291096
Change-Id: Ia2d79f27dd81fdc74a44829da3ca472f4c01d4b5
This rule can continue to apply to all buttons. Increasing
the specificity caused regressions.
Bug: T294286
Change-Id: I8bf02e81df56cafa221daeeb0f36e0305c6d9816
MWNamespace has been deprecated in favor of the NamespaceInfo
service in 1.34 and should no longer be used.
All methods are unused in wikimedia-deployed extensions.
Bug: T291389
Change-Id: Ibe2069dea1af983d8fda53e734396c5a7a8b7321
This change fixes the following differences and bugs compared to the
normal diff:
* On an empty change the API response contains no `main` in
`response[ 0 ].compare.bodies`. Remove the previous diff and show a
'diff-empty' message in this case.
* The header with 'currentrev' and 'yourtext' is missing. Show this
message similar to the normal diff.
The HTML in the diff of the live preview is not exactly the same as in
the normal diff:
* The live preview has now <thead> and <tbody> elements.
* The live preview has always 4 columns.
Bug: T293307
Bug: T293597
Change-Id: Ibb4fccb74634094ffeabf6fe201257d747bb8a01
The parameter of the hook 'wikipage.indicators' in mediawiki.page.ready
and in mediawiki.action.edit.preview was inconsistent:
* mediawiki.page.ready fired the hook with the root element.
* mediawiki.action.edit.preview fired the hook with the children
elements.
This should be consistent.
mediawiki.action.edit.preview fires the hook before adding the elements
to the DOM. Therefor it can't fired with the root element before adding
to DOM. To be consistent the behavior in mediawiki.page.ready must
changed to the behavior in mediawiki.action.edit.preview.
Also remove the text nodes with the newline from the value in
mediawiki.action.edit.preview to be consistent with the value in
mediawiki.page.ready.
This change is a follow-up to bea70565d9.
Bug: T293564
Change-Id: Ie8890e6396db071975794655c4e4ec3616891f96
After the unicode migration from HHVM-like to PHP 7.2 (T219279),
MediaWiki is running in production with default PHP 7.2 unicode, so
some of the char mappings overrides for mw.Title are no longer
nesessary, since PHP is now closer to JS.
Bug: T219279
Change-Id: Ic487c55b09ff81c1b7878651342d793982814a3e
Add some of the hardcoded examples on the [[mw:RL/DM]] wiki page here
and improve the docs a bit overall, in prep for removing those sections
in favour of the API docs link, as we do for most other modules already.
This is quite possibly the most used module, and for some reason we
never integrated it into the rest of the docs :)
Change-Id: I7f255e87e65f11cde25ce4476bb9f25e289cf16c
mw.widgets.datetime.DateTimeInputWidget() uses the "clear" OOUI icon but
the "interactions" OOUI icon module wasn't declared as a dependency,
leading to an invisible clear button unless the module was loaded
elsewhere.
Bug: T283129
Change-Id: I5aef30a7b5f4f3286e3f5b459b675204b1233fea
Add the query value as a redlink in the result list,
as is already done if the query value is *not* a prefix
of some other (existing) title.
Bug: T291056
Change-Id: I1569ad5a57cd98fe7deb034512b46e948a3561e1
Fix the last drifts between the two. Custom CSS IDs/names/classes in
FileDeleteForm were replaced with the base one, as I think it's better
to be consistent, and it wouldn't be trivial to allow changing those
values in a clean way. Question for reviewers: should this part be
announced on tech news in case somebody is using those values in a
script?
Move the file delete intro above the form, like we do for normal
deletion.
For normal deletion, use the content of the wpReason field as default
value for that field, not the result of merging the dropdown and the
"other" field, which doesn't seem correct (the file version was already
doing this).
Make the file deletion form use the title as token salt like the base
form -- it shouldn't make any difference AFAICS.
After this patch, it should be possible to make DeleteAction extend
FormAction with low effort.
Bug: T288282
Change-Id: I8b115ecb1c94af63d686a575b18362ac32105ae2
I was under the impression that live preview could only be used on
wikitext pages, but this isn't the case. So pass the proper content
model to the API.
Bug: T293022
Change-Id: Icff5b8b25a4b0df3feda2093d5b9c92e6dd9be3a
After the mediawiki.rcfilters.filters.(dm|ui) modules were merged,
mw.rcfilters.js was just `require`ing the old init script to run some
extra setup, no need for separate files.
Bug: T256836
Change-Id: I6462151152d075af0ef8bce3a5edf0a0ba48761a
The new module retains the name .ui name so that existing
skin style overrides continue to work. We can consider renaming it
to just "mediawiki.rcfilters.filters" in a future patch.
This does not handle file reorganization, since both of the
modules used package files - instead, in the main script we also
require() the old main script for the .dm module so that its
setup code runs. But, we did need to rename the virtual
config file from the .dm module to not clash with the
virtual config file from the .ui module, since the
latter uses a callback instead of retrieving configuration
variables directly. These can be merged later as well.
Bug: T256836
Change-Id: I5ec0af8b8e6bcdba6b7881f946f777b854a33739
Follow-up: Ieab0606068a78e5b5e5b9b3337f3a75a0b64adbc
This is concatenating an object and a number, so the index is always
"[object Object]0.5"
Ops :)
Bug: T292600
Change-Id: Icf9df9a3e1fbbb08f1868131cf3fb740ee3a3e08
Inject `wgForeignUploadTargets` and `wgEnableUploads` via a
virtual file instead of always adding them to mw.config.
Added a comment about them in the release notes since wgEnableUploads
was used by an (undeployed) extension, but we can make the
breaking change because their inclusion was marked as
@internal.
Bug: T292017
Change-Id: Ib1635b1864963c6c03c4a80e15048a898b8eaf90
Previously, .thumb wouldn't be a direct descendant of .gallerybox
because of the explicit div for padding. We don't want this rule to
apply to the legacy media dom so use that knowledge as a differentiator.
Follow up to Iff2bdc3aa02f84f0bf4ca55d177706823934cc08
Change-Id: I5ad9bf1913ece4a167fd642b536143695e34d00f