Similarly to nsITabParent, TabChild is exposed to frontend code via nsITabChild. It's not clear what the future of this interface will be, but for now we can just rename it to nsIBrowserChild.
Differential Revision: https://phabricator.services.mozilla.com/D28134
--HG--
rename : dom/interfaces/base/nsITabChild.idl => dom/interfaces/base/nsIBrowserChild.idl
extra : rebase_source : a6c42a661e35b19e46c60f6f6a6f3dab64c0a1bc
extra : histedit_source : 1eb475bd840bf37a3f86294685c9b3c250684e79
Create a new parser (PrototypeDocumentParser) and content sink
(PrototypeDocumentContentSink) that can be used by both XUL and XHTML.
The new parser moves the code from XULDocument that handles creating and
loading a nsXULPrototypeDocument from either the cache or the source
file. Once the parser has finished loading the prototype it notifies the
content sink. The parser is largely a stub and would be better suited
for use as a nsBaseParser, but nsHTMLDocument unfortunately needs an
nsIParser.
The new content sink has the XULDocument code responsible for the
prototype traversal that creates the DOM (XULDocument::ResumeWalk and
friends) and fires off various events.
To unify XUL and XHTML, the XHTML readystate event sequence is used in
XUL. However, the layout path of XHTML loaded from the prototype cache
more closely follows XUL, where frame initializers and layout don't
start until the entire DOM is built.
Differential Revision: https://phabricator.services.mozilla.com/D21236
--HG--
rename : dom/xul/XULDocument.cpp => dom/prototype/PrototypeDocumentContentSink.cpp
rename : parser/moz.build => dom/prototype/moz.build
rename : parser/moz.build => parser/prototype/moz.build
extra : moz-landing-system : lando
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
nsISHEntry.index is readonly, but if you pass `true` as getEntryAtIndex()'s
second argument, nsISHEntry.index will be modified. This is pretty gross.
This patch changes `index` so it's not readonly (because it's not!) and removes
getEntryAtIndex()'s second argument.
--HG--
extra : rebase_source : c519d77fcc1c3bda2f260b5888ce9cd0f6cfdab5
nsSHEntry is the only class that instantiates those two interfaces, so the
separation is not useful. This lets us remove numerous pointless QIs.
--HG--
extra : rebase_source : 570b7ade669fb89a789184198bec9da186c5f1d3
After these patches, these objects will no longer be globals, which would make
their current names misleading. Parts 1a-1c give more appropriate names to the
bindings which will cease to be globals.
MozReview-Commit-ID: L8GolQaHnO5
--HG--
rename : dom/base/ProcessGlobal.cpp => dom/base/ContentProcessMessageManager.cpp
rename : dom/base/ProcessGlobal.h => dom/base/ContentProcessMessageManager.h
extra : rebase_source : c5db43ff4f56bc27c869a8051c8d2c000b3fe287
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.
--HG--
rename : dom/base/ChromeMessageBroadcaster.cpp => dom/base/MessageBroadcaster.cpp
rename : dom/base/ChromeMessageBroadcaster.h => dom/base/MessageBroadcaster.h
rename : dom/base/ChromeMessageBroadcaster.cpp => dom/base/ParentProcessMessageManager.cpp
rename : dom/base/ChromeMessageBroadcaster.h => dom/base/ParentProcessMessageManager.h
rename : dom/base/ChromeMessageSender.cpp => dom/base/ProcessMessageManager.cpp
rename : dom/base/ChromeMessageSender.h => dom/base/ProcessMessageManager.h
extra : rebase_source : c9b0c543f9f367535919a6c6840e5ba038023112
extra : histedit_source : 7749f98e11e25423fcf414cc1f0415104343798a
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
--HG--
rename : xpcom/ds/nsIAtom.h => xpcom/ds/nsAtom.h
extra : rebase_source : ac3e904a21b8b48e74534fff964f1623ee937c67
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
--HG--
extra : rebase_source : f9c2971bf71475202a1a6bbc719ab9ce19f94bc5
Ryan Hunt
Boris Zbarsky
Sylvestre Ledru
Csoregi Natalia
Narcis Beleuzu
Brendan Dahl
Felipe Gomes
Cosmin Sabou
Ehsan Akhgari
Emilio Cobos Álvarez
Nicholas Nethercote
Kris Maglione
Brian Hackett
Peter Van der Beken
Jon Coppeard
Nika Layzell
Sebastian Hengst
Olli Pettay
Andrea Marchesini
Andrew McCreight
Trevor Saunders