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
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
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
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
This patch changes the comment text color
to #84A0A0, as suggested by Kaldari in T170067.
Bug: T170067
Change-Id: I016b8ce360a06f14b02cee13b629fa578c889347
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
This changes the green for HTML entities to a slightly lighter
shade of green to match the green of HTML tags.
Change-Id: Ice51e96b0f5fac67d88375fe76630098d380afc9
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
* Move CSS out of mediawiki.css which is for wikitext
highlighting rules.
* Account for wikieditor-ui adding wrappers even when
disabled.
Change-Id: I0fca693a6771ee1d790800c9afd5c7091fda20c1
* Fix state toggle in WikiEditor
* Update options API code
* Fix font-size and line-height so text doesn't move
* Append to WikiEditor after loading so it appends in
correct part of DOM.
* Only add border in classic editor
Change-Id: I5e80298030633d4859d01a92b6c61ef1fa969e96
Test jshint and jscs through npm using latest version of jscs and jshint.
Add support for composer.json running phplint and in the future php code
sniffer.
Change-Id: Id8f11f9414fae8313dc18a857a07e11694354dcb
Zopfli is the most efficient DEFLATE compression algorithm, trading run-time
performance for file sizes that are typically 3-8% smaller than those produced
by zlib with the maximum compression setting. Its output is Deflate-compatible,
so no specialized decoder is needed.
This change was created by running zopflipng against all the PNG files in this
repository. The exact invocation was:
git ls-files --exclude-per-directory=.gitignore -- '*.png' \|
parallel zopflipng -m -y --iterations=500 --filters=01234mepb {} {} \;
Files which zopflipng was not able to compress more efficiently were left unmodified.
Bug: T127608
Change-Id: Iec319a37c5884798afa58145a30d496bb1c9d57b
* Cleanup the init process of this extension (PHP & JS setup)
* Make it useable for other extensions like MobileFrontend.
* Call new hook CodeMirrorGetAdditionalResources instead of CodeMirrorGetExtensionMode
Bug: T91796
Change-Id: I9763c40835c2edddafb0dcbacdf53a86f663b8cd
