Use subject principal as triggering principal in <video>/<audio> "src"
attribute. We deviate from Mozilla here because we do not worry
about content isolation principals in Page Info.
Use subject principal as triggering principal in <img> "src" attribute.
Also get rid of the `BeforeMaybeChangeAttr`/`AfterMaybeChangeAttr` dance:
It makes more logical sense for these effects to happen _after_ the
attribute has actually been changed.
In order to tailor certain security checks to the caller that is
attempting to load a particular piece of content, we need to be able to
attach an appropriate triggering principal to the corresponding requests.
Since most HTML content is loaded based on attribute values, this means
capturing the subject principal of the caller who sets those attributes,
which in turn means we need to make it available to `AfterSetAttr` hooks
on all relevant element types.
We're currently fairly vague and inconsistent about the values we provide to
content policy implementations for requestOrigin and requestPrincipal. In some
cases they're the triggering principal, sometimes the loading principal,
sometimes the channel principal.
Our existing content policy implementations which require or expect a
loading principal currently retrieve it from the context node.
Since no current callers require the principal to be the loading
principal, and some already expect it to be the triggering principal
(which there's currently no other way to retrieve), a choice was made
to pass the triggering principal whenever possible, but use the loading
principal to determine the origin URL.
Instead, require users to do so. This is a minor translation-unit size
improvement for anyone who never has to use SourceBufferHolder other than
by reference.
Curiously, we should have had this at our fork point (as it was backported
by Mozilla to 52.5.2) by apparently Tobin's import wasn't actually 52.6.0.
:-/
Didn't check that the convenience function existed for this. Throw the
error manually, instead.
TO-DO: Add these convenience functions for one-shot errors.
This is relevant if scripting is terminated due to execution timeout but there are setTimeout/Interval callbacks pending
or if scripting is disabled altogether.
QIing to CC interfaces is a hot path for a few widely-used classes.
Presumably there are many of these objects being created and destroyed.
By making these classes check first for the CC interfaces directly, rather
than going up the inheritance chain, the resulting overhead is reduced.
All DOMProxyHandler::ClearExternalRefsForWrapperRelease now does is clear
a backpointer to the expando, and that's handled during reflector
finalization already, making it redundant.
This is a stub implementation because of the considerable abuse risk and
bad web code risk causing DoS, e.g. when using bad timeout values and
callbacks on the AbortSignal (e.g. recursive).
Considering the abort-ability of these signals otherwise there is never
a guarantee to websites that these signals will be triggered anyway, so
it should be considered an optional signal - meaning we can safely just
ignore the timeout, which allows us to avoid a ton of complexity and
potential sec/privacy issues.
Primary use in the wild seems to be detailed profiling/ad metrics anyway;
we don't really want to encourage that!
