(...modules of unusual size.)
Enabling full syntax highlighting for very long Lua modules can produce DOMs
that have hundreds of thousands of elements and cause browsers to lock up.
I took a count of spans by class (which amounts to a count of tokens by type)
of https://en.wiktionary.org/wiki/Module:languages and came up with:
sy0: 62545 (symbols)
br0: 61952 (brackets)
st0: 39291 (strings)
kw3: 7746 (keywords)
kw1: 3
kw2: 2
co2: 2
co1: 2
nu0: 1
------ ------
Total: 171544
GeSHi allows you to disable highlighting for a particular token type (see
<http://qbnz.com/highlighter/geshi-doc.html#disabling-lexics>) which like a
good way of handling this issue.
Disabling symbols (set_symbols_highlighting(false)) removes both sy0 and br0
elements from the DOM (about 124k elements in the case of Module:languages),
with about 47k elements remaining on the page. This is enough to make Chromium
responsive on my laptop (2.3ghz i5, 8 GB RAM), but it's still noticeably
sluggish. Adding 'set_string_highlighting(false);' removes another 40k elements
from the rendered output, and the resulting DOM is quite zippy at 8k elements.
Proposed solution: disable symbols highlighting when >100 kB; disable strings
highlighting too when >200 kB.
Change-Id: I90c645f9d03bbdc135058a3717a463dec40aa77d
The Geshi rendered output has a font-size of 10px where we would expect
13px just like for <pre>.
Bug 33496 against MediaWiki core dealt with that issue already: in some
(all?) browser 'monospace' has a size of 13px where as the default is
16px. When defining a font-size of 0.8em the monospace is scaled down to
10 px which is too small. By appending another font statement, the
browser treat monospace as a default font and thus scale it starting
with 16px instead of 13px.
This patch append a style to geshi which set the font-family to
"monospace, monospace" thus tricking the browser in considering
monospace a regular font.
Change-Id: I7bbdcc0a21010513473a7ca9d784df77e9920b5b
This can happen if the TitleIsCssOrJsPage hook causes a page without a
.css or .js extension to be considered a CSS/JS page.
Change-Id: I875a7f89f683336f18e70358fe589cef706fd5d1
Remove usage of mw-code-inline:
* That class ended up not being merged into core, so it does nothing.
Only mw-code (for the <pre> wrap) is needed.
7c9b2273c9cbdae90c9f4e3890a13619f769c5d0 (mediawiki/core) had both
in an earlier patch version, but only mw-code was merged.
Follows-up:
* mediawiki/extensions/SyntaxHighlight_GeSHi:
dc147a5ef1
Use .mw-code and .mw-code-inline
* mediawiki/core
7c9b2273c9cbdae90c9f4e3890a13619f769c5d0
Add .mw-code styles in core
Change-Id: I793c05c3e103209cf966d9e35ab37c05528cdbb8
Also make sure mw-content-ltr/rtl is the same as the dir attribute value. Restrict that value to either ltr or rtl (not sure if rtl really needed; source code is always ltr). Also remove text-align:left; as it can/should be set manually in the <source> tag.
Tidy always converts tabs to spaces on input; on a big <pre> section this is ok but it tends to fail on syntax-highlighted output, where the spacing should depend on the *output* not the *input markup*.
As a workaround, when $wgUseTidy is enabled we now apply our own tab-to-space conversion preemptively on the input before feeding it into GeSHi for highlighting; this keeps the right spacing through to output.
* Support for the new GESHI_HEADER_PRE_VALID in geshi 1.0.8
* Strict Standards: Non-static method SyntaxHighlight_GeSHi::validHighlightRange() should not be called statically
* Break input validation out to a function so it doesn't mush up main program flow readability
* Reduce denial of service attack area by imposing an arbitrary limit on the size of line ranges
* Reject 0 as a valid input line
Some further notes:
* Currently, the line numbers given for highlighting seem to ignore the 'start' line number provided for displaying line numbers. This is IMHO a bit confusing; it might be better to add the start line number in so you can specify line numbers which match what will be displayed.
* You can specify line numbers after the end of the document without complaint. It might be better to count the lines and ignore any additional ones.
