Follows-up I361fde0de7f4406bce6ed075ed397effa5be3359.
Per T253461, not mass-changing source code, but the use of the native
error silencing operator (@) is especially useful in tests because:
1. It requires any/all statements to be explicitly marked. The
suppressWarnings/restoreWarnings sections encourage developers to
be "lazy" and thus encapsulate more than needed if there are multiple
ones near each other, which would ignore potentially important
warnings in a test case, which is generally exactly the time when
it is really useful to get warnings etc.
2. It avoids leaking state, for example in LBFactoryTest the
assertFalse call would throw a PHPUnit assertion error (not meant
to be caught by the local catch), and thus won't reach
AtEase::restoreWarnings. This then causes later code to end up
in a mismatching state and creates a confusing error_reporting
state.
See .phpcs.xml, where the at operator is allowed for all test code.
Change-Id: I68d1725d685e0a7586468bc9de6dc29ceea31b8a
Expected value is the first parameter to assertSame() or assertEquals().
And turn to use assertCount() for some assertions aginst count of array.
Based on code search `assert(?:Same|Equals)\(.+,.+expected` and I look
through files roughly, so some assertions that don't contains 'expected'
are also fixed. In the meantime, some assertions that I am not clear
about are not touched.
Change-Id: I75798b60d29fd19b33f4fdf34ed3c788db420d01
Many communities for historic reasons use "messagebox" to style
certain templates. Going forward we aim to make sure all internally
produced CSS classes are prefixed with "mw-".
A user notice has been run notifying editors that this is potentially
a breaking change with directions on how to update their CSS in
preparation for this change.
Bug: T270796
Depends-On: Id258e328d1691f7bd31d2b3c57d64d5434706561
Change-Id: I2df24431ec72641b63fbe2fc929025a53459c06c
This reverts commit 066e77735e.
Reason for revert: Objections brought up on ticket by Esanders are in alignmenet with own objections, that arose after initially providing this patch. We need clarification that is better addressed in new patch, reverting this.
Bug: T270796
Change-Id: Id873b3e3b7efb3003daa4986225b1fb3e7e218c8
The name change happened some time ago, and I think its
about time to start using the name name!
(Done with a find and replace)
My personal motivation for doing this is that I have started
trying out vscode as an IDE for mediawiki development, and
right now it doesn't appear to handle php aliases very well
or at all.
Change-Id: I412235d91ae26e4c1c6a62e0dbb7e7cf3c5ed4a6
Add public, protected or private to function missing a visibility
Enable the tests folder for the phpcs sniff
Change-Id: Ibefce76ea9984c47e08c94889ea2eafca7565e2c
Adding optional $className parameter to provide additional
styling options.
Optional parameter $heading was introduced for MobileFrontend. Therefore
leaving inconsistent parameter order is necessary for the time being.
Bug: T232903
Change-Id: I5857b2c58a47a83156c32f086a73fe2bd48ab0c8
assertSame() is guaranteed to never do any magic type conversion.
This can be critical when accidentially comparing empty strings (a
value PHP considers to be "falsy") to false, 0, 0.0, null, and such.
Change-Id: I2e2685c5992cae252f629a68ffe1a049f2e5ed1b
The value of "all" can be completely arbitrary and in practice
it's usually an empty string. Avoid attempting to filter it out
and format anyhow.
Bug: T227202
Change-Id: I371466407bd038914faa4dc3b0cae9547cf427eb
The name of the test class and method as well as the @covers tags already
explain well enough which code a test is testing. Repeating this does not
provide additional information.
Change-Id: Ieec4ec131e5925d11704a11e1df46bc00c9fad9b
Asking users to select from a list that is in a namespace
other than their user language can be quite difficult.
Transition a number of use cases. This was applied via a flag
to avoid unexpectedly changing extensions also utilizing
the namespace selector.
Pages updated:
* Special:Search
* Special:Watchlist
* Special:RecentChanges
* Special:Contributions
* Special:Import
* Special:WhatLinksHere
Bug: T174057
Change-Id: I3fdac72179a124849ef7ad1e0e54eb66396c3c6e
The tests here were only testing when user and content language
are the same, but the way things are rendered when they differ
is perhaps more interesting as it allows ensuring the two are used
in the correct places.
Change-Id: I357f50b082882fee485a95323d3a0a7cadb9a63c
There are three problems with the CDATA approach:
1. It doesn't work.
HTML5 already interprets the contents of <script> tags as CDATA,
which means escaping of characters like & is not needed. In fact,
in HTML5 mode, a plain script tag with <script>0&1;</script>
would be a syntax error. Indicating it is not interpreted as
text, but as CDATA. Effectively, the only thing an HTML parser
looks for is </script>.
And that's exactly the problem. Producing an inline script
containing the characters "</string>" for legitimate reasons,
is currently broken.
No alternate wrapping or setting can make it work, either.
See also:
https://people.wikimedia.org/~krinkle/200506-html-inlinescript.html
which contains:
<script>/*<![CDATA[*/
if (true && true) {
console.log('This is a <script></script> tag (original)');
}
/*]]>*/</script>
In a browser, the script is terminated by the first "</script>",
leaving the code unfinished, throwing a SyntaxError, and outputting
the rest of the script as plain text on the page.
2. CDATA is only for XML mode, whereas MediaWiki does not support
the XML/XHTML output mode (since MediaWiki 1.22). Instead, we only
output HTML (5). Code that does need to produce XML, should use the
class from Xml.php instead.
3. It gives a false sense of security.
We could just remove the CDATA code as-is and that in itself would be an
improvement per point 2 and 3, and would break nothing per point 1.
However, this commit attempts to address the underlying bug by rejecting
the characters "</script>" from input. If this is needed in a literal,
it is the responsibility of the caller to escape it in a way that is
appropiate for how it is used (string, comment, regex, etc.).
There are two ways this can be used currently in core:
* User input as exported through JSON (e.g. mw.config, or mw.messages).
This is already fine as both FormatJson::encode and json_encode handle
escape either < or / in the string by default already.
* Previews of edits to user scripts. This is currently already broken and
causes the script to end early and produce arbitrary HTML on the page.
This commit limits the impact by refusing to output such script in a
broken way. I will further address that use case in a follow-up.
Bug: T200506
Change-Id: I67ceb34eabf2f62fd3f3841b8f1459289fad28fb
This asserts current behaviour in preparation for changing it
in a later commit (see T200506).
Bug: T200506
Change-Id: I76fd15c32c763754d0825d02a49de3d9973c4f8f
Directly use the UTF-8 encoding of the 'NO-BREAK SPACE' (U+00A0) instead of
the HTML/XML entities   or   or .
With the UTF-8 character the generated HTML is shorter and better to read.
Also change the special value for the label in HTMLForm from   to
U+00A0 but also support   for backward compability.
Bug: T154300
Change-Id: I882599ac1120789bb4e524c4394870680caca4f4
Find: /isset\(\s*([^()]+?)\s*\)\s*\?\s*\1\s*:\s*/
Replace with: '\1 ?? '
(Everywhere except includes/PHPVersionCheck.php)
(Then, manually fix some line length and indentation issues)
Then manually reviewed the replacements for cases where confusing
operator precedence would result in incorrect results
(fixing those in I478db046a1cc162c6767003ce45c9b56270f3372).
Change-Id: I33b421c8cb11cdd4ce896488c9ff5313f03a38cf
* Messagebox is now private to Html class to discourage unconventional
usages
* Tests are added for all three helper methods added in
4e7021a231
Bug: T166915
Change-Id: I1c3e4131b2439c0f4fb94ad4e616a909b52d6b78
We blacklisted them in 2010. Modern browsers support them fairly well,
and it doesn't seem to conflict with any of our code.
I tested this with SecurePoll poll creation form, which contains an
astonishingly wide range of form controls and validation options.
Change-Id: I08244addcf9b6eb96137895f28e7b750914fef5c
Use HTTPS instead of HTTP where the HTTP link is a redirect to the HTTPS link.
Also update some defect links.
Change-Id: Ic3a5eac910d098ed5c2a21e9f47c9b6ee06b2643
It looks like there is something missing after the last statement
Also remove some other empty lines at begin of functions, ifs or loops
while at these files
Change-Id: Ib00b5cfd31ca4dcd0c32ce33754d3c80bae70641
`<command>` is nowhere to be found in current HTML5 specification.
Scarce documentation on the internet hints that it has been removed.
Change-Id: I2a704194c7e8f8ca307f9d97c7f47a47cfaf00a6
Follows-up ee4d5c6ee ("Remove support for $wgWellFormedXml = false")
Remove now-redundant duplicate tests that were previously there
to test the same thing again with $wgWellFormedXml set to false.
Change-Id: I91623a8c10e5108ffae13f67328aece2cf33c719
tl;dr: Having unnessary complexity in security critical code is bad.
* Extra options add extra complexity and maintenance burden
** Thus we should only have one html output mode. well formed = false
was already vetoed in T52040, so lets go with WellFormed=true.
* Options which are used by very few people tend to get tested less
* Escaping is an area of code where we should be very conservative
* Having escaping rules depend on making assumptions about which
characters various browsers consider "whitespace" is scary
* $wgWellFormedXml=false has had a negative security impact in the
past (Usually not directly its fault, but has made other bugs
more exploitable)
* Saving a couple bytes (even less bytes after gzip taken into
account) is really not worth it in this context (imho).
Change-Id: I5c922e0980d3f9eb39adb5bb5833e158afda42ed
It seems both of these tests assertions all expect
this to be false.
Ic675e92d8dd8f11fa67914d2ce1dc00a379106ca
ended up discovering these issues somehow
with these tests suddenly starting to fail.
Change-Id: I9d2d3c18d1c9640e2ff04d6fd4296abb86e26877
* Remove trailing space in self-closing tag.
Brings parserTest output of Parser and Parsoid closer together.
* Remove various line breaks at begin and end of script contents.
* Remove FILTER_NOMIN from makeConfigSetScript() output.
This isn't part of any user- or page-dependent module and not minified.
And Xml::encodeJsCall already ensures compact output for prod mode.
Bug: T127328
Change-Id: I85a5a59fd0955c1a112e8b24b933f0d9e983a156
Removed redundant set up in these classes (same as their paren
class MediaWikiLangTestCase does already).
* BlockTest
* ExportTest
* MWTimestampTest
* TitlePermissionTest
Change-Id: I28d18cb797bb249981727b02dffce4f0d8682b02
