MediaWiki::emitBufferedStatsdData() is never called for the PerDbName factory,
so stats were being dropped. Instead of having two factories, turn the
PerDbName one into a proxy/wrapper around the main factory that just adds a
prefix in front of all of the keys.
Bug: T202144
Change-Id: I31e376446abb58e41353b4ca3814120d2e914104
And include tests :)
This code is independent of MediaWiki, but not really large enough to be
worth librarizing right now.
Bug: T200626
Change-Id: I022c074e8a708fb5219bc4ff4b53e7e31f60dc4b
This way it gets run during extension test runs as well.
Temporarily add a hack allowing 'wbeu' duplicates until T196962 is fixed.
Change-Id: Ic89a22a2ff4525585de9e290a1d47d22cfaaac5e
Calling SpecialPageFactory methods statically is now soft-deprecated.
SpecialPageFactory::resetList() is a no-op, and I changed tests
in core to use overrideMwServices() instead.
Methods that fell back to $wgUser now require a User object being passed.
Depends-On: Ie1f80315871085b9fd4763a265b588849d94414d
Change-Id: Id8a92d57743f790b7d8c377c033cef38d1bb24de
The following pattern of input (found in jquery.js) triggered
this bug:
call( {
key: 1 ? 0 : function () {
return this;
}
} );
The open brace changes state to PROPERTY_ASSIGNMENT (for object literals).
The colon after 'key' sets state to PROPERTY_EXPRESSION.
Each individual parts of an expression (identifiers and literal values)
is recognised with state *_EXPRESSION_OP, such as PROPERTY_EXPRESSION_OP.
The '1' after 'key:' correctly sets the state to PROPERTY_EXPRESSION_OP.
Upto there it goes well, but after that it goes wrong.
The question mark (TYPE_HOOK) in this context was wrongly switching
back to PROPERTY_EXPRESSION. That is a problem because that does not
handle TYPE_COLON, which meant '0: function' was seen together as a
sequence of continuous PROPERTY_EXPRESSION_OP where TYPE_FUNC may
not be handled.
Fixed by changing handling of TYPE_HOOK in PROPERTY_EXPRESSION to
switch states to EXPRESSION_TERNARY, and also performing a push
so that ternary handling can pop back to the property expression.
This mirrors the handling that already exists for ternaries in
the regular handling of EXPRESSION/EXPRESSION_OP (as opposed to
the variant for object literal properties).
Bug: T201606
Change-Id: I6104c839cfc3416257543b54a91b74cb4aa4193b
In PHP, `strtotime('tomorrow')` evaluates to the first midnight
after the current time.
Which means on Aug 14 at 23:59:59, strtotime('tomorrow') refers
to a timestamp merely 1 second in the future (Aug 15 00:00:00).
This causes the test to fail because this timestamp is computed
in a data provider, before the test itself starts. In order to
pass, it needs to be far enough in the future that it will also
be after the point in time where the test creates the page and
revisions in question.
Fix this by:
* ... moving it into the test itself, where even plain time()
should probably suffice, but that's for another time.
* ... using +24*3600 instead of strtotime().
Bug: T201976
Change-Id: Ice5d54af4fb7cffa8db9b657796ba6ebecdaffa0
So callers don't need to do this manually. Pointed out by Tim in T201799.
Depends-On: Ia6c36d5a650095e35093bf47e275e081e89b3daf
Change-Id: Ida62767f3ca53f99609cae01d3a20051bb92ccab
The use of global variables was deprecated in favour of
ResourceLoaderModule::getLessVars() on a per-module basis.
Also moved testLessFileCompilation case to the appropiate file as it
covers ResourceLoaderFileModule.php, not ResourceLoader.php.
Bug: T140804
Depends-On: Ib1b2808df2384473bfac47f53a5d25d7c9bbca2b
Depends-On: I96047f69d01c4736306df2719267e6347daf556f
Change-Id: If708087c85c80355c7e78f1768529b5f2e16ed07
This was supposed to already be the case, but it wasn't. The flag that
was set got cleared and never did anything.
Change-Id: Ide960f8cb9228f9a9d68c540369f122ada0a2a6f
Discovered by adding a test case that uses file_get_contents()
to pass jquery.js, and then scan the PHPUnit output for an entry
containing `return` by itself on a line where the next line
is isn't `;` - then reducing it to a test case as small as possible.
This was reduced from the definition of jQuery.event.addProp.
Bug: T201606
Change-Id: I1f907436c32630102e60e3ded7092dbeb9669fe8
I wasn't sure how to convert the rest of the occurrences in core (there
are a significant number).
Bug: T200881
Change-Id: I114bba946cd3ea8a293121e275588c3c4d174f94
Previously, $push contained:
self::PROPERTY_EXPRESSION_OP => [
self::TYPE_PAREN_OPEN => self::PROPERTY_EXPRESSION_OP
],
But $pop contained:
self::PROPERTY_EXPRESSION_OP => [ self::TYPE_BRACE_CLOSE => true ]
This meant that when a closing brace was found inside a property
expression, it would wrongly pop the stack, eventhough we are still
inside the property expression.
The impact is that everything after this is one level higher in
the stack than it should be, causing various other types to be
misinterpreted. Including in the following contrived example:
call( function () {
try {
} catch (e) {
obj = {
key: 1 ? 0 : {} // A
}; // B
} // C
return name === 'input';
} );
In the above, the closing brace at A would close the 'obj.key' assignment
(PROPERTY_EXPRESSION_OP), instead of waiting for the closing brace at B to
decide that.
Then the closing brace at B would wrongly close the 'catch' block (instead of
the 'obj' assignment). And lastly, the closing brace at C would close the
function body (STATEMENT).
This resulted in keyword 'return' being interpreted while in state
PAREN_EXPRESSION_OP instead of STATEMENT, where PAREN_EXPRESSION_OP is the
arguments list to `call()`. In an argument list, TYPE_RETURN is not valid,
which means we stay in that state, instead of progressing to EXPRESSION_NO_NL,
which then wrongly allows for a line break to be inserted.
Bug: T201606
Change-Id: I07b809a7ca56e282ecb48b5c89c217b4b8da6856
Set maxLineLength to '1' instead of messing with filler content.
This makes it easy to see all potential line-breaks, instead of only
at the 999th offset.
Bug: T201606
Change-Id: I220b145c5bc8e7d1a41efacd2a6cea738545f006
The viewBox attribute of the <svg> element allows both whitespace and
commas to be used as field separators.
https://www.w3.org/TR/SVG/coords.html#ViewBoxAttribute
Bug: T194192
Change-Id: Iae9be3e4fad3a8ffa411d7a76eee2f20cc39b718
