wfGetUrlUtils() is also deprecated, but less so, so we can do this first
and then properly replace the individual uses with dependency injection
in local pieces of work.
Also:
* Switching Parser::getExternalLinkRel to UrlUtils::matchesDomainList
exposed a type error in media.txt where $wgNoFollowDomainExceptions
was set to a string (which is invalid) instead of an array.
Bug: T319340
Change-Id: Icb512d7241954ee155b64c57f3782b86acfd9a4c
Soft-deprecated since 1.35 and hard-deprecated since at least
I9776d11d4e2d184 (1.39).
Not set in production.
Change-Id: I68b68ffcdff22daafad34c186d1cc609dcecbf32
Instead of only exposing the ability to send CSP headers, expose
the values of the headers so they can be set via other mechanisms.
Bug: T169027
Change-Id: Ie9f7a29218392e3bc3215ce879ed2a3c48847a7c
The "nonce" CSP feature has been never been properly tested and is not
on track to be enabled at WMF or in MW by default. The use of
nonce-protected eval is not particularly meaningful. It is trivially
bypassed by mw.loader.implement, mw.loader.store, or importScript();
all of which allow any code to be executed directly, or to be stored
and loaded from a first-party origin.
The "nonce" feature is not required for the T208188 roadmap, and with
change I51b8535b2b21a3 there is now also a (small) performance reason
to keep this disabled long-term.
Until and unless there is a plan for enabling this particular aspect
of CSP, we might as well remove it so that we don't waste time our
time building abstraction layers and satisfying dependency injection
through many years for something that might never be used.
Note that this does not remove CSP support from ResourceLoader, and
does not take away from the future of enabling CSP in MediaWiki to
e.g. strictly block third-party scripts, or to require domains to
opt-in by site config or user pref (T208188).
Change-Id: I5a176c41a06a484a11e64bdacdc42b40811fe72e
Profiling in Chromium 115 of a VE request with a mw.loader.store cache
hit shows that the largest domEval() takes 59ms, mostly DOM-related
overhead. Using the Function constructor reduces the time for that call
to 30ms.
Profiling in Firefox 116 shows that it is 41ms either way, there is no
significant DOM overhead.
So, use the Function constructor instead of DOM eval for normal RL
module implementations.
User scripts rely on e.g.
function foo() {}
creating window.foo, which is not the case for the Function constructor.
So for them, continue to use domEval().
The Function constructor propagates exceptions, which is beneficial,
since domEval() was called in a try/catch block. Now the catch should
be reachable.
Change-Id: I51b8535b2b21a3ed62e05c727a06dee09ba0a7b7
