Requested by a user at https://www.mediawiki.org/wiki/Topic:Vkk1ahk3eggd9747 for
whom their hoster provides curl but with multi-threaded functions removed for
some reason.
Change-Id: Id3877c600ae02feffb67f74a815430f8e679230a
Had no visibility defined; no deployed uses outside of the file:
https://codesearch.wmflabs.org/deployed/?q=-%3EshowDiff%5C(&i=nope&files=&repos=
Also removes use of Revision::getContentHandler.
Bug: T249561
Bug: T250981
Change-Id: Iaab55713eb616780c0b2b7429ad099b5d19fd73c
Using Revision is not deprecated yet
Bug: T250608
Depends-On: Ic13220b3120dbecd83685ce3553c5b5a6c1e7fdd
Change-Id: I648cb62460f6ca20217a21c462e842d82ae06613
The instructions regarding requiring a TLD are no longer valid. '*' can be used by itself.
Bug: T241958
Change-Id: Iadc3c09bb2db330950f27ee12fc36585c18f71d1
Returns a Revision object; only deployed uses are in core
Make fetchRevisionRecord public as the replacement
Also removes a use of Revision::getContentHandler
Bug: T249393
Bug: T250981
Change-Id: Ib8f399e451c3a9b942001b48ea9a138f405c894c
Hard deprecate and rewrite call of proxy methods
Deprecate Article::$mContext. It should become private
Bug: T239975
Change-Id: I92018a02b00fdc0b6cd90dfc77ad27782322f344
This test was an awful, awful, mess. (And I take full responsibility.)
Changing the global user language mid-way into execution is in no way
supported by ResourceLoader and this test was going through great
lengths to fool mw.loader about what's really going on.
Basically, all we're doing is get a list of instructions on what tests
to run, get comparison values based how the PHP side proceses these
(for parity comparison), and then run the assertions.
The mw.language singleton already has support for multiple languages,
and mediawiki.jqueryMsg already supports injecting data and constructing
new instances for each test case. Make use of that :)
Instead of calling ResourceLoaderLanguageDataModule::getData by
trying to hot load the same module repeatedly from load.php,
just export this data using 'packageFiles'.
The mediawiki.jqueryMsg QUnit suite previously took 4s to run locally
and now only 0.1s (145ms). This is not only significant for this
particular module, but also for QUnit in general as Headless Chrome
only took about 7s to run all of MediaWiki core's test suites prior
to this change, which is now down to ~3s. (MacBook Pro)
For WMF CI:
* Before (master commit):
- mediawiki.jqueryMsg.test: ~2.1s (2135ms)
- MediaWiki core total: ~4.8s
* After (this patch):
- mediawiki.jqueryMsg.test: ~0.015s (15ms)
- MediaWiki core total: ~3.6s
Bug: T250045
Bug: T225730
Change-Id: I5f1067feb0a43d63bfc5e7fff5110285a5e433c8
== What
This feature is disabled initially because we want to be able to
test it. When mw.loader's own tests are testing mw.loader.store,
they are mocking setTimeout and mw.requestIdleCallback, so that
they can then make mw.loader.store schedule its "flush" callback
and via the mock timer control when it executes and then assert
its result.
== The Bad
Previously an inline JS hack was concatenated right after startup.js,
and that seems like it should be early enough to prevent anything
from initialising mw.loader.store and scheduling a real 2s flush timer.
There is no obvious sign here that the startup module response would
request or implement a module (which could inititialise mw.loader.store).
However, there is.
== …, the Ugly
The startup response contains RLQ processing (which is empty in
the standalone test runner, so no worries here) and a call to
mw.loader.load for RLPAGEMODULES. The RLPAGEMODULES list is empty,
but it does still make a call to mw.loader.load(). And that
expands the empty array to include jquery+mediawiki.base and thus
makes a proper module request, which then initialises mw.loader.store
and schedules its 2s flush timeout.
This hasn't caused failing tests in CI so far, because there are
generally at least 2 seconds of unrelated tests that run first.
So by the time mw.loader's test suite comes around, it has
been disabled and the previous flush has already completed.
== … and the Good
Change I5f1067feb0a43d makes the 'mediawiki.jqueryMsg' test suite
super fast (previously took 2+ seconds, longer than any other test).
This exposes the fact that mw.loader.store was in fact not
actually properly disabled from the get go, and so tests would
be failing.
Bug: T250045
Change-Id: I38c3ad2a9a5813215dbb210bddafcc3cdd70295d
* Remove calls to setHeaders(), disallowUserJs().
These never do anything because the 10 lines of standalone HTML
page outputs don't consult OutputPage or Skin.
The exception was the 404 handler for if you visited
Special:JavaScriptTest/bogus, where there is nothing to protect,
not to mention that the page is disabled by default and in any
production environment anyhow.
* Inline the 404 handler logic.
* Update the outdated documentation for exportQUnit().
Bug: T250045
Change-Id: I2b9d712f439b270ae998e994113b7f3cd8601abf
The intro text visually renders the same without it. The parsed
message already has its own block (a paragraph).
This div is a left-over from when the test runner was a skinned
page, and we had some CSS to style it in a fancy way. All that
was removed many years a go in favour of the 10-line standalone
HTML testrunner we have today.
Bug: T250045
Change-Id: Iffcca90857cf8e5df09a9287ab22fad109df7b79
Much less indirection this way, making the test runner a bit easier
to reason about (maintenance-wise) and easier to debug for developers.
Minification doesn't help here anyway (quite the opposite).
This also means the legacy option to load a module synchronously
from ResourceLoader\ClientHtml can be removed. This option existed
solely to bootstrap the QUnit test runner, and can be removed in a
subsequent commit.
Bug: T250045
Change-Id: I73985048382e9cc754753ed84f04d25214c07599
This will make it easy to later allow the user to select which
component's specs to load and run (via CLI and GUI), e.g. for
an entire extension. We currently only have very narrow or very
wide selection mechanisms ('module' param for 1 module,
'rerun' for 1 test case, 'filter' param for global pattern match).
Bug: T250045
Depends-On: I55fe27e1c74972fcb3cdafefdc78e10e24f95b80
Change-Id: I5c01f720d787c3847228de511ce913284786ad66
