This reverts commit cb6a24d3c4. We were looking to find
violations other than the Gadgets extension in preparation for
removal of this feature. And... we have. And they're sufficiently
high-volume that it doesn't make sense to keep enabled until we've
fixed those.
Lower the detection severity back down until we've fixed these
new ones.
Bug: T235711
Change-Id: Ia3c047f76430584dcc49741ba2d7b7f7b2b89063
Now that we've all known violations we can safely enable this
in production. It was mainly held back because the Gadgets
extension violated it "by default" due to not checking targets
and letting core handle it. This has been fixed by f59eaacb4f72d8
in MobileFrontend and 2008def8063 in Gadgets.
Bug: T127268
Change-Id: I43aed5011f96160565f2dfc3422034d0e8fa95c4
This was previously hardcoded from three places: 1) Upon viewing EditPage,
2) Upon viewing SpecialCreateAccount, 3) For any url if the user is
logged-in (User::loadFromSession/isLoggedIn).
== User::loadFromSession
Performing cookie blocks from here created a circular dependency because
Block may need the user language for localisation, which is determined by
asking the User object. This was previously worked around by using a
DeferredUpdate (T180050, T226777). Moving this logic explicitly to the
end of the pre-send cycle in MediaWiki::preOutputCommit breaks the cycle.
This is also where other request-specific handling resides already.
== Limited effect on unregistered users
When an unregistered user performs an edit, and gets blocked,
the cookie block is not applied until they open built-in editor
or CreateAccount page. This makes it more likely for a user's
IP to change meanwhile. Either intentionally, or simply due to
IPs varying naturally (e.g. between mobile locations, or when
going on/off WiFi). By applying it throughout sessioned page
views for unregistered users, it is more likely to get set.
Similar to what was already done for logged-in users.
This commit also makes the intent of not caching EditPage and
SpecialCreateAccount explicit. This was previously implicit
through nothing having called setCdnMaxage() and/or due to
Session::persist being checked for by OutputPage::sendCacheControl.
Bug: T233594
Change-Id: Icf5a00f9b41d31bb6d4742c049feca0039d0c9d9
Phan can treat scalar types as non-interchangeable with
`scalar_implicit_cast` set to false. This patch fixes some of those
issues (which are in total >1000), namely the ones with alphabetic order
< includes/actions.
Change-Id: Ib1c6573ab899088bc319b9da9ceaffc850da3dbe
Methods that visibility was added to are; `addMeta()`, `addLink()`,
`setCanonicalUrl()`, `addScript()`, `getHeadItemsArray()`, `addParserOutput()`,
`getCacheVaryCookies()` and `haveCacheVaryCookies()`. Last but not lease, did
a few micro-optimizations to `addMeta()` and `addLink()`.
Change-Id: I94d037a5edc7131627724fd1d864000128077b0c
Reduces output by not needlessly performing a change client-side
for which we already know the result server-side.
Bug: T231168
Change-Id: I4b8749f976d04d24f85236ddd641c7a4c7f6c23a
Skin shouldn't be responsible for providing requested revisionId
nor if that revision is the current revision.
The OutputPage object has all required information (both the
currentRevisionID and the current Title object).
Change-Id: I2dbae4c6968a2b3b3cea3e09977e9579609b4cc5
Follows-up 66a011797d, which changed the reference to this
JS file to be without the indirection of ResourceLoader.
It's been deployed well over the needed 7 days, so this can be
removed now.
Change-Id: I823c0b31c4478e5e34f4191d851b6a9c83a6019b
This library was introduced in 3a30e03645, to make sure Grade C
stylesheets that apply to HTML5 elements that older browsers might
not know yet, work as expected in old IE.
It originally committed a minified version and loaded it directly
as an HTML script tag in a conditional comment. This had minimal
impact on anything else, and was easy to maintain.
In 68237fb1a7, this was changed to commit the unminified version
instead because Debian maintainers don't like packaging software
that contain minified files, despite being a simple file,
unmodified from the original (upstream publishes it in minified
form, with license header), published under a compatible free
license, and embedded in a license-compliant manner. We then
registered it as an unused ResourceLoader module, to be minified
on-the-fly at run-time.
Support for "server-registered client-unregistered" modules was
removed last week in c554ee8e64 because nothing needed it
anymore (except html5shiv apparently), which resulted in this
module being registered client-side on all page views for all
users (in latest master). This doesn't break anything, but it
is a regression performance-wise.
Restore this by (mostly) going to how it was before: A simple static
file, committed to Git, served as-is. Not related to, served by,
pulled through, nor registered with, ResourceLoader in any way.
Only difference with the original approach is that it is no longer
minified, which means a few more bytes transferred on old IE page
views, which is considered an acceptable compromise.
Bug: T201483
Change-Id: Ib0020b6bd015679b61f63eaa8109ed9b83d8ad15
In mediawiki.js, this marker has always been optional, falling back to
appending to <head>. When no stylesheets need to be after the marker
(e.g. no site styles on the wiki, and user is not logged-in), then
there is no need for the marker to exist.
In a previous refactor, I was going to do this and created an
"$append" variable in the function to do what this commit does,
but I forgot to actually use it for anything.
Test Plan:
* Local wiki, with no MediaWiki:Common/{Skinname}.css pages existing.
* When logged-out, before this change, there is a marker, now there is not.
* When creating "MediaWiki:Group-user.css" and logging in, there is still
a marker, and it is still above the <link> for that user styles request
in the <head>.
Bug: T219342
Change-Id: I2e9657f318088860916823efeb96ae4f1532974c
Clean up a few more code paths and documentation bits left behind by
Ia53d07cd8ce8ab1497294ea244c13c7499f632c7.
Change-Id: I2bb1749c45bb79b27c5a3b2e1b8ed3395e8c11e0
These methods were deprecated in 1.31, and most of the related code
was removed in b4e557f8f8 but these three
methods appear to have been overlooked.
Change-Id: Iea6c8b1b628a7b6acf9b65497966af9fc4ab662e
These implemented a since-abandoned draft IETF spec, and the code was
broken due to (1) case-(in)sensitivity issues with the Accept-Language
header and (2) the BCP47 language code compatibility workaround we use.
Change-Id: Ia53d07cd8ce8ab1497294ea244c13c7499f632c7
This starts cleaning up the programmer-visible API for OutputPage
and removed some deprecated untidy parser modes.
Change-Id: Ib464b57248f114b68424ec1175d36ad86d1319ad
The ResourceLoaderModule::isRaw() feature and the ability to magically
switch a regular load.php request into raw mode is being removed soon.
Instead, specify raw=1 in the request url where that behaviour is needed.
Bug: T201483
Change-Id: Ie4564ec8e26ad53f2de1a43330d18a35b0498a63
You can now create ResourceLoader modules for arbitrary sets of OOUI
icons. This is an alternative to I8af783666a2b23a938af93c1b56fee619219eaf5.
Update dependencies of OOUI's modules to use custom icon packs instead
of default icon packs.
Bug: T160690
Change-Id: Icf9560da79c91e56c7a3f4c0de01dd057f5aa00d
T208768 introduced the PermissionManager service that can now be used
for page specific permission checks. This change replaces remaining calls
to Title::userCan() with the new service in MediaWiki core.
Bug: T220191
Change-Id: Ie45e0cb6aa49a8c66147b470946161fc18160fc1
Output::sectionEditLinksEnabled(), ParserOutput::getEditSectionTokens() and
::getTOCEnabled(), ::setEditSectionTokens(), ::setTOCEnabled have been removed.
Change-Id: I7fe927776e2451bafb96ef5c4ee500497ec3734c
