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
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
Sylvestre Ledru
Kris Maglione
Doug Thayer
Dorel Luca
Bogdan Tara
arthur.iakab