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 reverts commit 531e71acda.
Was a breaking change that did not following the deprecation
policy.
Change-Id: Idefd38e1f42ee849a09da0fc5793fb7f051b2a4c
The call of wfGetLangObj( $lang ) is not necessary anymore.
Keep $lang as optional parameter to avoid the coding style check error
Required argument follows optional
Depends-On: Ibe295e7020e995eea52e319feaf59c635f8bb4dc
Change-Id: Id49201957e716ef8a2ea930b3616ca4fe6e35633
Uses new PHP 5.6 syntax like ...parameter unpacking and
calling anything looking like a callback to make the code more readable.
There are much more occurrences but this commit is intentionally limited
to an easily reviewable size.
In one occurrence, a simple conditional instead of trickery was much more readable.
This patch finishes all the easy stuf in the core, the remainder is either unobvious
or would result in smaller readability gains. It will be carefully dealt with in
further commits.
Change-Id: I79a16c48bfb98b75e5b99f2f6f4fa07b3ae02c5b
Find: /isset\(\s*([^()]+?)\s*\)\s*\?\s*\1\s*:\s*/
Replace with: '\1 ?? '
(Everywhere except includes/PHPVersionCheck.php)
(Then, manually fix some line length and indentation issues)
Then manually reviewed the replacements for cases where confusing
operator precedence would result in incorrect results
(fixing those in I478db046a1cc162c6767003ce45c9b56270f3372).
Change-Id: I33b421c8cb11cdd4ce896488c9ff5313f03a38cf
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
* Fix ResourceLoaderClientHtml to return what it was documented to
return, a WrappedStringList. It accidentally used the wrong join()
method, causing it to create a plain string too early.
* Update method documentations from ClientHtml::getBodyHtml to
BaseTemplate::getTrail for 'bottomscripts', and from
ResourceLoader::makeInlineScript for 'reporttime'.
* Update BaseTemplate::getTrail to join by new line instead of native string
concatenation.
This by itself would suffice for the most common case, but in order
to also account for the possibility of extensions using hooks for
'SkinAfterBottomScripts' that concatenate, update bottomScripts()
to pass a plain string to the hook and merge it later.
Change-Id: If0d227cb9db67229a27d489c082db790ea8e3840
The primary goal here is a defense in depth measure to
stop an attacker who found a bug in the parser allowing
them to insert malicious attributes.
This wouldn't stop someone who could insert a full
script tag (since at current it can't distinguish between
malicious and legit user js). It also would not prevent
DOM-based or reflected XSS for anons, as the nonce value
is guessable for anons when receiving a response cached
by varnish. However, the limited protection of just stopping
stored XSS where the attacker only has control of attributes,
is still a big win in my opinion. (But it wouldn't prevent
someone who has that type of xss from abusing things like
data-ooui attribute).
This will likely break many gadgets. Its expected that any
sort of rollout on Wikimedia will be done very slowly, with
lots of testing and the report-only option to begin with.
This is behind feature flags that are off by default, so
merging this patch should not cause any change in default
behaviour.
This may break some extensions (The most obvious one
is charinsert (See fe648d41005), but will probably need
some testing in report-only mode to see if anything else breaks)
This uses the unsafe-eval option of CSP, in order to
support RL's local storage thingy. For better security,
we may want to remove some of the sillier uses of eval
(e.g. jquery.ui.datepicker.js).
For more info, see spec: https://www.w3.org/TR/CSP2/
Additionally see:
https://www.mediawiki.org/wiki/Requests_for_comment/Content-Security-Policy
Bug: T135963
Change-Id: I80f6f469ba4c0b608385483457df96ccb7429ae5
Following I3404c1c2a7e, update the core skins to use
getDefaultModules() instead of the now-deprecated setupSkinUserCss().
Change-Id: I48b76938f46c1b6b683b618e7571e6fc6876cc52
This advances T140664 as well, because it encourages module
loading logic from the skin to be in this single method.
Update the tests for setupSkinUserCss(), to now target
getDefaultModules() instead, given setupSkinUserCss() no longer
provides these behaviours. Had to move where the mock object
was created so that it can be injected in the skin (previously
it could be passed as parameter). Besides, its generally best-
practice to create mocks and stubs within the test anyhow, not in
the data provider.
Bug: T140664
Depends-On: Ib2b19ba165a9d646a770702cdf1724509156b93e
Change-Id: I3404c1c2a7e8eae0b803b31f333cb9b837f43d4a
Relatively straightforwardly - we move padding-right definition into
top styles to avoid a reflow
This turned out to be a little tricker than first imagined.
The code in jquery.makeCollapsible.js finds elements marked up
as collapsible and then 1) collapses them 2) inserts a toggle button.
To avoid a reflow on the page, we have to make sure the collapsed content
is collapsed prior to the code running and reserve space for the toggle
button.
The toggle button is tricky as it is subject to i18n. However we can
access this label via a LESS variable and use a pseudo element (which
is supported by the majority of modern browsers) to preserve the space
we need. When the JavaScript has loaded there is no need for that CSS
any more.
Note on slow connections, collapsed content will not be accessible until
the JavaScript has fully loaded, however this is arguably less of a problem
then the existing reflows.
Note, there are many many many usages of mw-collapsible, because of this
this does not claim to address all reflows in all usages - but it does provide
support for the more widespread usages.
Follow up patches can be added for specific situations - for example table
of contents toggle.
Bug: T42792
Bug: T42812
Depends-On: I3388c3c4f91cdbab11e89cdc95973b688d3f1ce7
Change-Id: If9c8f0974e3a4b08e4a66d37f7f5adf67d73054e
This optimisation attempts to minimise loading the styles in places
they are not needed.
The logic is kept inside Skin::getDefaultModules to avoid fragmentation
of where modules get defined.
Update ApiParse to avoid repetition of code.
Bug: T42792
Bug: T42812
Change-Id: I59f02a7bab3baa9d43f6bc2ef1f549d9d31d8456
The siteinfo API response's 'writeapi' value is now hard-set to true,
as are the ResourceLoader variables wgEnableAPI and wgEnableWriteAPI,
to be deprecated later.
Bug: T115414
Change-Id: I54ff9428b247ba203d67aba079149393f323d5a9
This code path is never used.
When introduced in 2005 (bf0d92d5 / rSVN10709), the "Permanent link"
item in the MonoBook sidebar was a link to an oldid only when viewing
the latest version of an article (using the ID 't-permalink'), and
otherwise it was a greyed out link to nowhere to indicate you're
already viewing a permanent link (using the ID 't-ispermalink').
Later, in 2007, when the behavior of "Cite this page" item (now part
of the CiteThisPage extension) was corrected for old revisions
(1a60bd4c / rSVN21819), the "greying out" of the permalink was removed
to be consistent with the new item. Only half of the feature was
removed though: permalink was no longer a link to nowhere, but the
code in MonoBook to make permalinks that are links to nowhere greyed
out (by using different ID) stayed.
This code was then dutifully preserved when BaseTemplate, MonoBook was
rewritten, and then through several refactorings.
I think we can safely remove it. Leftover styles in MonoBook are being
removed in I58aca1f4255df14d6289e167e180dad31b546a8c.
Change-Id: I2fb3d7e0ecb3bbbd0c09774e2d86f86502a48bf1
The avoids the long delete() loop in MessageCache::replace()
and has better separation of concern.
Change-Id: I0acb0119058fa92fcafb52a5850f5dad4aaa94d2
Remove all usage of $tpl->translator->translate() with wfMessage()->text(),
which does the same thing, given the deprecated $tpl->translator->set()
and $tpl->setTranslator() methods have no callers.
These new wfMessage() callers should probably be changed to context calls
via BaseTemplate::msg() or Skin::msg() at some point, but I'm reserving that
for a separate commit given wfMessage() is what MediaWikiI18N::translate()
currently does - to reduce risk of unrelated behaviour changes.
While `$tpl->setTranslator` and `MediaWikiI18N::set` ($tpl->translator->set)
have no known callers in Wikimedia Git, the `$tpl->translator->translate`
method does have a handful of calls (although less than three, and not in
bundled or WMF-deployed repos). As such, proceeding with hard-deprecation.
Bug: T186090
Change-Id: I93d503de5515298288852ec4c150959fd688786b
These methods have no callers anywhere in Wikimedia Git.
Deprecate it now, remove in MediaWiki 1.32.
This is part of removing the legacy MediaWikiI18N class.
Bug: T186090
Change-Id: Ie2ca6a4b4f4481dc5cd81e7ed5543a05ee611f42
Removed all use from core. It was only used in a handful of other
repos, most of which have been updated already.
Bug: T140664
Change-Id: I6b1ea3221022597ca38a5cd40eee040d34d1abb8
It is the job of git and svn to provide this information/metadata.
The form was different, some with short, some with long month name
some with leading zero at the day, some without.
The year is also present in the Copyright clause
Change-Id: If006907b82b9e45f13cfa2e45d41107a95570e1a
And changed a little bit signature of Linker::titleAttrib
and Linker::tooltipAndAcceskeyAttribs. Added $options
parameter to the second one and made $options parameter
satisfied by passing an array with options, because there
is one more now: 'nonexisting' which tells to add text
about the thing that the page does not exist to its tooltip.
Bug: T19099
Change-Id: Ia76dd6db363f6add5efb8955be9e23a1f8e8476f
Clean up use of @codingStandardsIgnore
- @codingStandardsIgnoreFile -> phpcs:ignoreFile
- @codingStandardsIgnoreLine -> phpcs:ignore
- @codingStandardsIgnoreStart -> phpcs:disable
- @codingStandardsIgnoreEnd -> phpcs:enable
For phpcs:disable always the necessary sniffs are provided.
Some start/end pairs are changed to line ignore
Change-Id: I92ef235849bcc349c69e53504e664a155dd162c8
- Add public function to get user's personal tools.
- Add new level of abstraction to the creation on personal tools list items,
by enabling user to provide list of personal tools.
Change-Id: I549376af6f7380dbadfb5f3f7f7171bbe64cccd7
This will help us consolidate the various uses into one single
method which will help us drive standardisation of these defacto
widgets.
Hopefully, by being a method of the Html class, which has a very
low barrier for use will drive down the inconsistent display of
warning/error boxes across MediaWiki's products
Various usages of warningbox and errorbox have been ported over.
I've retained some more complicated usages which make use of the
parser (wrapWikiMsg) and any where id and class are medled with
- we'll probably want to consider whether we want to encourage
those going forward as they encourage adjusting the styling.
Bug: T166915
Change-Id: I2757e1f4ff2599e93a7257fc644cab69063896d2
Remove the need for skin classes to have a hardcoded string as
skinname property value. This previously created the possibility
for the value to not match the skinname in the SkinFactory registry,
which creates confusing situations where message keys and load.php
urls are crafted with the internal skinname, but all other
handling (useskin, preferences, hooks, SkinFactory, ResourceLoader,
etc.) operate on the names in the registry.
We could enforce the matching by requiring a 1:1 relationship between
skinnames and Skin sub classes, but that is not backwards-compatible
with the 1:many map that wgValidSkinNames provides, and not compatible
SkinFactory either, which supports a factory function to return an
object. This makes a lot of sense and allows Skin-classees to be
re-used and composed with injection. If we do want to enforce 1:1,
we could validate it with a structure PHPUnit test, but instead this
change just uses the injected name from the constructor (passed by
ServiceWiring, previously unused).
The added unit test shows the new behaviour. Before this change,
getSkinName() on SkinFallback would always return 'fallback',
whereas now each instance of the class adheres to the registered
name (if it differs from the default).
Update the two direct uses of protected $skin->skinname to use
$skin->getSkinName() instead to enable sub-classes to optionally
implement an alternate source for the self-name (or to hardcode
it there as before).
Bug: T173546
Change-Id: I4383dcc3094da6e3c9ac12dc6c9311128db9db6e
When 'mainpage' was used in the 'sidebar' message, the anchor would be
preserved (code in Skin::addToSidebarPlain() uses Title::getLinkURL()).
When 'mainpage' was used on its own in Skin::makeMainPageUrl() (which
is used in SkinTemplate::buildNavUrls(), and many skins use that data
to generate the logo link), it would not be preserved (the code used
Title::getLocalURL()).
Bug: T176583
Change-Id: Icc4895c08089caaa06e37ce765819829b90de0ff
