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
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
Follows-up 777336288b, which renamed the module in 1.31.
It was only used in a few places, which have been updated except
for MassMessage, which is updated with Id7612859dfba.
Depends-On: Id7612859dfbace9052f62df1c07595f85a75515b
Change-Id: I475fe6fef5b863b44895c201217a82ee18a020c6
This is an empty placeholder module that does nothing, for
backwards compatibility with older extensions that were still
supporting MediaWiki versions from a time where ES3 was the
requirement and ES5 was shimmed. There is no longer any use
of 'es5-shim' anywhere in Wikimedia Git, nor on-wiki.
Bug: T192623
Change-Id: I143b89d3658ab83b98a1f201dd1f67a2d506fb09
This is an internal dev utility used by mediawiki.debug, not
used anywhere else, and probably wouldn't be supported even if
it was re-used somewhere, given it's custom made for mwdebug.
Bug: T192623
Change-Id: I086f7a1d06ab33d9dd9fc29fff27ddcdeb9a304b
If any special pages are loading this code, let it load.
Skins can disable this code if necessary (see Minerva for example)
In T111565 we will look to enabling this on the Minerva skin.
Bug: T111565
Change-Id: I837c16bdad7769f5cb4ce0bcfadb380b34c48bd4
These are all quite tiny and not worth providing separately
to the system as deliverable file bundles.
Mark the other mediawiki.api.* modules as alias to 'mediawiki.api'
for back-compat, with deprecation warning.
Highlights:
* Change mediawiki.api.edit.js to not use mw.user, because that
causes a circular dependency, given mw.user also depends on
mediawiki.api.
Bug: T192623
Change-Id: I0afdc8ab50bc1354bb5099bf39923c07eab0b665
The 'mediawiki.special.changeslist.visitedstatus' module is only
used in SpecialWatchlist.php, which also always loads
'mediawiki.special.watchlist'. Thus, registering them as seperate
deliverables isn't needed.
In terms of size, they're also sufficiently small that even if
they could load under different conditions, it'd fine to load
as one module regardless.
Bug: T192623
Change-Id: I67d78083ce7a3000c05356e3eb0bcb98d0c1e990
These stylesheets are sufficiently tiny that it doesn't make sense to
offer them the ability to be loaded separately from each other (saving
bytes in double-digits) at the cost of 1) exporting a dedicated registry
item with meta data shipped on every page view, 2) reduced cache re-use
from increased fragmentation.
Instead, move these to the 'mediawiki.special' style module.
The entries retain their own files to keep them as easy to find
and edit as before.
Where not already, ensure addModuleStyles() is always placed above
any addModules() call in the same method. The load order isn't
affected by the call order, but given blocking style-modules load
before async JS, it helps to order them in a way that visually
matches the effective load order (from top to bottom).
The following 7 modules were remove without deprecation:
1. "mediawiki.special.apisandbox.styles" (1 rule)
2. "mediawiki.special.edittags.styles" (3 rules)
3. "mediawiki.special.movePage.styles" (1 rule)
4. "mediawiki.special.pagesWithProp" (1 rule)
5. "mediawiki.special.upload.styles" (2 rules)
6. "mediawiki.special.watchlist.styles" (3 rules)
7. "mediawiki.special.comparepages.styles" (4 rules)
These module names were only used on the core classes loading them, and
aren't depended on outside core by module name, rather, extensions and
gadgets depend on the styles styles being loaded in a blocking manner on
these pages, which remains unaffected.
Bug: T192623
Change-Id: I6e663dc3c80c7104c9b9abdde44c654543185373
With MCR coming up, ApiEditPage is going to need to be able to take
"text" and "contentmodel" parameters for each slot-role, and enumerating
such parameters for every possible slot would probably get rather
confusing as to what is required when, or at least long-winded in
repeating the exact same thing for every possible role.
So let's abstract it: we'll have an "editroles" parameter to specify which
slots are being edited, and ApiEditPage will just declare that
"text-{role}" and "contentmodel-{role}" parameters should exist for each
value of "editroles" in the submission.
Note this patch doesn't introduce anything that uses templated
parameters, just the functionality itself. For testing purposes you
might cherry pick I2d658e9a.
Bug: T174032
Change-Id: Ia19a1617b73067bfb1f0f16ccc57d471778b7361
This change allows to add internationalized messages into CSS. The new
parameter 'lessMessages' contains the array of message keys that get
set as Less variables.
In Less the variables must enclosed in double quotes (") or single
quotes (') to prevent CSS injection.
Example usage:
Resources:
"class": "ResourceLoaderLessVarFileModule",
"lessMessages": [ "editsection" ],
Message 'editsection':
edit
Less file:
content: '[@{msg-editsection}]';
Generated CSS file:
content: '[edit]';
Also add a type case (object) to ensure that an empty object is
serialized as '{}' and not as '[]'.
Also include Less variables from parent.
Change-Id: I280b52c6745fe8e5755dc5d58c5621a64757d99d
Single-file modules to src/, the remaining as sub directories.
A few highlights:
* mediawiki.Upload.BookletLayout. (stylesheet: no image references)
* mediawiki.feedback - Also move the image to its own images/ subdir.
* mediawiki.searchSuggest. (stylesheet: no image references)
* mediawiki.toc. (stylesheet: no image references)
Also updated any other references to 'src/mediawiki/' that I could find
in core:
* Fixed references in docs/uidesign/*.html
* Remove redundant exclude from jsduck.json.
After this, there are 4 files remaining in src/mediawiki,
which are the 4 files used by the actual 'mediawiki' base module.
Bug: T193826
Change-Id: I8058652892a78b3f5976397bd850741dd5c92427
* mediawiki.htmlform.styles:
- mediawiki/htmlform/styles.css
- mediawiki/htmlform/images/*
Only contains two images, only used by this module.
* mediawiki.htmlform.checker.js.
* mediawiki.htmlform.ooui: Only Element.js.
* mediawiki.htmlform.ooui.styles.less.
* mediawiki.htmlform: Other files from mediawiki/htmlform.
Bug: T193826
Change-Id: I5c057c758933e905d5c7940ade5bf43282088159
The two CSS files belonging to this module are the last ones
remaining in src/mediawiki/page. Move them to their own directory
in src/ instead. The stylesheets don't reference any images.
Bug: T193826
Change-Id: Ic07bbd5b60668a437177b389aa8fee861eb11892
* Reduce clutter in src/mediawiki/.
* Make these files and modules easier to discover and associate.
Follows-up I677edac3b5e, which only moved simple cases where no
related modules existed.
This commit also moves files for modules that have some related
multi-file modules. As well as files that previously did not
strictly have their path match directly to their module name.
For example:
- 'mediawiki.checkboxtoggle.css' to 'mediawiki.checkboxtoggle.styles.css',
because its module name is 'mediawiki.checkboxtoggle.styles'.
- 'mediawiki/page/gallery-slideshow.js' to 'mediawiki.page.gallery.slideshow.js',
because its module name uses a dot, not a dash.
- 'mediawiki/page/watch.js' to 'mediawiki.page.watch.ajax.js',
because its module name also includes 'ajax'. This also makes it matches
the way "mediawiki.page.patrol.ajax" files were already named.
Ideas for later:
- Consider merging 'mediawiki.ForeignApi' and 'mediawiki.ForeignApi.core.'.
- Consider merging 'mediawiki.page.ready' and 'mediawiki.page.startup'.
Bug: T193826
Change-Id: I9564b05df305b7d217c9a03b80ce92476279e5c8
This moves all files belonging to a 'mediawiki.*' module containing
only a single JavaScript file with no references to other files.
* Reduce clutter in src/mediawiki/.
* Make these files and modules easier to discover and associate.
Bug: T193826
Change-Id: I677edac3b5e9d02208c87164382c97035409df63
* Reduce clutter in src/mediawiki/.
* Make it easier to see from the repo structure which files
belong to this module, and which files not. For example,
'mediawiki.notification.convertmessagebox' and 'mediawiki.notify' are
logically related, but not actually part of this 4-file module.
Bug: T193826
Change-Id: I274323dffa8af1d046beb21d88f633f432a6ebbc
* Reduce clutter in src/jquery/.
* Make it easier to see which files belong to which module, especially
src/jquery/images/ which was confusingly shared between multiple modules.
This also helps emphasize that while jquery.tablesorter.less is included,
jquery.tablesorter.styles.less is not.
Also follows-up 8cdfcc5fd, which placed its style-module definition among
the 'mediawiki.*' modules instead of near the 'jquery.*' modules.
Change-Id: Ib639de5df323a36982ecdd89158a939beaaa2dd3
It was currently in the directory for 'mediawiki.messagePoster', but this
file actually belongs to a different module.
Bug: T193826
Change-Id: Ia51d2a373173c1bc7fe78196dbef89089c51ac86
Keep the main file in src/ for now, because it's got some whitespace
changes and a closure-wrap that make it differ from upstream's
version. Those changes are hard to review both for diffing and for
functional differences due to its odd-looking scope assignments that
I'd rather not change as part of this.
Change-Id: I248831cfa984432d0a30aa923a9bcd98029b05c4
Follows-up 648667ac9f, which didn't move this module because
it had a local patch for exposing via module.exports and mw.lib
(instead of its default 'pluralRuleParser' global).
Restore the file back to a clean copy from upstream, and perform
the export via a separately concatenated file instead, using the
same pattern we already use for 'oojs' and 'moment'.
Change-Id: I27ee80dc34e0ad5206cf9c1ce68be3ec8811ecf8
