Process and non-process managers have different script loader interfaces
(ProcessScriptLoader/GlobalProcessScriptLoader vs FrameScriptLoader). The WebIDL
conversion used the same interface for some process and
non-process managers, but because of the different script loader interfaces they really
should be using separate interfaces.
This is a large patch which tries to switch many of the external consumers of
nsGlobalWindow to instead use the new Inner or Outer variants.
MozReview-Commit-ID: 99648Lm46T5
(Path is actually r=froydnj.)
Bug 1400459 devirtualized nsIAtom so that it is no longer a subclass of
nsISupports. This means that nsAtom is now a better name for it than nsIAtom.
MozReview-Commit-ID: 91U22X2NydP
This code now lives in TimeoutManager. Note that this is a transition
state, the Timeout list management code also needs to be refactored out
later.
In order to simplify the lifetime management of the new class, its
lifetime is equal to the lifetime of its containing nsGlobalWindow. In
a few places where we need to dispatch runnables to do asynchronous work
on this object, we hold the containing window alive to guarantee safety.
This patch also removes a bit of dead code that was left over from the
code removed in bug 1281793. See:
https://hg.mozilla.org/mozilla-central/rev/0ac748f4d677#l1.63
The immediate reason we need to change this is that bug 1299911
proposes adding a verifier to check that there are no black-gray edges
in the JS heap, and sGeneration being 0 causes that to fail, due to
mozilla::dom::TraceBlackJS(). If something is a black root, I believe
the verifier requires that it be marked black. This makes sense,
because a black root is something that is definitely alive, and if the
object is marked gray, the CC might free it, as far as the GC knows.
This fails because when the browser starts, it GCs and marks the stuff
at the bottom of TraceBlackJS grey. Then it runs the CC, which flips
sGeneration to 1. Now, the verifier runs (before the GC runs!), and it
sees that the stuff in TraceBlackJS claims to be black, but is grey,
causing a verification failure.
In this particular case the code is actually safe. The purpose of the
black-gray invariant is to ensure that the CC does not incorrectly
unlink any gray C++ objects that are reachable from black JS
roots. The JS objects in TraceBlackJS should all be reachable directly
from a C++ object, and the CC knows that those C++ objects are alive
(because of refcounting). Therefore, the CC will not unlink any
objects that are reachable from black JS roots.
MozReview-Commit-ID: 8PrRkjqWBL
