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
MobileFrontend's Drawer component already adds a mask that covers
the whole screen intercepting any clicks to the `body` tag and as a
result handles hiding the drawer when clicked.
Therefore, this code is redundant.
Change-Id: I7cb9ee240400e5bb0f7ca8480cd5321210ed1d7d
The Drawer API was changed in Ib123efe6af1b167706a73c71c860c85e7f439cc5
to have clients in charge of appending drawers to the DOM.
To reflect and make AMC outreach drawer work with these changes, the
amcOutreach.js code in MF was refactored in
I8aa3f2c1fe1f638810a20a5e77eb5f2e2f6addd1 to make the showIfEligible
method return the drawer instead of calling show on it.
This work refactors Minerva to make use of both of these changes.
Additional changes:
* Removes amcOutreach click handler for talk button. Talk button is a
tab everywhere except main page (I think) now so this code is just
confusing.
Bug: T242491
Depends-On: I8aa3f2c1fe1f638810a20a5e77eb5f2e2f6addd1
Change-Id: I01afe765cbcb5e79e419a3e42b3125f513e1f87e
This class is used for the main menu exclusively. Applying it
will reveal 2 transparent shields on top of each other when is
not desired
Bug: T214049
Change-Id: I8ddcc7082c3c602a78084157c2d613366a8016c7
