Each can be selectively embedded by placing the /* @embed */ comment
just before the url() value. /* @embed */ at the beginning of the rule
affects all url() values appearing in it.
Three changes in existing behavior for previously supported syntax:
* /* @embed */ comments are no longer preserved in output
* rules not terminated by semicolons are correctly supported
* spaces within url() values are correctly supported
Bug: 46757
Bug: 56514
Change-Id: If9082f553fa920c606f12093f39f4a163ebacc32
Also added commented-out tests which should work, but don't.
Making them work in subsequent patch If9082f55.
Change-Id: I65f62493e6d10e7e90af8844f8a26e3982d75f51
We just need to negate the horizontal offset value in both of them.
This only supports *a single shadow* per element; multiple shadows
are not supported (only the first will be flipped).
Second attempt. First, reverted one: I14822955.
Bug: 45677
Change-Id: I97ee7431e1a5acb35d594076a88a0f9acf290402
The values are not "top right bottom left" here, but
"top-left top-right bottom-right bottom-left".
Bug: 49074
Change-Id: I22bc777b59e667aeb36727fdc8e41e8681979128
The 'color' rule, and by extension 'four_notation_color' too,
only understood #rrggbb and named colors. Extend it to match
rgb[a](...) and hsl[a](...) syntaxes as well.
This makes usage of rgb(a)/hsl(a) syntax in declarations like
'border-color: a b c d;' be interpreted and flipped correctly.
Change-Id: I218a9aa55a86b3d955b92375c1a209fdde312138
Don't mangle 5+ consecutive numeric values in the
'four_notation_quantity' and 'four_notation_color' rules. This
prevents box-shadow rules from being utterly broken in RTL (but still
doesn't flip them properly).
Bug: 45677
Change-Id: I16cb9e171a79c6f299b40fa02908b0c045e3c474
We just need to negate the horizontal offset value in both of them.
This only supports *a single shadow* per element; multiple shadows
are not supported (only the first will be flipped).
Also, to make it possible:
* don't mangle 5+ consecutive numeric values in the
'four_notation_quantity' rule
* support rgb(a) and hsl(a) colors in the 'color' rule
Change-Id: I148229558e1b9a0516e413ffe86007235c3c3ef8
Fix almost all occurences of the following sniffs:
Generic.CodeAnalysis.UselessOverridingMethod.Found
Generic.Formatting.NoSpaceAfterCast.SpaceFound
Generic.Functions.FunctionCallArgumentSpacing.SpaceBeforeComma
Generic.Functions.OpeningFunctionBraceKernighanRitchie.BraceOnNewLine
Generic.PHP.LowerCaseConstant.Found
PSR2.Classes.PropertyDeclaration.ScopeMissing
PSR2.Files.EndFileNewline.TooMany
PSR2.Methods.MethodDeclaration.StaticBeforeVisibility
Change-Id: I96aacef5bafe5a2bca659744fba1380999cfc37d
Then 'stdclass' is preceded by T_NEW and taken as a class name.
Else it was misinterpreted as a function call.
Change-Id: Ib6afccb26e530a24bf7414ede10f573a9934d2ed
Calling the method does not raise an exception but a notice (depending on settings).
PHPUnit just happens to turn this into an exception. The test thus breaks if PHPUnit
does not do this, which apparently happens in some cases and caused bug 41491
Change-Id: I9d14fd875c70c8b3d164c0b8a4fa2667c5769682
This code is meant to replace the current interwiki code, but does not do so just yet. It is however used by the Wikibase extension. This allows us to try out some more things and have the code stabilize more before we migrate over existing interwiki functionality.
Change-Id: I23c47c2c3909a1500350fb560a5f2ec654e2c37e
This commit depends on the introduction of
MediaWikiTestCase::setMwGlobals in change Iccf6ea81f4.
Various tests already set their globals, but forgot to restore
them afterwards, or forgot to call the parent setUp, tearDown...
Either way they won't have to anymore with setMwGlobals.
Consistent use of function characteristics:
* protected function setUp
* protected function tearDown
* public static function (provide..)
(Matching the function signature with PHPUnit/Framework/TestCase.php)
Replaces:
* public function (setUp|tearDown)\(
* protected function $1(
* \tfunction (setUp|tearDown)\(
* \tprotected function $1(
* \tfunction (data|provide)\(
* \tpublic static function $1\(
Also renamed a few "data#", "provider#" and "provides#" functions
to "provide#" for consistency. This also removes confusion where
the /media tests had a few private methods called dataFile(),
which were sometimes expected to be data providers.
Fixes:
TimestampTest often failed due to a previous test setting a
different language (it tests "1 hour ago" so need to make sure
it is set to English).
MWNamespaceTest became a lot cleaner now that it executes with
a known context. Though the now-redundant code that was removed
didn't work anyway because wgContentNamespaces isn't keyed by
namespace id, it had them was values...
FileBackendTest:
* Fixed: "PHP Fatal: Using $this when not in object context"
HttpTest
* Added comment about:
"PHP Fatal: Call to protected MWHttpRequest::__construct()"
(too much unrelated code to fix in this commit)
ExternalStoreTest
* Add an assertTrue as well, without it the test is useless
because regardless of whether wgExternalStores is true or false
it only uses it if it is an array.
Change-Id: I9d2b148e57bada64afeb7d5a99bec0e58f8e1561
* Per https://bugzilla.wikimedia.org/show_bug.cgi?id=27395#c1
adding test cases for things that broke in the past:
- bug 26931
- bug 27046
* Added various other small tests that seem fitting in their context
* Moved testBug32548Exponent to below the data provider (like most
other tests iirc).
Change-Id: I7a4df097108ec05bc58d5a110329e13ff9587c8a
r103915 added a parse error for 'more than 2 decimal points' in a number; this is the wrong place to check for that. Should only check whether there's more digits or identifier chars -- identifier chars would be illegal.
Added test cases for the exponent missing fails, tweaked it to be more consistent (only need to check for one e; if we have more we can lump them in with 'not digits' :)
Also cleaned up no-longer-needed suppress/restore warnings around JS parser invocation
This will trigger 2 test failures, where an exponent in a JS numeric literal gets split over line breaks at the '-' or '+', causing a parse error in the resulting output.
A number with the same string length but without using + or - in the exponent passes through fine, indicating that it's the -/+ that's getting misinterpreted.
Followup r91591, r93020: patch to jsminplus to support Unicode chars and char escapes in identifiers
Fast-path check keeps runtime about the same on most scripts (eg jquery.js parsing was abround 4100ms both before and after on my test machine)
Slow-path code kicks in if plain ASCII word chars don't extend all the way to the next whitespace or punctuation char.
Using PCRE's Unicode properties magic to ensure that we're catching everything, following ECMA-262 edition 5.1 spec.
Note that identifiers using escapes don't get normalized to their UTF-8 form; this might be a nice thing to do as it saves a couple bytes, but currently there's no change made to output.
Added QUnit tests to verify that unicode letter & escapes work in identifiers in all supported browsers (ok back to IE 6, yay)
