This callback is only used in very limited ways, so just require that the
caller passes in the canonical supports pointer plus the participant.
This probably won't affect performance much.
All DOMProxyHandler::ClearExternalRefsForWrapperRelease now does is clear
a backpointer to the expando, and that's handled during reflector
finalization already, making it redundant.
The nsISupports objects added to the purple buffer are already canonical,
so we can avoid some overhead by not QIing them to
`nsCycleCollectionISupports`.
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!
baseDomain is used as a key for cookies in a hashmap. For cookie
operations to work properly, the baseDomain generation must be reliable.
This is, however, not the case, because the result can change by updates
to the public suffix list (PSL).
Since the stored baseDomain is not reliable, the value must be recomputed
when the database is read. This causes a minor performance hit but is
needed if we want to keep abreast of PSL changes without clobbering the
cookies database.
Resolves#2670
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.
This warning throws off a lot of users reporting issues. It's not even
a proper warning as it's informative at best.
Leave it in for debug builds, but stop spewing these common notices in
release builds.
