We risk a shutdown hang without any clues if a dangling reference somewhere
keeps a SharedThreadPool alive past xpcom-shutdown-threads. This because
xpcom-shutdown-threads waits for all SharedThreadPool to be destroyed before
advancing shutdown further. nsCycleCollector::Shutdown comes after
xpcom-shutdown-threads so it is possible that a reference-cycle unexpectedly
keeps a SharedThreadPool alive and blocks shutdown indefinitely.
This patch attempts to help diagnose future cases like this by printing which
SharedThreadPools we are going to wait for to stderr.
MozReview-Commit-ID: CwTApYUMikA
--HG--
extra : rebase_source : f29d04508cf492c82d65f324d7b1990849a0da13
For now we preserve the current code structure and function signatures to make
review simpler. That's about to get cleaned up.
MozReview-Commit-ID: 4epLHQiEwDV
test_bug609794.html was testing a behavior that the method before the current
method of attaching InstallTrigger to windows depended on. We don't really
need that behavior, which is good, because this change is not producing it.
MozReview-Commit-ID: GPzif89UYYl
The only caller of nsDOMConstructor::nsDOMConstructor is
nsDOMConstructor::Create which has no callers.
Also removes the now-unused nsDOMConstructorSH class.
MozReview-Commit-ID: GgOO8ugXFKb
We only have classinfo left for DOMConstructor and DOMPrototype, both of which
use nsDOMConstructorSH, which overrides PostCreatePrototype.
To avoid -Werror build failures, this changeset also removes static functions
that were only reachable from PostCreatePrototype.
MozReview-Commit-ID: JpJOuMHAAuo
We don't resolve it normally, because nsDOMConstructorSH overrides
PostCreatePrototype to be a no-op, so nsWindowSH::GlobalResolve never actually
defines the relevant property on the window. We also hide it in
nsWindowSH::NameStructEnabled. But in the Xray-to-window case we attempt to
define it. We shouldn't do that.
MozReview-Commit-ID: 3tnMnSQuvuT
The only caller is nsDOMClassInfo::RegisterClassProtos. The only caller of
that is nsDOMClassInfo::Init. In nsDOMClassInfo::Init this is called after we
have done the RegisterClassName call for "DOMConstructor".
Since the only bits of classinfo left are DOMConstructor and DOMPrototype, and
both use nsIDOMDOMConstructor as their interface, we call RegisterClassProto
with "DOMConstructor" as aClassName, find the existing nsGlobalNameStruct, and
return without doing anything. So this entire codepath can be removed.
MozReview-Commit-ID: JfXmIex7tLC
nsFrameLoader is on WebIDL bindings, so those QIs are no-ops anyway, unless the given object is no a frameloader to start with.
MozReview-Commit-ID: IPiW70H5NPc
The change from "docShell" to "mDocShell" for the SetName call in the
OwnerIsMozBrowserFrame case in nsFrameLoader::MaybeCreateDocShell is a
drive-by correctness fix for a bug the rename of "docShell" to "parentDocShell"
caught: setting the name of our _parent_ docshell based on the name attr of our
owner makes no sense.
MozReview-Commit-ID: DwnWt8jTokV
