Our eslintrc extends from 'wikimedia/client' which includes a
'no-restricted-properties' ruleset from the 'not-es5.js' file [1].
However, we were also including our own 'no-restricted-properties'
rules.
ESLint handle this duplication by clobbering instead of merging
so eslint-config-wikimedia's no-restricted-properties where not taking
effect and we were losing out on some guards against using es6.
This commit corrects that and makes both no-restricted-properties
rulesets merge instead of clobber as already done in MobileFrontend [2]
[1] 07320f16ae/language/not-es5.js (L5)
[2] https://github.com/wikimedia/mediawiki-extensions-MobileFrontend/blob/master/.eslintshared.js
Bug: T239269
Change-Id: Ibc2c144be51719d71a4c1d5828486253a5d4bf5d
Our eslintrc file extends "wikimedia/client" which already includes all
of the previously listed jsdoc rules [1]. Therefore, we were clobbering
this much more thorough list.
This commit removes this clobbering and enables a much more extensive
list of jsdoc rules. Additionally, downloadPageActions was made to
conform to the rules.
[1] 07320f16ae/common.json (L99-L137)
Bug: T239269
Change-Id: I19c09054ba0bf2746ac78befc1b44426352113ec
It's called 'markup'. Since this icon only ever shows to logged in
users there are no caching implications.
Bug: T244444
Change-Id: I75f5365ccb5a41f1c0628532e81b5ec63804a2a8
"login", "watchlist" and "logout" in skins.minerva.personalMenu.icons
are already defined inside skins.minerva.mainMenu.icons which is
loaded on all page views via CSS so we are loading this icon twice for
no obvious reason. This is why ResourceLoader modules should never reference
files outside their own module folder!
Change-Id: I2097802cc2d42483ef4bdd1ccfa05e0f7b1bcad4
This reverts commit 7b4b65a30f, which
caused a regression in the user menu part of Advanced Mobile
Contributions mode.
Bug: T244436
Change-Id: Ifce627dac35b2cd05e1c5ebe658534b6b8d0de88
This also means we can now get rid of the rlModuleLoader module
and make all OverlayManager routes synchronous form now on.
Depends-On: Iacea45ea5ac7332d61a33041bbd25ea4830e1375
Bug: T214641
Change-Id: I73cb622bbda44f4cfe51d08189419e15003b9d91
Those have been introduced into MF's .svgo.yml a while ago in
I9b3bf1bc9652aab2586055c826bba1b3d0c7d58d but due to the code
split those important rules have not yet made it into MinervaNeue.
Change-Id: I71f650bc2a0bfa61f20a8e849a714e4fb3891e30
As far as I can tell, this is unused and the invoked method doesn't
cause any side effects. Therefore, I think it can be safely removed.
Change-Id: I8b507b4bf38a8a0e70684165d8a48c2d284cdd11
* Drop non-existent pointer-overlay selector
* Drop redundant icon class for arrow
* Drop unnecessary !important
* Drop transparent-shield class
* Reword an existing FIXME about a contensious decision and
add a new FIXME for moving some code to a more appropriate place.
* Move an image into a ResourceLoaderImage module (test with
`mw.notify('error', { type: 'error'} )`)
Change-Id: I6e38f07772afae6f13c4851ca17a67d52ca7d331
Previously it always used the global context RequestContext::getMain(),
which is basically equivalent to using $wgTitle or $wgUser, and will
not produce the correct results when used in other situations than
regular web requests (e.g. API requests or jobs).
MinervaPagePermissions is required to parse pages (due to the custom
section edit links in SkinMinerva::doEditSectionLink), which is often
done in API requests or jobs.
Pass the appropriate context in SkinMinerva::getPermissions(). This
fixes T234868. Note that MinervaPagePermissions is also used elsewhere
and I am not fixing those cases.
Depends-On: Iaa83e5f801c7776bf8218d8ce7484e2485b227d4
Bug: T234868
Change-Id: I2d6fd525f20a0b6beeeaa731f6b8caa471b8529d
Add a script that builds CSS for Minerva using lessc than measures
their bundlesize.
This will give us added protection to large increases in bundlesize
that can lead to performance regressions.
Change-Id: I2e5e55ad10fac7ecb5a8c19ccdf3cc54de59b75d
All stylesheet-only ResourceLoader modules now have a single entry point
rather than multiple files. This eases compilation of the content of
those modules by all toolchains, which will be useful when introducing
the bundlesize tool.
Change-Id: Ic38a3e51db2f419fe68efd23a2c48ee69218a526
This makes use of the ResourceLoader change in
I1c1e2b912a41d29565e45e9e536c68ac46deb0e1
Bug: T217616
Change-Id: I30632a8c12abf634fc8031ac588c36a412c7abbd
* Fix styling of empty lines - cover full width
* Disable the pseudo element shipped in core
* Move styles from mobile.special.mobilediff.styles into mediawiki.diff.styles
since the latter is always present, the former isn't if MobileFrontend is not
available.
Bug: T242310
Bug: T243235
Change-Id: Ic7d12fe890622e7b3ccc7bc56765f505ac0ab651
Clicking on any talk page section should now open it regardless of the
characters in it. This includes ascii and non-ascii characters.
There are two changes done here:
1) When a user clicks on a section, `window.location.hash` is set to the
percent encoded version of the associated id attribute of the section.
This is important because, unfortunately, different browsers can encode
characters that do not conform to RFC 3986 (illegal URI characters) [1]
differently when calling `window.location.hash` again [2] (e.g. chrome
encodes `>` as '%3E' while safari leaves it as '>').
2) Register the encoded version with OverlayManager. OverlayManager will
simply do a strict string equality check when checking if the current
path matches. Because the browser will navigate to the percent encoded
version in step one and this version does not contain any illegal URI
characters, `window.location.hash` should give back the same percent
encoded string and the paths will match across browsers.
**Why not put this logic in OverlayManager?**
Alternatively, we could make OverlayManager decode the current route's
hash fragment and make it compare that with the unencoded version of the
id similar to the work in
I9cdaf3b01c2e5fe25512b6c18dcf6787c4422abd. However, ids with the '%'
character would then pose problems (e.g. `decodeURIComponent('100%')`
throws an error). This would require extra logic in OverlayManager to
differentiate client supplied '%' characters from browser encoded ones.
Making OverlayManager responsible for normalizing hash fragments will
make it more complicated than it already is. However, making the client
only register routes in OverlayManager that conform to RFC3986 from the
start avoids all of this logic at the expense of making the client make
one call to encodeURIComponent (if necessary).
If this patch is agreed upon, then the next step would be to change the
jsdoc `add` method in OverlayManager to be explicit that it will only
work with URIs that conform to RFC3986 and the client should percent
encode if necessary before registering.
[1] https://tools.ietf.org/html/rfc3986
[2] https://bugs.webkit.org/show_bug.cgi?id=180396 (Thanks to TheDJ for
pointing this out)
Bug: T238364
Change-Id: Idc2cfac51c40f585c5d43713d8edf848b10424fd
