The fancy mobile editor doesn't support undo, but we can just use the
fallback (no-JS) editor. The experience is not very friendly (e.g. due
to two-column diff), but it works.
Previously we showed an old-school alert() message and then loaded the
fancy editor as if it was a normal edit, ignoring the undo parameters.
The whole thing is rather hypothetical, since there are no links to undo
in the mobile interface. See T191706.
Bug: T191706
Change-Id: I5147ada9e85d9188f19ae898fdd411985d19182f
* Page edit action (#ca-edit)
I guess it became always visible when no-JS editing was implemented?
* User page creation CTA (.edit-link)
I'm making it always visible in Ie2fc6d43ebc03626517eec21bf4738dca05152d0
(which also makes it available for no-JS editing).
* Section edit links for nested sub-sections (.in-block > .edit-page)
No idea about these, but they are clearly always shown (even in
non-article namespaces).
Depends-On: Ie2fc6d43ebc03626517eec21bf4738dca05152d0
Change-Id: I226cb1fd1e716078a4a34ed8349d5304428964cf
This is a MobileFrontend feature, implemented
in ExtMobileFrontend::getUserPageContent().
Having the test for it in the Minerva repo made
it harder to make changes to it. Adding it there
in I6e763cd6b6763c60d2ad47bf384f739dfb1a07c0.
Depends-On: I6e763cd6b6763c60d2ad47bf384f739dfb1a07c0
Change-Id: Id1692b50f3f0d282c8aea4c45b63845f418e0970
This reverts commit 6daf19dfb5.
Mobilefrontend change was reverted meaning this test should be
restored here so we continue to have coverage.
Change-Id: I2e8eeacaf01aa61040405501d69f329fe3a9bbd6
It was limited to the main namespace since its introduction in
Ieabe8f7071696cde6afbdc6df853aacdb741a4a3. Unfortunately that
commit does not explain the reason.
It should be shown e.g. on user pages (so that sandbox pages
look like the real article) or on project pages (many policy
or help pages on Wikipedia are long and would benefit from it).
It looks like some of the CSS code already assumed that the
TOC would be shown in all namespaces (space for it was reserved
using a 'visibility: hidden;' element on all pages).
Bug: T205312
Change-Id: Id6935f5a7a3701c1c7a38fb37b48b6a3bbc80393
Config added inside SkinMinerva is subject to the rules of HTML
caching and can take several days [1]
Adding it via the onResourceLoaderGetConfigVars hook reduces the
cache time to minutes [2], giving us more control over the experiment's
enabled state.
[1] T124954
[2] https://www.mediawiki.org/wiki/ResourceLoader
Bug: T205355
Change-Id: I18cb40afe405e2f6a89a7ce5a924eb855aed5430
This is a MobileFrontend feature, implemented
in ExtMobileFrontend::getUserPageContent().
Having the test for it in the Minerva repo made
it harder to make changes to it. Adding it there
in I7cac24cf64422212196439bf49598ed749d5fafa.
Depends-On I7cac24cf64422212196439bf49598ed749d5fafa
Change-Id: I93e0f195b3cad1ae83ee2ae3b5b4c5f08944882e
This code could never be used under normal circumstances since
a crucial bit of it was removed from MobileFrontend in 2015:
(I65e943b6dad8bfea994020f9f555bd095da1a171)
// Allow us to distinguish sign ups from the left nav to logins.
// This allows us to show them an edit tutorial when they return to the page.
if ( $query['returntoquery'] === 'welcome=yes' ) {
$query['returntoquery'] = 'campaign=leftNavSignup';
}
…and honestly, that's for good, because it fails horribly
when triggered by adding &campaign=leftNavSignup to the URL
manually: clicking "Start editing" in the callout navigates
you to an article called "Undefined/leftNavSignup".
Bug: T205325
Change-Id: I0e385488be5b2eaa7d489029b91e18b336c0d133
'returnto' is, in fact, set a few lines above this comment,
since 2013 (I1553ee71f4f9ffec8462e3f9b85de9f39d921204).
Change-Id: I20ab084b3ddf59d338268f00a7f2306c9e2bd2b3
Unlike other skins, Minerva wants to be in charge of when WikimediaEvents
is loaded, so that it can guarantee load order happens at a time that
suits it.
WikimediaEvents will be loaded after initialisation of the interface.
This allows Minerva to enable schemas such as ReadingDepth conditionally.
Upon merging this patch, Ibb45f40ea301727c0c6480043760bd9426106845 can
be merged which will revoke WikimediaEvent's ownership.
Merging in this order will ensure that ReadingDepth is never
removed from production.
Bug: T204144
Change-Id: If8395033f31485aca0ca3b38fda1be985369b481
Updates QUnit test files from starting with "test_" to ending with
"test.js" in accordance with the Readers Wed coding conventions.
https://www.mediawiki.org/wiki/Reading/Web/Coding_conventions
Bug: T197884
Change-Id: I98877e3fc432b6edd0c53d834ef23b3ef8fb7d6a
In I1a471f81cc9390fc9e8665a7a336cf2dd7a063ab we excluded
edit events that led to the creation of a new page.
This restores them by providing a dedicated home for this data
in the schema.
Additional changes:
* Address some line length warnings
Bug: T204073
Change-Id: Ie7eb95f15737e94b7926d38ed6411bc0e5df2404
This event is meant to track attempts to edit the page we are on,
but also happened to catch clicks on "see talk page" links, in
case that talk page doesn't exist yet.
Bug: T204073
Change-Id: I1a471f81cc9390fc9e8665a7a336cf2dd7a063ab
dev-scripts/pre-commit is unused since 5037568 which added the
pre-commit NPM package. Remove the script.
Change-Id: I7b7e11415dc6ada17a5fe6bc1a390cc5de80851a
- Enable ESLint caching with `--cache` which presumably improves
performance.
- Forbid warnings by setting `--max-warnings` to zero. Code containing
warnings should not be committed. However, warnings are still an
exceptionally useful distinction to make from errors during
development. When hacking, we do not care if a comment exceeds the
maximum line length or if a trailing space is present but we do oh so
very much care if the linter detects a likely programming error such
as forgetting to initialize a constant. The former is a warning and
the latter is an error.
- Forbid unused lint directives by enabling
`--report-unused-disable-directives`. This setting prevents outdated
ESLint error waivers from littering the code.
There is a related pull request to move these settings to defaults in
eslint-config-wikimedia itself:
https://github.com/wikimedia/eslint-config-wikimedia/pull/82/files#diff-46af3d30ba7affc4adf37ef4c5382c39
Change-Id: If3c99ff7309eafb1ebefa4c4b451299b45db4e60
They no longer depend on Minerva's variables and can be moved there.
See I964b23bf9363233e5fc927cfaf1e8bdbc3435de1.
Bug: T202978
Change-Id: I6ce2156c29dcf8a95015ffdf59d02ecc5a03b74f
We need to load these only when VisualEditor is loaded. This is
the best way to ensure that. They have been haphazardly placed
in different files.
The goal of this change is to move content styling for Minerva out of
mobile.editor.ve/minerva.less, and thus to be able to move this file
to mediawiki/extensions/MobileFrontend (T202978). But I spotted the
other places while working on that.
Moved as-is:
* skins.minerva.content.styles/links.less
* mobile.editor.ve/minerva.less
No longer needed:
* skins.minerva.content.styles/text.less
Parsoid now uses <sup> tags for references rather than <span>,
so the existing rules for <sup> tags are enough. See T45094,
<https://www.mediawiki.org/wiki/Specs/HTML/1.6.0/Extensions/Cite>.
Was never needed:
* skins.minerva.content.styles/thumbnails.less
The styles from the core module 'mediawiki.skinning.content.parsoid'
are never loaded, so we don't need to override them.
Bug: T202978
Change-Id: I45e1cb89b65a41a29d2b1a361a79199745ccec14
There should be no visual changes in this commit.
The goal of this change is to stop using variables from
minerva.variables, and thus to be able to move this file
to mediawiki/extensions/MobileFrontend (T202978).
Bug: T202978
Change-Id: Ib4b3206f724c3e6f089e626b704dc8ff790a76ae
Requires Ia13f758a6870be2e6c89fd11f2ee3544ac61a1d7 in
mediawiki/extensions/VisualEditor to be merged at the same time.
There should be no visual change if both are merged.
The goal of this change is to stop using variables from
minerva.variables, and thus to be able to move this file
to mediawiki/extensions/MobileFrontend (T202978).
Bug: T202978
Change-Id: I28278449512ed1e5e8c4ac6ae390334a26d1bad6
If18ad1ff9363fff65d3e347c01ce4bc0669b2a0e introduced some skipped
tests. This restores them.
* NotificationsBadge test was failing due to some failures to stub
* clicking on the product of createBanner failing due to no action occurring
in the test body.
Change-Id: I4c1f407912767737f7cd1e9884a2e7db0baabf75
This exposes two broken tests:
* #setCount (Eastern Arabic numerals)
* clicking on the product of createBanner() should trigger a custom event
that were previously passing due to buggy assertions.
Change-Id: If18ad1ff9363fff65d3e347c01ce4bc0669b2a0e
