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
* Protect from setActive not being defined on the old toolbar button
* Use role is switch on the button, since WE only supports simple
buttons
* Add the checked attribute to reflect state of the toggle button
Bug: T196512
Bug: T197534
Change-Id: I48dfef1740f124105f65859ce4f51098f1157fd0
This patch makes Codemirror on VE independent of the beta feature,
making it always load.
This is a first step to graduating CodeMirror out of beta.
Bug: T191923
Change-Id: Ide794e8f986d3f0455ff282819c71d9144dd75db
Keep all our font rule settings in one place to make it
easier to keep them in sync. Also add a rule for 'hyphens' in
case the browser default has changed.
Bug: T192019
Change-Id: I2c27e5075a9bc6aaed9fe048d163f57976708357
A Node script was used to remove the now unused i18n messages.
This same script sorts the messages alphabetically, so it looks
like some unrelated messages were changed, but they weren't.
Bug: T191297
Change-Id: I69cce06133c1d055d31d12ebc8408123c187b574
Also uses upstream tool-active styling, which was
based on cm-on.svg.
Depends-On: I3e6f65f6f290778d3fbfa22f5d212c26fee12a86
Change-Id: Ib42be9f8b87efe1387eb5c77698fd2f0af0a673d
We can't guarantee the preserve glyph width, e.g.
on Firefox with Chinese characters.
Bug: T184467
Change-Id: I6fc92fcd034bda3d9a94749935aae03c8373f7c5
Deferring the insertions can lead to sync issues, so use
a different technique to selective refresh the CodeMirror
view when the height changes.
This reverts commit 8e3d96f75f.
Bug: T188473
Bug: T185184
Change-Id: I502501cc0325db64f29a67716306733859d102a9
We currently only provide modules for
* wikitext
* css
* javascript
* xml
* htmlmixed
* clike
* php
Change-Id: If47827f61043bd2c474ec160af56f651b3cf3af0
encapsulateSelection is now defined in terms of other methods,
so we don't need to duplicate it here.
Follows on from T185917.
Change-Id: I1f99b3140ed363658ed2724a58c8b34ef20769fa
CM intercepted textSelection() globally but assumed
nobody will ever need to call it for anything but wpTexbox1.
Thus, attempts to get edit summary returned article text.
Lots of things can probably be fixed in this area, but here's
the beginning.
Bug: T177175
Bug: T179287
Depends-On: I113394a473e8fe534f17815676ec7014203db7d6
Change-Id: I72d7d72b2a891a0ad242a565dddc076fa6dd1bd1
This patch changes the comment text color
to #84A0A0, as suggested by Kaldari in T170067.
Bug: T170067
Change-Id: I016b8ce360a06f14b02cee13b629fa578c889347
Not a great solution, but will prevent most of the damage in the
meantime, for example, people losing their edits.
Bug: T178348
Change-Id: I434878a2325df01ad27f590f296738ff1f93320f
.CodeMirror is supposed to magically replace it. Some gadgets'
interface displays incorrectly without it.
Change-Id: I27e2b5b462aa445a13f50dc99af57b4bb0ad3067
It's not fullproof. There's bugs where it forgets a string is misspelled
after re-rendering. But it's better than nothing.
Bug: T95104
Change-Id: I33718a71ff5734912ac59be2cd9575dd662ec2f7
For testing:
__NOTOC__
___NOTOC___
____NOTOC____
_____NOTOC_____
______NO!TOC__NOTOC____
______NO{{TOC}}_____
______NO[[TOC]]_____
______NO'''TOC'''_____
__nOtOc__
FFFFF___NOtoc______
'''____________NOTOC______'''
__TOC___TOC__
__TOC____TOC__
___TOC_____TOC___
__TOC___TOC__
___NOTOC___
____NOTOC____
_____NOTOC_____
______NO!TOC__NOTOC____
______NO{{TOC}}_____
______NO[[TOC]]_____
______NO'''TOC'''_____
__nOtOc__
FFFFF___NOtoc______
{{__TOC__|__TOC__}}
Wrong, but not a big problem:
[[__TOC__|__TOC__]]
Bug: T170041
Change-Id: I0b2cfd02550c2685d241bdf3596507c5972878d5
* Use setTimeout instead of window.setTimeout.
* Directly call function and avoid anonymous function.
Change-Id: Ic396ef744d58fb722761a66f38390d2bb4848c2d
The popup label was being styled as two words from two different
i18n messages, each a different colour. This combines them into
one, moves the identifing class name up to the outer span, and
colours both words blue (the outer braces are left black).
Bug: T174219
Change-Id: Id1166f48ae4b3b8daff29be56dd92ef330dd9cef
This adds the new 'highlighter' symbol to the five CodeMirror SVG
icons, and regenerates their PNG counterparts (using Inkscape).
The only changes to the SVG files apart from the paths (and their
positions) are whitespace formatting. I'm not sure all those
gradients need to be there, but I guess someone did that for a
reason. :-)
Bug: T164441
Change-Id: Ibdb8ecf53eb03fb1d1805e788a3e497e4941263a
* Use OOUI buttons for the actions.
* Make the widget wider to accommodate longer titles in
different languages.
* Don't show if CM already enabled
Change-Id: Ibde461a99929565c15b5e7c5ef3ad88e163fba05
Due to using bold as a highlight style, the VE overlay technique
will only work with monospaced fonts.
Change-Id: I33e3e07cf0f3d8e25dd35623286eedf28ba20ae1
This will be slightly off when you have scrolled past
headers which have a different font size, but it's better
than jumping back to the top of the document.
Change-Id: I62a73c30932c3dc1e538484edead9c5d2ed6c72f
This changes the green for HTML entities to a slightly lighter
shade of green to match the green of HTML tags.
Change-Id: Ice51e96b0f5fac67d88375fe76630098d380afc9
CM surface is just for presentation, it shouldn't
be possible to focus or select anything in the surface,
so in addition to it being beneath the VE surface,
disable it through the CM API and disable pointer-events
with CSS.
Bug: T170170
Change-Id: Ief49c293f514e22bc6db5eebb3a11c1bc695432d
Long-term todo:
* Performance will be poor on large pages due
to using a auto-height textarea which CodeMirror
doesn't optimise.
Change-Id: I16598fcdbeee51e6fae88376ec81f1c8552b383d
This patch makes initialization easier and cheaper.
Since only the PhpTags extension uses the CodeMirrorGetAdditionalResources
hook it was removed. Instead, the CodeMirrorPluginModules and
CodeMirrorTagModes properties are used in extension.json file.
This patch adds ext.CodeMirror.lib.mode.php module for the PhpTags
extension (with dependences). In CodeMirror there are a lot of modes
they will be registered on request (if they will be requered for
extensions).
Examples of integration:
* Cite: I1bf156fa813af4d5f891619f692047bbdb8a1a86
* PhpTags: Ie339f0475e63885e603defaee2cdcccd6a95fafc
Bug: T163238
Change-Id: Idb7a1a5769a1047ef2f7cd25a7152f73a6613225
Since WikiEditor uses wikiEditor-toolbar-doneInitialSections event
we don't need to add it to ResourceLoader dependencies.
Bug: T161475
Change-Id: I7c7c3ba495c0292d2df052145e7930c86fcb48f5
* Move CSS out of mediawiki.css which is for wikitext
highlighting rules.
* Account for wikieditor-ui adding wrappers even when
disabled.
Change-Id: I0fca693a6771ee1d790800c9afd5c7091fda20c1
Before CodeMirror was enabled every time (ignoring user settings)
since switchCodeMirror was called in initialisation and some others bugs...
Change-Id: I418c64000e05dbfac62f5bb2327cfe7ed74efb17
