Make the necessary UI changes to Special:Block in order to set/update
partial blocks.
Bug: T197109
Change-Id: Ib3067824b5dcbdd893ab1f165d169a35d0716cb2
Add the widget in both PHP and JS for OOUI, and into HTMLForm
definitions.
In JS, the widget uses the engine from mw.widgets.TitleWidget
with the async support from OO.ui.mixin.RequestManager.
The PHP version provides a textarea, like UsersMultiselectWidget.php
which is then infused if JS is available.
Also, add highlightSearchQuery option for TitleWidget to allow for
not highlighting the partial search query the user typed in, if the
UI requires it. This option (highlighting partial result) is already
optional in the TitleOptionWidget, so this config exposes that
optionality in the TitleWidget widget for its menu children.
Notes:
HTMLTitlesMultiselectField is a duplication of HTMLUsersMultiselectField
except for:
- The configuration variable changed to 'titles' (from 'users')
- OOUI modules were adjusted for the TitlesMultiselectWidget
- The PHP version instantiates a MediaWiki\Widget\TitlesMultiselectWidget
TitlesMultiselectWidget is a duplication of UsersMultiselectWidget
except for:
- $usersArray was renamed to $titlesArray
- getJavascriptClassName returns the correct js class for
mw.widgets.TitlesMultiselectWidget for infusion.
Bug: T197109
Depends-On: I675316dddf272fd0d6172ecad3882160752bf780
Change-Id: Ie96947a35f70b76731e16ae5b85de815dfa4a8ce
With this change, MediaWiki will no longer have a 'JavaScript-powered'
wikitext toolbar, and instead sysadmins will be required to choose one
(or more) of the several extensions available for this purpose if they
need the functionality. For over half a decade MediaWiki's tarball has
included the 2010-era replacement for this feature, WikiEditor. We are
now working on replacing even that, with the 2013-era visual editor, a
mode of which is the forthcoming 2017-era wikitext editor, and several
more specialised editors like CodeEditor.
Beyond this, the core editor toolbar is ancient, un-loved, and is used
only exceptionally rarely, mostly by accident. It is unhelpful to give
implicitly this as the primary editor for MediaWiki just because we've
not removed it from core when it is not a very good experience for any
kind of user, and has not received the attention that users deserve to
be worth retaining in core.
The old core preference, which was intended to govern whether this old
toolbar should be shown, has since mutated into whether the to run the
EditPageBeforeEditToolbar hook. The hook is used by several extensions
to provide toolbars in lieu of the core one. This preference has been,
in practice, a very confusing preference for MediaWiki users, who have
to interact with quite similar preferences to toggle their real editor
which sit next to this one on the preferences page. Consequently, this
preference is also removed.
The code could be made into an extension for those (very few) users of
MediaWiki who might want to keep on using it. However, the author will
offer their services but not their encouragement in said undertaking.
Bug: T30856
Bug: T32795
Change-Id: I2b05f0ca25873ad8e0b33a5e4938bef52c4e9347
This is to make sure that the design is similar, but also so
that the widget can be read in JS where needed and that we
can toggle the disabled state on/off through the whole widget,
that is made from a series of checkbox widgets.
Bug: T199946
Change-Id: I9943b0aa1746fdfb60c7d4c88d6d4d7ac0589a2c
Per discussion on T193826, these are not part of jquery (the library, or the
module), and should not be in the same subdirectory.
To follow the new convention that all entries directly in /resources/lib
should correspond to single library only (either as file, or as directory),
move them one directory up.
Bug: T193826
Change-Id: I24c05ec5fc5f0a2d54d501a4a022d829675bf850
Was originally created for Vector, which was originally part
of MediaWiki core. It hasn't been used for a while, and Vector
is in its own repository now.
Found 0 uses of this anywhere in Wikimedia Git, nor elsewhere
indexed by MediaWiki Codesearch.
Bug: T202154
Change-Id: I72ab5ad7f25be87b2f6d2f5f41a672b6a48b8005
OOUI's 'widgets' style module must be loaded after its 'core' style
module, because the styles need the rules to be in this order to work.
We can't enforce a dependency from 'oojs-ui-widgets.styles' on
'oojs-ui-core.styles', because it is a style-only module (it can't
have dependencies).
When both of these modules are loaded as style-only modules (using
addModuleStyles() in PHP), everything works fine, because they are
loaded in alphabetical order. But when they are loaded as dependencies
from JS code, the order is unspecified.
Move OOUI 'widgets' styles back into the 'oojs-ui-widgets' module
(partially reverting fc65ff17d9) to
avoid the problem.
When 'oojs-ui-widgets.styles' is loaded on a page that also includes
'oojs-ui-widgets' (e.g. Special:Preferences), unfortunately the styles
will be loaded twice. I don't see a way to avoid this problem.
Bug: T195544
Change-Id: Ia07189f96b423b218ecbc52acffdedca517d2b01
=== module.exports
Follows-up dec800968e, which added a clause for `window.$` inside runScript()
that ensures require/module.exports is not given to 'jquery'.
This commit adds the same clause to debug mode handling, which follows a
different code path. Without this, jquery.migrate.js execution throws from
`require('jquery')`, when viewing a page in debug mode.
=== mediawiki.legacy.wikibits
Before dec800968e, 'jquery' was a raw module and not allowed as dependency,
and before that commit base modules did not follow debug mode. Instead,
they were always combined in the same request (even in debug mode), with
only the order in the query string dictating their execution order.
After that commit, it is mandatory for base modules to express their
execution order through dependency links. This was done for 'mediawiki.base',
but forgotten for 'mediawiki.legacy.wikibits'. That module isn't used by
default, but becomes used when enabling $wgIncludeLegacyJavaScript, which
is off by default, but on for Wikimedia wikis.
Bug: T192623
Change-Id: Id4fbfee71deeb9528e8a622604d4cd972dd25d3b
This commit implements step 4 and step 5 of the plan outlined at T192623.
Before this task began, the typical JavaScript execution flow was:
* HTML triggers request for startup module (js req 1).
* Startup module contains registry, site config, and triggers
a request for the base modules (js req 2).
* After the base modules arrive (which define jQuery and mw.loader),
the startup module invokes a callback that processes RLQ,
which is what will request modules for this page (js req 3).
In past weeks, we have:
* Made mediawiki.js independent of jQuery.
* Spun off 'mediawiki.base' from mediawiki.js – for everything
that wasn't needed for defining `mw.loader`.
* Moved mediawiki.js from the base module request to being embedded
as part of startup.js.
The concept of dependencies is native to ResourceLoader, and thanks to the
use of closures in mw.loader.implement() responses, we can download any
number of interdependant modules in a single request (or parallel requests).
Then, when a response arrives, mw.loader takes care to pause or resume
execution as-needed. It is normal for ResourceLoader to batch several modules
together, including their dependencies.
As such, we can eliminate one of the two roundtrips required before a
page can request modules. Specifically, we can eliminate "js req 2" (above),
by making the two remaining base modules ("jquery" and "mediawiki.base") an
implied dependency for all other modules, which ResourceLoader will naturally
fetch and execute in the right order as part of the batch request.
Bug: T192623
Change-Id: I17cd13dffebd6ae476044d8d038dc3974a1fa176
Also make a few changes for consistency with normal delete form:
* Add `autofocus` attribute on the "Other/additional reason" text field
* Remove bold styling from "Suppress …" checkbox label
* Remove `class="wpReasonDropDown"` from the "Reason" dropdown
* Remove `id="wpDeleteSuppressRow"` from the "Suppress …" form row
Bug: T173997
Change-Id: Ia5a0412c959c6149b01afe7fc6cbf5e8591673ac
The latter two modules are never used separately and have no references
anywhere in Wikimedia Git outside MediaWiki core.
Remove without deprecation as they were introduced only as internal
work-around to be able to call setData after init.js and the rest of
'mediawiki.language'. Which is actually trivially done by concatenating
one after the other, but for some reason I didn't think of that when
reviewing 4c6c50f206 in 2012.
Also fix an annoying race condition in the unit tests that
often caused tests to fail locally.
Change-Id: Ic61f86b0dcbfac82da230770f66cb72e97bd9a03
Skins haven't been a part of MediaWiki core for a while now,
they are very much separate things existing in their own,
separate repositories.
Change-Id: I55e3b6382b8fef3b25562b52580d1b1f902a760e
Changes in the behavior:
* The toggle button generate no FOUC on loading.
* On keyboard navigation the toggle key is the space key and not the
return key.
* Animation on hide and show is missing. Maybe a new animation with CSS
can added.
* The state of the button is not saved in a cookie.
* Self-build TOCs can not get hidden.
Browser support:
* The new implementation does not need JavaScript and therefor it works
on browser with disabled JavaScript and on Grade C browser.
* The new implementation requires the CSS pseudo-class selector
:checked. Therefor IE8 and lower are not supported.
Risks:
* The new implementation needs additional HTML elements. These elements
also get cached and crawled. The elements have no content so they get
hopefully ignored by crawler.
* The new CSS code imitates some styles (link, focus). This must kept
up to date.
* Multiple TOCs on one page would generate the same id attribute.
This can avoided by appending a counter or better and easier a random
string to the id attribute.
Bug: T195053
Change-Id: I82db33d656b3795d7134a91d20ed9d93a3471086
This is an empty placeholder module. It was kept for backwards compatibility
with older extensions that were still supporting MediaWiki versions that in
turn supported older browsers that in turn did not yet implement the JSON
interface of the ES5 standard.
There is no longer any use of 'json' module anywhere in Wikimedia Git,
nor anywhere found by Codesearch, nor anywhere on-wiki in gadgets at WMF.
Bug: T127328
Change-Id: I8ba40a73dc900909e3fa3bd3ebe88616c9a26d3c
Embed the essential files to define mw.loader directly as part of
the startup module.
* This means the internal 'mediawiki' module no longer exists.
This is safe to remove because:
1) While registered server-side for loading from startup.js, a PHPUnit
structure test disallowed being specified as a dependency.
2) Anything that attempted to load it client-side failed because the
module was marked in the registry as 'raw', thereby excluding it
from the data sent to the client-side. As such, it was seen as an
unknown module that the client refused to fetch from the server.
* Deprecate getStartupModules() and getLegacyModules().
These are no longer needed. There are no known callers anywhere in
Wikimedia Git or elsewhere indexed by Codesearch, but easy enough
to leave as no-op for one release.
* Remove ResourceLoaderRawFileModule class.
No longer needed. Was created as a hack specifically for the 'mediawiki'
module so that it would not leak global variables in debug mode.
It has no usage anywhere in Wikimedia Git, nor elsewhere in Codesearch.
Remove without deprecation given this was meant to be a 'private' class.
* Introduce (private) getBaseModules(). Previously, this list only existed
locally in getStartupModulesUrl() by merging getStartupModules() and
getLegacyModules(). This value was factored out into its own method.
* Make getStartupModulesUrl() private and rename to getBaseModulesUrl().
It is only used internally to export the 'baseModulesUri' value.
Its name was already confusing before, but it would've been even more
confusing now given it doesn't even call getStartupModules() any more.
Bug: T192623
Change-Id: I14ba282d7b65e99ca54b7c2f77ba6e1adaddd11c
Add a PopupWidget subclass that wraps the color picker, and pass that
down to the buttons in the menu items.
Bug: T198142
Change-Id: I84dabce988f4c99835f503bb8c8eb492f7fbfde1
This is an internal script automatically loaded by Skin.php to
activate the 'jquery.hidpi' polyfill for all images on the current
page in browsers that don't natively support the 'srcset' attribute
on the HTML img element.
This script is loaded via ResourceLoader for which Grade A currently
requires:
> IE11+/Edge, Chr 65+, Ff 52+, Saf 5+, Op 15+, iOS 6+, Android 4+.
According to MDN and CanIUse, the basic 'x' syntax of srcset is supported, and
enabled by default, in:
> Edge, Chr 34+, Ff 38+, Saf 7+, Op 21+, iOS 8+, Android 5+.
This means in the following browsers, MediaWiki will no longer attempt to
replace images in articles with their hidpi versions.
| Browser | analytics.wikimedia.org (22 May - 22 June)
| ---------------------- | -----------------------
| IE 11 on Windows <= 7 | 3.4% (OS does not support HiDPI)
| IE 11 on Windows 8+ | 1.1%
| Safari 5 & 6 (desktop) | <0.1%
| Opera 15-20 (desktop) | <0.1%
| iOS 6 & 7 (mobile) | 0.1%
| Android 4 (mobile) | 0.5%
While the total of 1.7% is higher than our usual point where we decide
to remove support, I think we should consider dropping the hidpi polyfill
still for several reasons:
* MobileFrontend no longer uses 'srcset' attributes. As such, these browsers
don't actually change their behaviour based on the polyfill.
* For IE 11/Win8 in particular, most users don't have an HiDPI monitor,
but we still download the polyfill. HiDPI on Win8 is primarily tablets.
* In all cases where the polyfill activates, we download the HiDPI images
in addition to the standard resolution (which downloads and renders first).
This is because client-side JavaScript is not able to replace it sooner.
This could be considered a waste of bandwidth, as it can double or tripple
the bandwidth cost for end users.
This also means pages complete their loading much later because the browser
first renders the page nearly to completion with standard resolution images,
and only at the end our polyfill activates to restarts all image loading.
The experience gracefully falls back to normal web rendering, where the standard
resolution of the image is used. This would match what users of these devices
see on other websites, given client-side emulation of srcset is fairly rare.
== Modules
The 'mediawiki.hidpi' module was removed, and considered internal to Skin.php.
It contained no public methods. I confirmed there were no matches in Codesearch,
and no matches in mwgrep on Wikimedia wikis.
I did not remove 'jquery.hidpi', which is what contains the actual polyfill
and the jQuery.fn.hidpi() public method. (Codesearch shows 2 extenisons using
it, and mwgrep returned 1 unused gadget on Meta-Wiki referencing it).
It has been kept, but marked as deprecated. To be removed in a future release.
Bug: T127328
Change-Id: I42ce0feea1fbfe534f00e05a7cd8d81df0c33d8f
This is an empty placeholder module that does nothing. It was kept
for backwards compatibility with older extensions that were still
supporting MediaWiki versions that in turn supported older browsers.
There is no longer any use of 'dom-level2-shim' anywhere in Wikimedia Git,
nor anywhere found by Codesearch,
nor anywhere on-wiki at WMF (including user scripts).
Bug: T127328
Change-Id: I416b216471c321d56d3b6d72bc9ef7dcc0f16093
When collapsed, make sure we are adjusting the 'min-height' on the
'rcfilters-head' div so that it actually takes the space it should.
Make sure the preference of whether the area is collapsed or not is
preserved for the user, per RC or WL pages, and that it is loaded
properly with the correct minimum height dimensions depending on
which state is in the preferences, so to prevent "jump" of the
result list after load.
Bug: T177206
Change-Id: I82c3042cd1bb85dedcd6b5458b157fed94def808
The library is used to compress large documents before
sending to the server, as HTTP doesn't support upload compression.
(See T68914 for context.)
N.B. Many of the polyfills in the original are omitted as
MediaWiki doesn't support browsers which require them.
Co-Authored-by: Kunal Mehta <legoktm@member.fsf.org>
Change-Id: I12a5879188f46f17dc4c33bdad52317d218d4172
There are no longer any skins bundled with MediaWiki releases that
use it. Styling for this should be the skins' responsibility.
Vector and MonoBook no longer use this element, and core's
providing of these styles actually creates conflicts.
For skins using 'mediawiki.legacy.oldshared' (predating MonoBook),
no changes are required! Their jump-to-nav styles remain preserved.
For skins that use 'mediawiki.skinning.interface' and have
MonoBook-inspired accessibility links within a `<div id="#jump-to-nav">`,
need to make one of two changes:
1. Adopt the new CSS-only approach documented in T195256,
as used by current MonoBook and Vector.
2. Or; Add a copy of the old CSS (included below) to your own skins'
stylesheet and ensure the `jquery.mw-jump` module is loaded (previously
by default), either by adding `$out->addModules( 'jquery.mw-jump' )`, or
by adding it from the skin's Skin::getDefaultModules() override.
@media screen {
#jump-to-nav {
/* Negate #contentSub margin */
margin-top: -1.4em;
margin-bottom: 1.4em;
-moz-user-select: none;
-webkit-user-select: none;
-ms-user-select: none;
user-select: none;
}
.mw-jump, #jump-to-nav {
overflow: hidden;
height: 0;
zoom: 1;
}
}
@media print {
.mw-jump, #jump-to-nav {
display: none;
}
}
This migration guide will be added to the T195256 task description,
to which the release notes refer.
Bug: T195256
Change-Id: I84bcd23180b3d1fa541728989f44a376189df95d
As a first step to splitting the 'mediawiki' module, start by
splitting the file. The two files (like the other files in the
same directory) are still concatenated and run at the same time.
The only difference being that the private variables aren't available,
and it forces us to think about not being able to call the methods
during initialisation given the base file will execute after the
main one, making its methods not yet available during the split
time between the two.
From the perspective of regular modules, this changes nothing
as it will still load as one atomic unit defining the same public
API as before.
Bug: T192623
Change-Id: I552ae02e49c4d30070e166a504f454e334e8e75e
The current styles (from 1b14198df2)
did not actually apply to any elements on the page until
jquery.tablesorter ran: MediaWiki parser does not generate
`<thead>` elements and it's not even allowed as a HTML tag, only
jquery.tablesorter wraps a table header in them.
Instead, they resulted in the padding not being applied inside
VisualEditor editing surface (T195108), because it doesn't run
jquery.tablesorter (and instead manually adds CSS classes for
the sorting icons to appropriate cells).
The original attempt (from 8cdfcc5fd4)
was a good idea, but I think it is not possible to do this well
enough with just CSS. In addition to unsortable columns (described
in T194451), the header may also consist of multiple rows, with cells
with colspans and rowspans, where only one header cell in each column
should have the sorting icon. This is not possible to implement in
CSS.
This reverts commit 1b14198df2
and parts of 8cdfcc5fd4.
----
Minimal example of a table where it is impossible to style
appropriate header cells with CSS only:
{| class="wikitable sortable"
! colspan="2" | H1-2
! rowspan="2" | H3
|-
! H1 !! H2
|-
| A1 || A2 || A3
|-
| B1 || B2 || B3
|}
Bug: T195108
Change-Id: Ife15069b3a2a38d36cb9077e31a82a9fc1a36215
This was added in (r99923; 4d8c7e96ed) while reviewing the
'gadget-preferences' branch in SVN of the Gadgets extension during
development of MediaWiki 1.18, intended for use in a color picker
on Special:Gadgets as part of an experimental feature that was
never completed (r94051).
The module has no usage anywhere in Wikimedia Git, nor in any
third-party hosted repos indexed by MediaWiki Codesearch, nor
anywhere on-wiki at WMF in site scripts (per mwgrep).
Bug: T193826
Bug: T192623
Change-Id: I8ed6c09dc7efd750ad4688b895b2e3f808a0e52b
