- In Vue.createMwApp, provide `mw.msg` as the CdxI18nFunction,
which will be used inside Codex components to get translated
messages for certain strings
- Include Codex messages in CodexModules that use Vue components
- Add the codex i18n dir to the LocalisationCache message dirs
and to the banana config in the Gruntfile
Bug: T368449
Change-Id: I24477f5f6dcb34ad1c0959d60cdf221e859db5ce
Chrome breaks on Apple ARM (e.g. Mac M1 or M2) when run from within
Docker (such as fresh-node), because Chrome is incompatible with
Rosetta emulation for Intel, thus making it hard to run tests locally.
Firefox works fine in this regard.
Depends-On: I6f8546e6e604cbb41e11bd2b59f8b5f19350c676
Change-Id: I6ecbd5743f3ed0d639b79cb08c8ff279e6ad9ff6
* Remove limitation to `.js` files, so that edits to Resources.php
and any .json files are considered as well.
* Add watching of the skin.json and extension.json file itself.
* Allow `--qunit-watch` to work without `--qunit-component`,
defaulting to watching MediaWiki core.
I would have liked to widen this to simply watch `extensions/**` and
`skins/**` by default (and when component != MediaWiki core), because
that way it will also re-run automatically after changes in an
extension dependency (e.g. from core to an extension, or
from a dependency like EventLogging to NavigationTiming). However,
Karma uses the popular "chokadir" which ironically chokes and runs out
of available operating system file handles in an attempt to crawl and
watch every file recursively. This unlike qunit-cli which uses
node-watch and the Node.js 12+ native file watcher API. Perhaps for
something to revisit in the future.
Change-Id: I2bb7f0df510f84872a2381bdebe3f2b59cc80705
Mozilla has stopped shipping the `Firefox.app/Contents/MacOS/firefox-bin`
entrypoint for macOS, instead favouring `Firefox.app/Contents/MacOS/firefox`.
This broke the launcher and requires a minor patch.
Pending an upstream release, use our fork for now. We can transition
this to a simpler setup without Karma (i.e. launch browser directly),
but for now we can patch it in this way.
Change-Id: If99f030b1b23be6b906a15bfdb72590fc249cb0c
jsduck is preventing us from using ES6 syntax and has not
been supported for some time. It is also difficult to setup
locally due its use of Ruby.
Introduce jsdoc and remove jsduck per T138401#9335987
Link to static copy of jsduck explaining the state
This does the bare minimum - the docs are built to the folder
docs/js/index.html and only one module is ported over to allow
us to provide feedback on the end result.
Bug: T138401
Change-Id: I1a351ac5aec731bb79a877023ac10988ec3ec786
When CHROMIUM_FLAGS is unset, as it is if you're running Chromium
outside any container (like fresh-node or Quibble), the splitting of
the empty string results not in an empty array but in an array with
an empty string. In other words `[ '' ]` insteadf of `[]`.
This means when Karma formats the browser launch command, and joins it
with a space, it runs `chromium --foo --bar http://localhost`
notice the three spaces between "bar" and "http".
This was fine in Chromium for ten years but Chromium 110 changes the
way it parsers the command-line arguments such that it will interpret
this as launching Chromium with two URLs, of which one is the empty
space. While regular Chromium supports starting the browser with
multiple tabs at once, HeadlessChrome does not.
Bug: T335329
Change-Id: Ie8a1ee7a0b16ca6dfd7a8293e0bf686a48141c8c
Follows-up I39f5d84504783c91d54b3d309064b546cd40e311.
* Fix bug where qunitWatchSourceFiles was assigned instead
of qunitWatchSourcePattern.
* Use array push and spread instead of needing filters. Alternatively
could use undefined vs object for a slightly simpler filter.
* Use separate let statements instead of legacy one-var style.
* Move vars to the inner-most block that needs them.
Bug: T250045
Change-Id: I6c63788d07fc27c31db63dce6da1bf1e9a661806
The doc folder contains (committed) json files with schema definition
for json files
That should be linted as well to spot syntax errors easier
Change-Id: I20ff7abf6b98d2247ee52e2d2b43af88c062f779
Add a --qunit-watch option to the Gruntfile, when used with
--qunit-component, the test and source files for the comopnent
will be watched and tests re-run on file change. Chrome headless
browser stays open as well, which results in faster overall
test execution time.
Bug: T250045
Change-Id: I39f5d84504783c91d54b3d309064b546cd40e311
This silences the "Unable to determine file type from the file
extension, defaulting to js" warning shown when running `grunt qunit`.
Bug: T250045
Change-Id: Ife62c53d1e2ff6121774552c7d0793784aea6d6b
Usage:
* DiscussionTools tests: `grunt qunit --qunit-component=DiscussionTools`
* MediaWiki core tests only: `grunt qunit --qunit-component=MediaWiki`
It might be nice to have this more granular, to run tests for a single
file, or a single ResourceLoaderModule, but will leave that to another
time; it is already fast.
Note that some projects may fail, e.g. GrowthExperiments has a test
failure due to not mocking all of the dependencies needed for the
test code; that can be worked around by adjusting the application code
or the test registration to include all needed dependencies.
Example fixes:
* GrowthExperiments: Iea3a89a902cd17dd91696d2a37144baa9e452077
* MinervaNeue: I8f747e3df196055361d53d00fea833fb9de892f0
The only other extension I see that has one broken test when run
this way is VisualEditor.
Bug: T250045
Change-Id: I977150ece26f5878a0ccc42d39bed6c7e74e9602
Was first attempted in f1eaa06d5e,
and reverted in 0b3fe4fe8c. Now this
is done in eslint-config-wikimedia for all repos.
Change-Id: I9ee735eef40085b6373b565838d67e186e438657
This reverts commit f1eaa06d5e.
Reason for revert: accidentally allowed ES6 syntax.
Looking for a way to redo this that doesn't break our linting as badly.
Change-Id: I78974b97001bdbea9aff5717c69d71b8a2582ade
This was here from a year ago when we added CHROMIUM_FLAGS, which
has since rolled out.
Also make the assert-mw-env less fragile by checking the
env variables in one place each instead of two places. Before this,
it was relatively easy to accidentally add a warning for one, without
the shell exit code changing.
Change-Id: I6b85483981b415fe251b3760d5f282433e7fc4e9
Install eslint-plugin-vue, which lints JS inside <script> blocks in
.vue files, and also lints Vue templates. Configure eslint and stylelint
to run on .vue files. stylelint automatically picks up on CSS in <style>
tags.
You may have to change a setting in your text editor or IDE to make it
run eslint and stylelint in .vue files. For eslint, see
https://eslint.vuejs.org/user-guide/#editor-integrations ; for
stylelint, I had to install the linter-stylelint-plus Atom plugin then
add source.css.embedded.html to the "Base Scopes" setting for that
plugin.
Change-Id: I7e6a13317792fc25c29106739b0c24864fd8d301
Trying to get away with returning a single code and parameter-list that
was supposed to represent both human-readable and machine-readable data
was a mistake.
This patch converts it to use DataMessageValue, which represents the two
separately and also provides guidance for supplying translations of all
the error codes.
This also eliminates the "describeSettings()" method that was trying to
serve multiple use cases (in terms of the Action API, action=paraminfo
and action=help). It's replaced by two methods that each serve one of
the use cases. Also some of the functionality was moved out of the
TypeDef base class into ParamValidator, to better match where the
constants themselves live.
Also I wound up creating a NumericDef base class so FloatDef can share
the same range-checking logic that IntegerDef has. I probably should
have done that as a separate patch, but untangling it now would be too
much work.
Bug: T235801
Change-Id: Iea6d4a1d05bb4b92d60415b0f03ff9d3dc99a80b
Follows-up fa63a70ae9 which enabled this for CI to investigate
a Jenkins-specific issue, but it makes for a very noisy and visually
unpleasant local experience because these Karma lines interweave
with the structural output from the qunit/karma reporter.
With this change applied, the local experience from 'npm run qunit'
has clean output again like so:
```
…
mediawiki.storage
✔ set/get(Object) with storage support
✔ set/get(Object) with storage methods disabled
✔ set/get(Object) with storage object disabled
mediawiki.template
✔ add
✔ compile
✔ get
Finished in 13 secs
SUMMARY:
✔ 440 tests completed
```
Change-Id: I21555468ed30ca3a2220eba1d8a78cc140a13399
Also:
* Remove "watch" task from Gruntfile.
This wasn't exposed via npm-run and afaik rarely if ever used.
It seems mostly obsoleted by modern editors which perform
linting and style guidance as-you-type and on-save.
* Remove "chromium" target from karma config, the default
target supports both Chromium and Chrome.
* Remove unused "default" alias in Gruntfile. Was only
accessible if developers installed grunt-cli globally, which
we don't require and shouldn't encourage. The new minify task
is now exposed as "npm run build".
* Remove "test" alias in Gruntfile. Was only used by "npm run test",
which now uses "grunt lint" directly, which makes it more clear
that these are only linters, and not unit tests.
This references T211784 because ensuring no headed browsers are used
(which would need Xvfb to start), is a prerequisite for the new Node 10
images. We may still need to provide a slower Xvfb-wrapped variant for
some repos, but would be nice of mw-core wasn't one of them.
Bug: T211784
Change-Id: I270a16d2b4f799ac7c9f84e9e2ee23806bdbc57e
Adding 'grunt-svgmin' package and corresponding 'svgmin' task and
also crush SVGs. Several of them are featuring bad UX and are not optimal
in many different angles (a.o. clarity, universality, recognizablity etc.).
Specifically the 'mediawiki.skinning' ones.
But while they are here, let's make them suck less.
Change-Id: I8191ceac14565ae31d941982fab1586fa9b6bbdd
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 was added in (r99923; 4d8c7e96ed) while reviewing the
'gadget-preferences' branch in SVN of the Gadgets extension during
development of MediaWiki 1.18, intended for use in a color picker
on Special:Gadgets as part of an experimental feature that was
never completed (r94051).
The module has no usage anywhere in Wikimedia Git, nor in any
third-party hosted repos indexed by MediaWiki Codesearch, nor
anywhere on-wiki at WMF in site scripts (per mwgrep).
Bug: T193826
Bug: T192623
Change-Id: I8ed6c09dc7efd750ad4688b895b2e3f808a0e52b
Single-file modules to src/, the remaining as sub directories.
A few highlights:
* mediawiki.Upload.BookletLayout. (stylesheet: no image references)
* mediawiki.feedback - Also move the image to its own images/ subdir.
* mediawiki.searchSuggest. (stylesheet: no image references)
* mediawiki.toc. (stylesheet: no image references)
Also updated any other references to 'src/mediawiki/' that I could find
in core:
* Fixed references in docs/uidesign/*.html
* Remove redundant exclude from jsduck.json.
After this, there are 4 files remaining in src/mediawiki,
which are the 4 files used by the actual 'mediawiki' base module.
Bug: T193826
Change-Id: I8058652892a78b3f5976397bd850741dd5c92427
Keep the main file in src/ for now, because it's got some whitespace
changes and a closure-wrap that make it differ from upstream's
version. Those changes are hard to review both for diffing and for
functional differences due to its odd-looking scope assignments that
I'd rather not change as part of this.
Change-Id: I248831cfa984432d0a30aa923a9bcd98029b05c4
Doesn't seem to add anything, except complexity.
This has the benefit of matching more closely the way the README
recommends running individual tests.
Also add a check for 'chromedriver' before running it.
Normally the -e and pipefail would suffice, but because
it runs in the background, the error can be buried,
hard to find, or even not cause exit code to be set
properly. Thus, do a simple 'hash' check that will
print a useful command and exit cleanly.
Before:
> $ something &
> [1] 57922
> -bash: something: command not found
> [1]+ Exit 127 something
> $ echo $?
> 0
After:
> $ hash something
> -bash: hash: something: not found
> (exit: 1) $ echo $?
> 1
Change-Id: Id95f18927b5443defe679a77a82c5cbdd127c716
Both Mocha and Cucumber tests should run. Since WebdriverIO supports only
running one test framework, the only way to do it is to have a generic
configuration file and two framework-specific files (Mocha, Cucumber). Having
Jenkins configuration file complicates things, and there is no need for
it.
Bug: T179190
Change-Id: I710066f7b5479dcad27aa57cd61007c1c2d88931
