The call in VRFrameData::LazyCreateMatrix is not needed because
aRetval.set(aArray) ends up calling into Heap::get() which does a read barrier
and exposes.
The call in nsXULPrototypeScript::Compile is not needed because initializing
the AutoJSAPI will guarantee that the global of the Realm it enters, which is
what we're examining here, will be exposed.
The call in Promise's CreateNativeHandlerFunction is not needed because the
object being passed in was always just-created into a stack Rooted.
The call in MIDIMessageEvent::GetData is not needed because it's always working
with a just-created object. Also, mData is a Heap, so there will be a read
barrier anyway before anyone gets at the value.
The call in PrototypeDocumentContentSink::ExecuteScript is not needed because
the AutoEntryScript will guarantee that the global of the Realm it enters is
exposed. And the JSAutoRealm is not needed either, because we're in that Realm
already.
Differential Revision: https://phabricator.services.mozilla.com/D29720
--HG--
extra : moz-landing-system : lando
It just does wasted work. The new setup is also much more similar to the one
used for element states.
Differential Revision: https://phabricator.services.mozilla.com/D27905
--HG--
extra : moz-landing-system : lando
Use the correct global for custom HTML elements created from a prototype.
Also, add an error message to make it easier to spot when the
PrototypeDocumentSink fails.
Differential Revision: https://phabricator.services.mozilla.com/D27401
--HG--
extra : moz-landing-system : lando
HTML script tags were being loaded once by the element when it was bound
to the tree and a second time by the PrototypeDocumentContentSink. This
patch disables the script element from loading itself.
Differential Revision: https://phabricator.services.mozilla.com/D26823
HTML script tags were being loaded once by the element when it was bound
to the tree and a second time by the PrototypeDocumentContentSink. This
patch disables the script element from loading itself.
Depends on D26822
Differential Revision: https://phabricator.services.mozilla.com/D26823
--HG--
extra : moz-landing-system : lando
Check if the current parent element is an HTML template element and if it
is, append to the document fragment instead of it.
Differential Revision: https://phabricator.services.mozilla.com/D26768
--HG--
extra : moz-landing-system : lando
This makes `Document::GetShell()` return `PresShell*` instead of `nsIPresShell`.
Additonally, "shell" is unclear ("docshell" vs. "presshell"). Therefore, this
also renames `Document::GetShell()` to `Document::GetPresShell()`.
Similarly, some other method names of `Document` are also renamed from
`*Shell*` to `*PresShell*`.
Differential Revision: https://phabricator.services.mozilla.com/D25338
--HG--
extra : moz-landing-system : lando
This makes `Document::GetShell()` return `PresShell*` instead of `nsIPresShell`.
Additonally, "shell" is unclear ("docshell" vs. "presshell"). Therefore, this
also renames `Document::GetShell()` to `Document::GetPresShell()`.
Similarly, some other method names of `Document` are also renamed from
`*Shell*` to `*PresShell*`.
Differential Revision: https://phabricator.services.mozilla.com/D25338
--HG--
extra : moz-landing-system : lando
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
Olli Pettay
Zibi Braniecki
Gurzau Raul
Boris Zbarsky
Ehsan Akhgari
Emilio Cobos Álvarez
Brendan Dahl
Coroiu Cristina
Masayuki Nakano
Dorel Luca