Created a runtime hook to handle DOM nodes. Specialized ubi::Concrete for nsINode-inheriting objects. Displayed outgoing nsISupports* edges on reflector JSObjects. Generated outgoing child edges from nsINodes by examining their children. Updated the UbiNodeCensus to ignore zone checks if there is no zone to be found in a node.
--HG--
extra : rebase_source : 319dccb3277a39e51a79588eac9c8f2b4ff97c2f
Created a runtime hook to handle DOM nodes. Specialized ubi::Concrete for nsINode-inheriting objects. Displayed outgoing nsISupports* edges on reflector JSObjects. Generated outgoing child edges from nsINodes by examining their children. Updated the UbiNodeCensus to ignore zone checks if there is no zone to be found in a node.
This way we reuse the same machinery everywhere for the content property.
The only difference is that we need to look at the parent style for content
instead of just our style, and at a given index.
Again, this is fine because changing content reframes, so no chance to mess up.
This allows the generated content stuff to not implement nsImageLoadingContent
and all that stuff, nor deal with events, which makes it much simpler IMO.
Now it just tracks an index. We may not even need for it to be an HTML element,
but I've kept that for now.
I added a crashtest that used to crash because of the bogus
nsCSSFrameConstructor code which trusted the node name without checking it was
native anonymous.
Differential Revision: https://phabricator.services.mozilla.com/D1897
MozReview-Commit-ID: 1pAzIvRRVnL
This way we reuse the same machinery everywhere for the content property.
The only difference is that we need to look at the parent style for content
instead of just our style, and at a given index.
Again, this is fine because changing content reframes, so no chance to mess up.
This allows the generated content stuff to not implement nsImageLoadingContent
and all that stuff, nor deal with events, which makes it much simpler IMO.
Now it just tracks an index. We may not even need for it to be an HTML element,
but I've kept that for now.
I added a crashtest that used to crash because of the bogus
nsCSSFrameConstructor code which trusted the node name without checking it was
native anonymous.
Differential Revision: https://phabricator.services.mozilla.com/D1897
MozReview-Commit-ID: 1pAzIvRRVnL
This ChromeUtils API now returns a promise that gets resolved once all the data
has been collected via IPDL and the main process. The existing notification
design and its related XPCOM classes are removed.
MozReview-Commit-ID: CYKukBOC8yh
--HG--
extra : rebase_source : 1e27524726ace0bfed5297d48af8be268c5b4945
This ChromeUtils API now returns a promise that gets resolved once all the data
has been collected via IPDL and the main process. The existing notification
design and its related XPCOM classes are removed.
MozReview-Commit-ID: CYKukBOC8yh
--HG--
extra : rebase_source : 1e27524726ace0bfed5297d48af8be268c5b4945
See the design doc[1] for further info. We would like to redesign
the places observer system to be more performant and more friendly
to consume. WebIDL was recommended as it simplifies creating simple
dictionary payloads while allowing dynamic typing with `any`.
There were some difficulties with WebIDL though, most of which
revolved around allowing consumers to be weakly referenced, from
both C++ and JS. The simplest solution I could come up with was to
create a simple native interface for the C++ case, and a WebIDL
wrapper for a JS callback in the JS case. Suggestions for simpler
alternatives are very welcome though.
[1] https://docs.google.com/document/d/1G45vfd6RXFXwNz7i4FV40lDCU0ao-JX_bZdgJV4tLjk/edit?usp=sharing
MozReview-Commit-ID: ACnAEfa5WxO
--HG--
extra : rebase_source : 0e4d66fb7eab68c14fad10e3c5876bc491452e22
See the design doc[1] for further info. We would like to redesign
the places observer system to be more performant and more friendly
to consume. WebIDL was recommended as it simplifies creating simple
dictionary payloads while allowing dynamic typing with `any`.
There were some difficulties with WebIDL though, most of which
revolved around allowing consumers to be weakly referenced, from
both C++ and JS. The simplest solution I could come up with was to
create a simple native interface for the C++ case, and a WebIDL
wrapper for a JS callback in the JS case. Suggestions for simpler
alternatives are very welcome though.
[1] https://docs.google.com/document/d/1G45vfd6RXFXwNz7i4FV40lDCU0ao-JX_bZdgJV4tLjk/edit?usp=sharing
MozReview-Commit-ID: ACnAEfa5WxO
--HG--
extra : rebase_source : 6b5101e05d2f0588e831c0a7d1239a3dcb65ddcb
See the design doc[1] for further info. We would like to redesign
the places observer system to be more performant and more friendly
to consume. WebIDL was recommended as it simplifies creating simple
dictionary payloads while allowing dynamic typing with `any`.
There were some difficulties with WebIDL though, most of which
revolved around allowing consumers to be weakly referenced, from
both C++ and JS. The simplest solution I could come up with was to
create a simple native interface for the C++ case, and a WebIDL
wrapper for a JS callback in the JS case. Suggestions for simpler
alternatives are very welcome though.
[1] https://docs.google.com/document/d/1G45vfd6RXFXwNz7i4FV40lDCU0ao-JX_bZdgJV4tLjk/edit?usp=sharing
MozReview-Commit-ID: ACnAEfa5WxO
--HG--
extra : rebase_source : cb13b24696ee97b611c318b407ea9c31215df3f6
See the design doc[1] for further info. We would like to redesign
the places observer system to be more performant and more friendly
to consume. WebIDL was recommended as it simplifies creating simple
dictionary payloads while allowing dynamic typing with `any`.
There were some difficulties with WebIDL though, most of which
revolved around allowing consumers to be weakly referenced, from
both C++ and JS. The simplest solution I could come up with was to
create a simple native interface for the C++ case, and a WebIDL
wrapper for a JS callback in the JS case. Suggestions for simpler
alternatives are very welcome though.
[1] https://docs.google.com/document/d/1G45vfd6RXFXwNz7i4FV40lDCU0ao-JX_bZdgJV4tLjk/edit?usp=sharing
MozReview-Commit-ID: ACnAEfa5WxO
--HG--
extra : rebase_source : cb13b24696ee97b611c318b407ea9c31215df3f6
See the design doc[1] for further info. We would like to redesign
the places observer system to be more performant and more friendly
to consume. WebIDL was recommended as it simplifies creating simple
dictionary payloads while allowing dynamic typing with `any`.
There were some difficulties with WebIDL though, most of which
revolved around allowing consumers to be weakly referenced, from
both C++ and JS. The simplest solution I could come up with was to
create a simple native interface for the C++ case, and a WebIDL
wrapper for a JS callback in the JS case. Suggestions for simpler
alternatives are very welcome though.
[1] https://docs.google.com/document/d/1G45vfd6RXFXwNz7i4FV40lDCU0ao-JX_bZdgJV4tLjk/edit?usp=sharing
MozReview-Commit-ID: ACnAEfa5WxO
--HG--
extra : rebase_source : 7e140df5961c5a01c13b1fd2489905f61c83959f
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
In the previous patch, one of the files which was deleted is ShimInterfaceInfo.
This is an implementor of nsIInterfaceInfo which exists for legacy reasons, in
order to allow Components.interfaces.nsIDOM* to have the correct constants and
IIDs associated with them.
As that file was deleted, this information now has to be stored in the typelib.
To do this, the information is moved to the xptshim and xptshimfile attributes
on the relevant xpcom interfaces.
xptshim(...) means that this xpcom interface is a shim for the WebIDL interface
with the specified name.
xptshimfile(...) is for use when the webidl interface is declared in another
interface's .webidl file, (in our case, MessageManager.webidl). It contains the
name of the parent binding, such that we can #include the correct file in our
generated code.
This patch does not add the code which uses these changes, only the parsing
logic.
The change in browser_net_view-source-debugger.js is needed because we now use WebIDL callbacks for MessageListener, and they add async creation stack frames.
--HG--
extra : rebase_source : 0adb349b40a0c51bb3d8f4b9b7d98106a3929cbd
extra : source : a88d94ec010a12c1d829708aaf59a85609478477
Adds the IPDL layer to asynchronously retrieve in the parent process the performance counters.
MozReview-Commit-ID: RbKstNx8pi
--HG--
extra : rebase_source : d7c00f2ef16623dbbd88ede0f6636ca56501e151
Adds the IPDL layer to asynchronously retrieve in the parent process the performance counters.
MozReview-Commit-ID: RbKstNx8pi
--HG--
extra : rebase_source : f81058b9bdd67c2f77bb5cd45d3838bc12f406ea
Adds the IPDL layer to asynchronously retrieve in the parent process the performance counters.
MozReview-Commit-ID: RbKstNx8pi
--HG--
extra : rebase_source : 673bbf79f5e20493eee5e129f6954c574c9c41b6
Jean-Yves Avenard
Masatoshi Kimura
Kristen Wright
Csoregi Natalia
Emilio Cobos Álvarez
shindli
Boris Zbarsky
Bogdan Tara
Tarek Ziadé
Margareta Eliza Balazs
Doug Thayer
Dorel Luca
arthur.iakab
Peter Van der Beken
Ben Kelly
Kris Maglione
Nika Layzell
Adrian Wielgosik
Cosmin Sabou
Noemi Erli