There is still styling associated with the "scrollbox" element, but eventually those instances can be replaced with simple boxes.
Differential Revision: https://phabricator.services.mozilla.com/D15298
--HG--
extra : rebase_source : 1ff8502e01df16e791c06b9cdcbe38fb2b55ccd7
Let SessionStoreUtils be a WebIDL namespace, rather than a XPCOM service
Differential Revision: https://phabricator.services.mozilla.com/D9776
--HG--
rename : toolkit/components/sessionstore/nsSessionStoreUtils.cpp => toolkit/components/sessionstore/SessionStoreUtils.cpp
extra : moz-landing-system : lando
Let SessionStoreUtils be a WebIDL namespace, rather than a XPCOM service
Differential Revision: https://phabricator.services.mozilla.com/D9776
--HG--
rename : toolkit/components/sessionstore/nsISessionStoreUtils.idl => dom/chrome-webidl/SessionStoreUtils.webidl
rename : toolkit/components/sessionstore/nsSessionStoreUtils.cpp => toolkit/components/sessionstore/SessionStoreUtils.cpp
extra : moz-landing-system : lando
This serves 2 purposes:
1. Provides an object corresponding to an inner window which Chrome JS can hold onto.
2. Provides the object to JS which Chrome JS per-window actors will be attached to.
3. Provides useful information to Chrome JS in the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D9394
This implementation is considerably more memory efficient than the existing JS
implementation. Migrating to it fully saves us about 28K per base content
process.
Differential Revision: https://phabricator.services.mozilla.com/D9887
--HG--
extra : source : a19c6b3e0402d16a77185f82d9fedab83a7ca52e
extra : intermediate-source : 28a19b7290ab288a1cb2cbf6d49f905cecc9682b
This implementation is considerably more memory efficient than the existing JS
implementation. Migrating to it fully saves us about 28K per base content
process.
Differential Revision: https://phabricator.services.mozilla.com/D9887
--HG--
extra : source : a19c6b3e0402d16a77185f82d9fedab83a7ca52e
This implementation is considerably more memory efficient than the existing JS
implementation. Migrating to it fully saves us about 28K per base content
process.
Differential Revision: https://phabricator.services.mozilla.com/D9887
--HG--
extra : rebase_source : f358f1f7097eaa8cd62ae916d048a58489e9f5ff
extra : histedit_source : c44c42de02750d71e23e70fdf22d3c3a40b91d3d
Add the first version of the IPDL-JS API, which allow chrome JS to load IPDL files and use them to communicate accross Content processes.
See IPDLProtocol.h for more information regarding how to use the API.
Differential Revision: https://phabricator.services.mozilla.com/D2116
--HG--
rename : ipc/moz.build => ipc/ipdl_new/moz.build
extra : moz-landing-system : lando
Expose Chrome only WebIDL to interface with BrowsingContext from
script. The API consists of parent, firstChild and nextSibling
attributes for BrowsingContext, and the browsingContext attribute for
Window.
--HG--
extra : rebase_source : 772d25e8b4e5526453545ddb2b1607845f3b65ea
libprio does not currently build with MSVC (since it only supports
C90 as a compiler), this is being worked on upstream at https://github.com/mozilla/libprio/issues/17
As we are almost certainly not going to ship Firefox build with MSVC anymore,
let's disable this to get it working on this Tier-2 platform.
Differential Revision: https://phabricator.services.mozilla.com/D4292
--HG--
extra : moz-landing-system : lando
libprio does not currently build with MSVC (since it only supports
C90 as a compiler), this is being worked on upstream at https://github.com/mozilla/libprio/issues/17
As we are almost certainly not going to ship Firefox build with MSVC anymore,
let's disable this to get it working on this Tier-2 platform.
Differential Revision: https://phabricator.services.mozilla.com/D4292
--HG--
extra : moz-landing-system : lando
This patch adds simple stubs to convert between the nsISimpleEnumerator
iteration protocol and the JS iteration protocol.
Each iterable object is required to have an @@iterator method which returns an
object implementing the iterator protocol. The later objects, by convention,
also have such a method which returns the object itself.
This patch adds both a @@iterator() and entries() methods to
nsISimpleEnumerator. The former returns an iterator which returns plain
nsISupports objects. The latter accepts an IID and queries each element to
that IID before returning it. If any element fails to query, the error is
propagated to the caller.
Differential Revision: https://phabricator.services.mozilla.com/D3727
--HG--
extra : rebase_source : 340eb43a1c5e6d7ae69fa8ee486d66d31d079b14
extra : histedit_source : f3efc6c265851a563968ee410e4626e0540f55c0
This is tracked upstream at https://github.com/mozilla/libprio/issues/15
MozReview-Commit-ID: L5VWKdEitfB
--HG--
extra : rebase_source : c19472a8658c01a2edc69904e36a2c5409af1396
This is the first basic implementation of a shared-memory key-value store for
JS message managers. It has one read-write endpoint in the parent process, and
separate read-only endpoints for each child-process message manager.
Changes to the parent endpoint are broadcast to the children as snapshots.
Each snapshot triggers a "change" event with a list of changed keys.
It currently has the following limitations:
- It only supports basic structured clone data. There's no support for blobs,
input streams, message ports... Blob support will be added in a follow-up
patch.
- Changes are currently only broadcast to child endpoints when flush() is
explicitly called in the parent, or when new child processes are launched.
In a follow-up, this will be changed to automatically flush after changes
when the event loop is idle.
- All set operations clone their inputs synchronously, which means that
there's no trivial way for callers to batch multiple changes to a single key
without some additional effort. It might be useful to add a
delayed-serialization option to the .set() call in a follow-up, for callers
who are sure they know what they're doing.
MozReview-Commit-ID: IM8a3UgejXU
--HG--
extra : rebase_source : 66c92d538a5485349bc789028fdc3a6806bc5d5a
extra : source : 2ebaf5f8c6055b11b11d7ec334d54ee941115d48
This is the first basic implementation of a shared-memory key-value store for
JS message managers. It has one read-write endpoint in the parent process, and
separate read-only endpoints for each child-process message manager.
Changes to the parent endpoint are broadcast to the children as snapshots.
Each snapshot triggers a "change" event with a list of changed keys.
It currently has the following limitations:
- It only supports basic structured clone data. There's no support for blobs,
input streams, message ports... Blob support will be added in a follow-up
patch.
- Changes are currently only broadcast to child endpoints when flush() is
explicitly called in the parent, or when new child processes are launched.
In a follow-up, this will be changed to automatically flush after changes
when the event loop is idle.
- All set operations clone their inputs synchronously, which means that
there's no trivial way for callers to batch multiple changes to a single key
without some additional effort. It might be useful to add a
delayed-serialization option to the .set() call in a follow-up, for callers
who are sure they know what they're doing.
MozReview-Commit-ID: IM8a3UgejXU
--HG--
extra : rebase_source : 8e8b7891ca48e61b2d6ba3c05912064a909d9698
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
John Dai
Dorel Luca
Paolo Amadini
Alphan Chen
Neil Deakin
Cosmin Sabou
Nika Layzell
Kris Maglione
arthur.iakab
Brad Werth
Alexander Surkov
shindli
Tristan Bourvon
Emma Malysz
Andreas Farre
Robert Helmer
Narcis Beleuzu
Tiberius Oros
Gurzau Raul
Margareta Eliza Balazs
Bogdan Tara
Doug Thayer
Sebastian Hengst