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!
This should avoid the intermittent crashes that are still being reported
on this issue that end up crashing because of a proxied object that can't
be unwrapped after being passed around.
This removes a lot of the plumbing for having the platform embed itself
through IPC which was required for B2G running the browser as both
shell and browser application.
The logic should be equivalent when frame IDs on aImages are contiguously
increasing from IDs on previously set frames.
There are currently no callers passing empty aImages, but the logic in this
case would now be as described in the documentation of
UpdatePrincipalHandleForFrameID():
> We will notify mElement that aPrincipalHandle has been applied when all
> FrameIDs prior to aFrameID have been flushed out.
