This removes the need for the init module.
Bug: T340751
Depends-On: Ibcc81c90bc9ba6c5fd012c512daf861973b03b2e
Change-Id: Iec3a4c6b00288aee376af47e778c4aa67a98d29b
It makes no difference to directly assign Codex Design System for
Wikimedia colors as values instead of re-assigning the outdated
`@wmui-color-*` variables.
Bump to required MediaWiki core version >= v1.41.0.
Also put stylelint-disable before the block it's actually needed.
Bug: T334934
Change-Id: I5696f160d39ef4edec7a1b966fe7e73608c86bdc
Note that this .match() method is not the one you think it is.
This is StringStream.match() from the CodeMirror lib, not ES
String.match().
Change-Id: Ief5048ff78bcd035482e7a68044e24592d28cb6c
I did some reverse engeneering and derived the three base colors for
nested templates and parser functions as well as links, together with
a formula to calculate any mixture of the three.
You can manually compile the .less file:
lessc resources/mode/mediawiki/mediawiki.less resources/mode/mediawiki/mediawiki.css
Then compare:
git diff --word-diff=color -w HEAD^ -- resources/mode/mediawiki/mediawiki.css
You will see that some numbers change. These are rounding errors in
the old .css code.
Bug: T307188
Change-Id: Ic534a2fac73f9f737ae5238b87aa80b705b37786
Get rid of the flag, without making any substantial changes to the
code. A follow-up commit will merge the CSS into base rules.
Bug: T307188
Change-Id: I601df5047d0db3cfb9559538487d3d39bb6c7cf4
When there are standalone special characters '<', '[', '{', and '~' in the section header, the ending '=' will not be highlighted while the ending characters in the next line are incorrectly highlighted. This is because the ending '=' is eaten as plain text at the end of function eatWikiText(). A less aggressive plain text matching does not hurt.
Bug: T309143
Depends-On: I47dad71df97f38c55550f71baf6dae67dbe0a2ba
Change-Id: I4a9c6c6cb2f7fbc212808e386124a56676fdbfb1
Including an user options to enable/disable the scheme. Defaults
to false. Feature is only availible together with the new more
accessibile color scheme as the CSS depends on each other.
Set behind a new temporary feature flag.
Bug: T305027
Change-Id: I46d240a30eda5a1526ada1fe9b724f7b4594b426
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
Fixes the issue with the change handler not working.
Bug: T303767
Depends-On: Iee4c885f92dd9ec985a3f9fd92a2fafc00f2e9ff
Change-Id: Idb97a67f940eee69e09679196d0de71e76ef3672
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
Currently, only registered parser tags are included in the list of
extension tags to be highlighted. This patch allows extensions that do
not register their tags as parser tags (Extension:Translate) to still
define them for highlighting using the existing CodeMirrorPluginModules
annotation.
This patch also removes the special-casing for <translate>, as it can be
defined in Translate instead.
Bug: T284883
Co-Authored-by: Tacsipacsi <tacsipacsi@jnet.hu>
Depends-On: I860c944eaeeb7771629a1ed2352c05cfd8d7ca80
Change-Id: Iba2b0b874ebbace7a892af9e1d9896e8b17ade78
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
My previous patch Icbb1122 focused on the behavior of the
matchbrackets addon when the text is *edited*. This patch here
is about moving the cursor without changing the text. I
realized the addon re-draws everything every time the cursor
moves, even if the highlighted pair of brackets is still the
same. This triggers very expensive code in the CodeMirror lib.
I had a look at this expensive code, but did not found an easy
win. It just is what it is: an expensive re-draw. Instead I
introduced a caching layer that remembers the positions of the
previously highlighted brackets and bails out as early as
possible when nothing changed.
The biggest chunk of code is that "did something change?"
comparison. It looks expensive, but typically isn't. There are
typically only 2 elements in the array for a single
opening–closing pair. (Possibly more when there are multiple
text selections.) The elements in the two arrays are typically
in the same order. (Except the cursor is on the closing
bracket.) Which means the nested `every` → `for` loop will
typically be executed 2 times only – one time for each of the
2 elements.
I won't upload this change upstream because it is only relevant
together with our custom "in the middle" bracket highlighting.
With our customization we have many, many situations where the
highlighted brackets don't change. This (almost) doesn't happen
upstream.
Bug: T270317
Change-Id: I789b45362388f0818e797f789f6af427a35e3e06
While working on T270317, I realized the performance of the
matchbrackets addon is not as good as described in
T270237#6739993. The issue with my original benchmark was that
I did it with a single pair of brackets with thousands of
characters between. A paragraph with thousands of brackets
behaves much worse. So bad that I feels painful when moving
the cursor.
Lowering the limit to something in the middle (between the
original 1000 and my 10000) makes it behave much, much better
on my machine.
Bug: T270237
Bug: T270317
Change-Id: I31f850f4c7778d6b5ff1d0eb17fdaf0edf7ae019
My upstream patch was accepted within 9 minutes:
https://github.com/codemirror/CodeMirror/pull/6565
Note: This backport includes another upstream commit that fixed
some typos.
Bug: T269096
Change-Id: Ib5b64214d7536bc952886f45290d537eab2f9bbb
The addon does have 3 settings:
- maxHighlightLineLength is for the current line where the
cursor is. Bracket matching is simply not done when the
current line is longer. The default is 1000, which is rather
low.
- maxScanLineLength is for every other line that is scanned in
the process. I don't understand why, but this limit is 10x
higher.
- maxScanLines is the number of lines that can be scanned.
Simply raising the first to be 10000 as well fixes our issue.
Note that CodeMirror does have a limit of 10000 anyway. It's
called maxHighlightLength there. Lines that are longer get
syntax highlighting only for the first 10000 characters. The
rest of the line is black. Using the same limit in the addon
makes it's behavior consistent. Means: The user can see when
the syntax highlighting stops, and bracket matching stops
working the same time.
I benchmarked with both settings. It doesn't have a measurable
effect. Bracket matching is done in <1ms in both cases.
Bug: T270237
Change-Id: Ia56bf4c2fb023c9f117376242221d39f51196173
Less ambiguous variable names. Less duplication. The minor
issues have been introduced in T270317.
Bug: T270317
Change-Id: I366396a61b76e19293ce8d14c2f346b97498fe40
I continued profiling the matchbrackets addon for T270237 and run into
performance issues that turned out to be unrelated to the addon. The
flame graph highlighted a "match" function. Note this is not the
String.match() from JavaScript, but something in the CodeMirror lib:
StringStream.prototype.match = function (pattern) {
var match = this.string.match(pattern);
if (match && match.index > 0) {
return null;
}
return match;
}
(Note: I simplified this code so we can focus on the bug.)
When the pattern is a regular expression, it's executed via
JavaScript's String.match(). The function then checks if there was a
match and if it's at the start of the string. If not, it's not a
match and doesn't return one.
In other words: Even if there is a match somewhere in the string, the
function acts as if there was no match.
When we change all patterns to be anchored via ^, they don't scan the
entire string any more but return much ealier when there is no match
at the start of the string. We are effectively replacing nested loops
(hidden in the patterns) with single calls.
This bug exists since 2014.
The disabled line in the matchbrackets addon is just dead code. I
don't remove it to document the fact that we disabled it.
Bug: T270237
Bug: T270317
Change-Id: Icbb1122e6a3b26c0606726ff405e108931d185be
The addon does support some configuration options. These are passed
as properties of the `matchBrackets` CodeMirror option. Just passing
the boolean there hides that fact.
Bug: T270317
Bug: T270237
Change-Id: Iaa4b5ed8ef538e76cd1c96a09485e143112f1ae0
This patch also removes all remaining FIXMEs. This code is not
a bottleneck. There is nothing to do.
Bug: T270317
Change-Id: Ie034440c98d8064a22811a1b569237dddb7b7436
We "forgot" to update this addon when we did the update in
I6f0f030 (T258999).
Bug: T258999
Bug: T270317
Change-Id: Iab29e9e36f34b76551ddac497e40dc76669ba7c7
Optimizations for the code introduced in Ic403e0a:
* Skip this entirely when something is selected (as discussed
in Ic403e0a).
* Use a combination of existing methods. I benchmarked these
again. This approach is "significantly" slower compared to
the custom code from before. However, "significantly" here
means something like 1 nanosecond vs. 4 nanoseconds. Both
is effectively nothing.
* Use the same approach in another place. This one is triggered
every time a change is made, e.g. a character typed. I
benchmarked this as well. The new code is about 500x faster
(yes, seriously).
Bug: T269094
Change-Id: I00fe595a89be7a257e27ed28d38568c81483338b
The fallback technique makes the whole edit surface semi-transparent,
so reset native selections to full opacity.
Change-Id: If6cd585b1a09c549781fe82a3bdf18d64ac597b5
* using CodeMirror addon matchBrackets
* highlights the matching bracket of a pair
* highlights brackets when cursor is inside a pair
* feature usable in source code editor
Bug: T261857
Change-Id: Ib01d9919a47bb29684b54501644b01936b57972a
I had to make some CSS selectors more specific, because the
library changed
.CodeMirror pre
to
.CodeMirror pre.CodeMirror-line,
.CodeMirror pre.CodeMirror-line-like
This is only relevant for entire lines (implemented as <pre>
elements). Most of the custom CSS is for characters, not lines.
In my tests in the Wikitext editor as well as VisualEditor I
could not spot any difference between the old and new version.
Bug: T258999
Change-Id: I6f0f030f972838727f3ef220feb105264f122798
The rgba() syntax is supported for a very, very long time now:
https://caniuse.com/#feat=mdn-css_types_color_alpha
Notes:
I realized the numbers in these file names are actually their
transparency in percent (more precisely their opaqueness).
4 is 4% which translates to 0.04 in the rgba() syntax.
I used Gimp to pick the opaque color values from the images.
Gimp makes this easy. No guesswork or calculations needed.
For multiple, stacked images I calculated the colors by
averaging their RGB values (considering how opaque each color
is). Note this is actually *more* precise than the stacked
images before. Stacking alpha colors is flawed. For example:
Let's say we have an rgba(255, 255, 255, 1) background.
Layering a half transparent rgba(255, 0, 0, 0.5) on top means
half the background shines through. This averages to
rgba( 255, 127, 127, 1). Now we stack rgba(0, 0, 0, 0.5) on
top. Again, half the background shines through, resulting in
rgba(127, 63, 63, 1).
When we apply the two colors the other way around, the result
is rgba(191, 63, 63, 1), a much brighter red.
This flaw doesn't happen when precalculating the averages, as
done in this patch.
Change-Id: I29026864714c5f90c2613af57f08693e7e2b996c
The spellchecking was disabled for Firefox on non-Mac systems because
Firefox had a bug and inserts characters (like B) into the content when
enter an access key combination (like Shift+Alt+B).
Firefox 65 fixed the problem by changing the default for
dom.keyboardevent.keypress.dispatch_non_printable_keys_only_system_group_in_content
from false to true.
The old behavior can activated in about:config by setting
dom.keyboardevent.keypress.dispatch_non_printable_keys_only_system_group_in_content = false
This change reverts 29f6b48eeb.
Bug: T177509
Change-Id: I23773b2ea2a154269a5b3064cd8d9e9132051c38
Problem: browsers implicitly and unexpectedly set the font-size to something around 13px with `font-family: monospace;`, but not with `font-family: monospace,monospace;`.
See: http://code.iamkate.com/html-and-css/fixing-browsers-broken-monospace-font-handling/
Bug: T176636
Change-Id: Ied24a0cde7db4a6092d2cd7a6207d0a361424c3f
Related: T245568
Related: T245476
Move this stuff to Timeless itself since we can just reuse the width cutoff
and padding variables directly there and don't need to worry about them
randomly changing.
Corresponding change: Ic64b9786cb7186dba3eb2042a3238149c3bb44c6
Bug: T230756
Change-Id: Ia7168341bcadbc60e307b58b67afc1975a2424f9
Also refactor out single use functions and call enableCodeMirror
from within addCodeMirrorToWikiEditor.
Change-Id: I77d37ae401483e187fe0bc355d7173b57fbe454b
CodeMirror inserts
style="padding-right: 0.1px;"
only on Webkit.
The test case now strips this pattern from the rendered HTML before
comparing with the expected test case output.
Change-Id: I34b201f790d3d85a5f51d8200bf8219f11d14506
VisualEditor's default padding for the source editing surface was
changed in Icdc6f1e2a7544ebbd828f85ff370113a0e06983a (June 2018).
Since then the alignment of editing surface and CodeMirror syntax
highlighting surface was broken in skins that don't override the
default padding (basically every skin except Vector and MonoBook).
Unfortunately Vector and MonoBook happen to be the only skins we
officially support and actually test, so the issue went unnoticed.
Bug: T205154
Bug: T205658
Change-Id: Ic85a6c20b266f6b93ab8ec9c2d35acff679f31bc
