Call RequestContext::resetMain() so that any subsequent call
to getMain() and getLanguage() is aware of the latest state
as set up by the setUp() and setupGlobals() methods.
The MediaWikiTestCase class for PHPUnit did this already, but
the parserTest suite and UploadFromUrlTestSuite didn't yet.
Change-Id: I6481176228944004091078704d0346c8f3fc0cf1
Right now it forgets to reset $wgResourceBasePath, which means it
is inherited from the wikis's (or Jenkins') default settings which
is typically '/w'. That caused parser tests to behave as if pointers
to /extensions were outside /w.
Also update wgScriptPath to be '' instead of '/'. Otherwise this
can cause double-slash prefixed urls.
Change-Id: Ic455d62fca8fcac2c4ecc055cc0d7e311b70a94a
* Brings us closer to the html5 attribute parsing algorithm described
in http://www.w3.org/TR/html5/syntax.html#before-attribute-value-state
* There's a similar patch for the Parsoid in,
I2160a23b2a3c914eb369347bbf5d58328440041d
* The spec says <div class= style="123">hi</div> should parse as
<div class="style=\"123\"">hi</div>, which it now does, whereas it
used to yield <div class="" style="123">hi</div>.
* Merge with caution. This is going to break pages like,
frwikisource/La_Mirlitantouille_(Lenotre)?oldid=4669681
Bug: T108134
Change-Id: Ic2fc1b573a55a847e6c05707678b58c1189ecc52
This reverts commit f51d0d9a81.
Breaks templates with non-closed </noinclude> tags, which
were previously acceptable.
Bug: T125754
Change-Id: I8bafb15eefac4e1d3e727c1c84782636d8b82c2b
* At that point, element attributes are already escaped so it serves no
purpose. Before `doTableStuff` is called, `Sanitizer::removeHTMLtags`
has been invoked which calls `Sanitizer::fixTagAttributes` which
calls `Sanitizer::safeEncodeTagAttributes` and finally gets down to
`Sanitizer::safeEncodeAttribute`, with the goal of "extra armoring
against further wiki processing."
Change-Id: Ieeb9b21148c2909eb839d13195d7d10012b48e3b
* Currently, for images:
[[File:Foobar.jpg|hi|alt=100|ho]]
caption: ho
but for galleries:
<gallery>
File:Foobar.jpg|hi|alt=100|ho
</gallery>
caption: hi|ho
* This patch brings some consistency to them.
Change-Id: I3b73189b27cc35fade4809477cf18779b953aa3b
I think it's saner to treat this as invalid syntax, and output the
mismatched tag code verbatim. The current behavior is particularly
annoying for <ref> tags, which often swallow everything afterwards.
This does not affect HTML tags, though. Assuming Tidy is enabled, they
are still auto-closed at the end of the page content.
Related to T17712 and T58306. I think this brings the PHP parser closer
to Parsoid's interpretation.
It reduces performance somewhat in the worst case, though. Testing with
https://phabricator.wikimedia.org/F3245989 (a 1 MB page starting with
3000 opening tags of 15 different types), parsing time rises from
~0.2 seconds to ~1.1 seconds on my setup. We go from O(N) to O(kN),
where N is bytes of input and k is the number of types of tags present
on the page. Maximum k shouldn't exceed 30 or so in reasonable setups
(depends on installed extensions, it's 20 on English Wikipedia).
To consider:
* Should we keep previous behavior for unclosed <includeonly> /
<noinclude>? This would be particularly disruptive for these if
someone relied on the old behavior, and they're already
special-cased in places.
* Unclosed <pre> tags are now treated as HTML tags, and are still
displayed as preformatted text, but without suppressing wikitext
formatting.
Change-Id: Ia2f24dbfb3567c4b0778761585e6c0303d11ddd0
Introduce an ogv video file to the parser file testsuite, so that we
can use it later in TimedMediaHandler parsertests.
Change-Id: I6a3b307ad9c82e9df0aeec025934d736eec8375f
I spent half an hour searching which extension was causing a crash in
my parser tests. Printing the filename seems like a handy plan here...
Change-Id: I09558101be15e92eeb3841f8f4198c2bc01f3e9d
Something is broken in the syncing worfklow. I deleted a
test that cscott added in 1888bf560.
Reverting this sync so we can figure out what is broken.
This reverts commit b55a729f74.
Change-Id: Idd32daa95bb44fd073262a1c37ded236bf724e5d
Follows-up 9cfb9cb9fb, and b62f0e9156.
Add data-mw="interface" to elements created by the interface
(e.g. not user-generated content) and use this to narrow down
scope of elements eligible for JavaScript binding.
This avoids bugs where e.g. the diff hook triggers on a wiki page about diffs.
This isn't a security issue per-se, but causing odd behaviour.
Also add missing tests for data-ooui filtering (follows-up aa9a52da).
Change-Id: I9a0c86c92d411538bd9e203ec6ae54616fdf49b8
Don't let users set attributes starting with data-mw or data-parsoid.
The main idea is to allow MediaWiki to use data-mw-<something>
attributes for trusted input to client side scripts. There have
been a couple security vulnerabilities in the past based on users
being able to manipulate a data attribute, which client side was
assuming was trusted.
Also include data-mw and data-parsoid as both are used by Parsoid
currently.
See https://lists.wikimedia.org/pipermail/wikitech-l/2015-November/083811.html
A corresponding change will also have to be made in Parsoid.
Change-Id: I06585380bde3bc57b17ad76740c5acc2056d7c44
If there are less than 3 entries, the browser still tries to render as it would
appear as if there are 3 columns, so the final rendering is broken. So don't apply
CSS columns and just show a normal list if there are less than 3 results. This also
matches the behavior of CategoryViewer.
Bug: T117887
Change-Id: Ie6ac0e1174ff8cc14008f39a91c95bcd6f616353
It is desirable in terms of user-friendly syntax to display an empty
list item if the user adds one to the source. However, we suspect that
this change will break the rendering of existing templates. So, preserve
the empty <li> element, but style it with display:none so that there is
no user-visible change. Changes can then be observed with a user script,
then eventually the CSS can be removed so that the desired behaviour will
be user visible.
This is imagined as a staged deployment of T89331, i.e. it is better to
resolve differences with Html5Depurate one at a time instead of
deploying it all at once.
The CSS module is specified in parser/MWTidy.php since the tidy driver
hierarchy is not meant to be so closely tied to the MW environment.
Bug: T49673
Change-Id: Ifb44b782c617240e3de73dcdf76c8737c7307d94
Stop using table on Special:PrefixIndex and use CSS columns instead and
removed 'column' parameter from this page.
This will also change the weird ordering (side to side) to the standard
top to bottom instead.
The pagination links hide at the corner on small screens. This can be fixed
later.
Bug: T32965
Change-Id: I720d34e21950c18de3c6e0b1d6d8a4461db495cb
Instead of having two conflicting filerepo configurations, one at
/tmp/test-repo and another at a randomized path, and populating the one
that isn't used with files, let's just have a single upload directory,
populate it with files, and then actually use those files.
This fixes a set of confusing system-dependent parser test failures. In
the failure scenario, the file upload would be recorded, but then
invalid JPEG metadata would trigger LocalFile::loadFromFile(), which
would look for the file in the wrong place and mark it missing. Then
parser tests would fail due to image links being broken (red).
This is probably not as nice as the fake in-memory repo used by
NewParserTest, but this approach does provide a richer integration test.
This is a conservative fix that just fixes the things that are terribly
broken rather than making new things.
Also:
* Clear the RepoGroup singleton, for completeness, since it doesn't
make sense to set $wgLocalRepo without clearing it. Since we now set up
a similar repo at initialisation to the one set up with each test, it
probably doesn't have any effect.
* Warn if gd is not present since this causes 49 test failures.
* Use glob patterns in teardownUploadDir() instead of requiring every
file to be individually listed. This fixes an error due to failure to
delete a 240px file.
Change-Id: I56a0e0d1cb363b40cf19c735e00cbb8929c1401a
* Split tidy implementations into a class hierarchy
* Bring all tidy configuration into a single associative array and
deprecate the old configuration.
* Remove $wgAlwaysUseTidy
This is preparatory to replacement of Tidy (T89331). I used the name
"Raggett" for things relating to Dave Raggett's Tidy, since if we use
"tidy" to mean the new abstract system as well as Raggett's tidy, it
gets confusing.
Change-Id: I77af1a16cbbb47fc226d05fb9aad56c58e8910b5
This seems to cause redirect loops in current Firefox instead.
This reverts commit a89a21990e.
Bug: T106793
Change-Id: I18fac8ab0f94e2df8476131b132c9866902a02c4
Similar to 7b4df0e12e,
but for apostrophe instead of tilde and for Opera
instead of Chrome.
Bug: T106793
Change-Id: Ic54390434cebcc76a6c8ab49acc164d36e0cdff6
Invalid HTML5 character entities become instances of UTF8_REPLACEMENT,
so we also ensure that checkCSS notices this and emits the proper
human-friendly sanitization notice.
Change-Id: I76cef7c772b1e3eba0af8dab6403e9100beab03a
