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
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
