Having greedy .* matchers in these regular expressions is quite scary,
and a possible source of hard to track errors. For example, a string
like "height:8px;left:3ex" will make these regular expressions succeed,
even if they shouldn't. The substring "8px;left;3" will be fetched, and
most probably turned into something unexpected like "8ex" for the
calculations below.
Change-Id: Ia6753a58802fb3f3c5df4d2b35a6d8e616835f20
The overflow-x rule has no effect on inline elements
anyway, as documented in T134281, and it confuses
logic in VE for computing highlights.
Bug: T167438
Change-Id: Ifb9e503386c2e0bb101265310767ca9d00ad0c44
In MathML rendering mode custom javascript is executed
to check if the brower has MathPlayer installed. In addition
it's checked if the browser supports SVG rendering. This
functionality was broken in Wikidata, since the scripts were
loaded as styles and not as JS modules.
Change-Id: I5fd8eafc89e01c6ec10cf0f3b71e885ec3a4399c
Previously, the 'action=purge' parameter could not be
accessed by the math extension, since 'action=purge' caused a reload
of the page, even before the math extension was called. However,
before MediaWiki 1.29.+ additional GET request parameter were
forwarded to the next page and could be evaluated by the math
extension. Thus, an additional parameter 'mathpurge=true' was added
to re-render formulae. However, it seems that this additional GET
parameter is no longer being forwarded.
This change reads the refer header to check if 'action=purge' was
passed. This makes the mathpurge parameter obsolete.
Bug: T74537
Change-Id: Ia09c039de3a7232a28bfdd5a97daf1029e5d7c40
Follows-up 946a18d1, which accidentally added a scripts module
to the styles queue (which is a no-op) and fcdfc316 which removes
it from the repo.
Fixes the following debug warning:
> Unexpected general module "ext.math.scripts" in styles queue.
Bug: T158376
Change-Id: I432e724d5f84887f4aecb56db607d189db12c329
So far, rare render errors caused by blips in the network or the mathoid
service produce a big red warning in the page, and cause a tracking
category to be added. The rendered content along with the error message
is cached normally, which means that temporary errors are persisted
indefinitely.
As a consequence, editors need to periodically perform null edits to
remove temporary render errors from caches. T136812 documents a history
of this.
This patch aims to improve error handling through two changes:
1) Limit caching of rendered content to 10 minutes. As a consequence,
temporary render errors should clear themselves up fairly quickly,
eliminating the need for manual follow-up. The 10 minute timeout was
chose as a compromise between relatively timely cleanup, and limited
load from re-renders after math trouble.
2) Track render errors in a dedicated category. This avoids mixing
syntax errors with temporary render errors, which should make cleanup
efforts a lot simpler.
Bug: T136812
Change-Id: If7537ed9117fb736a09f4396b7d55d774ce9674f
