Turns out the MediaWiki parser behaves odd when confronted with syntax
like this:
<ref name="a>b"> … </ref>
XML and HTML parsers are usually expected to respect the pair of double
quotes. But our parser doesn't. What it actually does is this:
<ref name="a"> b"> … </ref>
This change makes the syntax highlighter behave the same. This makes it
easier to spot this issue when editing wikitext.
Bug: T270880
Change-Id: I14bdf6630889fb6d0dea53890a693f00d9356f54
A common issue, reported in VPI as Possible Thursday weirdness, with
source editor users using syntax highlighting is that the caret can
often be misplaced as to where the user selects. This PR adds code
to reload CM when loaded to adjust for this behavior.
Moved to after CM has finished initialising. Tested working.
Add another instance of codeMirror.refresh().
Bug: T305333
Change-Id: I9a81ffd41a3ba1321b7b5744ba096583cbb1d96c
Add support for enabling, resizing, and disabling the new
realtime-preview feature.
Bug: T293347
Bug: T303767
Change-Id: I8c8c25fe56be55a61f4b8d1d2ef8cf74483aa241
The resulting code style in this file is a little mixed. I tried to
stick to the existing style. Most notably is the indention with
2 spaces instead of 1 tab. But I couldn't disable the spaces inside
round brackets. They make the code so much more readable.
What this patch effectively does is enabling the eslint check for our
custom code in this addon, excluding all old code, and exclusing a few
rules that conflict to heavily with the old code style.
Change-Id: I12f953cb0a6fd35e405b6cc348abfb2c11e70696
CodeMirror is already able to highlight multi-line tags if the tag name is followed by any non-whitespace characters in the same line. This commit fixes the other condition where the tag name is followed by whitespace only in the same line.
Bug: T201684
Change-Id: I8cb4a53ee0fe7fc8612a58331a1a3e57d00d7630
When CodeMirror is focused/blurred, the same event will triggered on its corresponding textarea.
Bug: T197632
Change-Id: Ib71b6774a60dd434bdc8a27b9eab433dcc1c65f0
HTML and extension tags should be highlighted as the text of internal or external links.
Bug: T184341
Change-Id: Ib1f2047936b395afd86720e2a7c921e382229cdd
The same already happens when switching it off, see line #249.
I noticed there is still a (random?) chance the selection gets lost
when switching back and forth between syntax highlighting on and off.
This is not what this patch is about.
Bug: T298488
Change-Id: I541f96be9e6fb2f9032df4b86657d01f0eac5679
* What we care about is the <pre>. The class="CodeMirror-line" is
added to every <pre>. We don't really learn anything new when we
include it in our tests.
* Testing the ARIA role is testing a CodeMirror feature, not a
feature of the mediawiki mode under test.
Change-Id: I33bfedb304228240c4e835cc983117668c398c61
Now css rules applied to pre tags can easily affect the appearance of CodeMirror output, may intentionally or not.
With the line-break attr set to initial can make the appearance more stable, users can still override this with the more specific rules if they do want to.
Bug: T252965
Change-Id: If0d29ad152151c09ace2bcd32d2953ec3c9cf1aa
I forgot this when I added this test case in I03a1e1a.
Also:
* Use another method to detect if the Cite extension is active. This
is the same method used in the actual code.
* Move a line of code into the `if` it belongs to.
Change-Id: I1efd3f945150aeb08db3c771e579d9a6114a4c21
* Append to the hidden #qunit-fixture instead of directly to the body
* Use the right selector when cleaning up
Change-Id: I8be38900e6c5f4592f06dfc8f7c2cfc348627716
This works by accident due to the CWD being mediawiki-core in most
cases during web requests, and Less.php implicitly falling back to that
as path expansion point when all attempts to expand the path fail (e.g.
relative to current file, and relative to a supported Less import dir
such as core `mediawiki.less/`.
Importing raw files from elsewhere in core is unstable, and is not
supported as this fails on some webserver configurations, as well as
in CLI contexts such as maintenance scripts that rebuild a cache, or
otherwise end up (in)directly computing part of a ResourceLoader
module.
The use case of themeing extension styles to the current skin (with
Vector using WikimediaUI) is subject of T112747 and T265941.
Follows-up I9eb07dd43.
Bug: T296639
Change-Id: I6d2be2941d6088b947ea7f18818add97f129760d
This patch also minifies existing code. Note that [] is true in
JavaScript, unlike in PHP.
Bug: T285660
Change-Id: Ic80903ebd1364505fd4aaf7f53b53324a235fd79
This allows gadgets to react to the changing editor (for example
to rebind event handlers on the new active editor) without having
to use something like an MutationObserver.
Bug: T284282
Change-Id: I83f0a3c29b01031ae370b7d1207457586f0d25d6
In T270880 an example with a slash in <ref name="a/b"> is
described. The same issue happens with several other characters
including the closing bracket, e.g. <ref name="a>b">. This patch
fixes all of this by accepting _all_ characters between double
and single quotes.
Bug: T270880
Change-Id: I03a1e1a25af692dc703b44a57b2d23d6fc15c8c9
Introduces a new config variable `CodeMirrorLineNumberingNamespaces`
that can restrict line numbering to only appear for specified
namespaces. Setting to null enables everywhere.
This takes some liberties with the `lib` module, turning it into a
container for shared functionality. This can be pursued in later
work, by cleaning up duplicated code in this repo.
FIXME: failed to deduplicate the code for now.
Bug: T267911
Change-Id: Ida2b33eef38edc57d29756ec472c6f2c83bd7b11
The issue can be reproduced as described in T278840. What
happens is that an (auto)clear is triggered and removes all
marks, but the cached values in `currentMarks` remain. The next
time the same marks are found, they are discarded and don't
show up, because the cache says they are already there, when
they are not.
Bug: T278840
Change-Id: If83bd99e924f579854cfe4b01fab4ef86892933b
Adds a custom class for matched brackets to allow better integration
with custom bracket styles. The brackets won't be bold in the 2017WTE.
Bold font might lead to misalignment there. See ticket.
Note: box-shadow seems to be supported for quite some time by all
relevant browsers
Bug: T270926
Change-Id: Ica1e301f63a106a96db3bfaba4b2f322af64b009
These changes to the color scheme are hidden behind a feature
flag for the time being.
Bug: T271895
Change-Id: I0a4b03e0f3bc8239f31edbbd5ae55661607b76f6
This does not have an effect any more with all the other
optimizations in place.
This reverts commit 094f20902c.
Bug: T274369
Change-Id: I288039a35270093bd22b5a073e70f6b769088c13
I was wondering why the performance when editing wikitext is
still so bad, and profiled it again. Turns out
StringStream.match() is still the bottleneck (even if already
100 times better than before Icbb1122).
The method is called with many different patterns from
mode/mediawiki/mediawiki.js. I profiled them individually and
found a single outlier. The idea is the same as in Icbb1122.
A pattern that is able to find something *in* a string is
doing nothing but wasting time, as StringStream.match() ignores
every result that is not at the start of the string.
The change adds the missing ^ anchor and wraps the regex pattern
from mw.config.get( 'wgUrlProtocols' ) (that is something like
"ftp:\/\/|http:\/\/|https:\/\/|…") in (?:…), which is a
non-matching group. This is necessary because of the | in the
pattern. The result is a pattern that looks like /^(?:…|…|…)/i.
I remember looking at this code while working on Icbb1122, but
didn't include it in the patch, and then forgot about it.
Bug: T270237
Bug: T270317
Change-Id: Iea2fd116b68704c3186b0edf965006cc7c6eda82
