For review purposes, the important changes are in dom/bindings/Configuration.py
and dom/bindings/parser.
The changes to the IDL files were done by running these in dom/webidl
and dom/bindings/test:
perl -pi -e 's/^interface ([A-Za-z0-9_]+)($| [:{])/[Exposed=Window]\ninterface \1\2/' *.webidl
perl -pi -e 'BEGIN { $/ = undef; } s/\[HTMLConstructor\]\n\[Exposed=Window\]/[HTMLConstructor,\n Exposed=Window]/g' *.webidl
perl -pi -e 'BEGIN { $/ = undef; } s/\[NoInterfaceObject\]\n\[Exposed=Window\]/[NoInterfaceObject,\n Exposed=Window]/g' *.webidl
perl -pi -e 'BEGIN { $/ = undef; } s/\[ChromeOnly\]\n\[Exposed=Window\]/[ChromeOnly,\n Exposed=Window]/g' *.webidl
And running this in dom/chrome-webidl:
perl -pi -e 'BEGIN { $/ = undef; } s/\[ChromeOnly\]\ninterface/[ChromeOnly, Exposed=Window]\ninterface/g' *.webidl
and then fixing all the resulting parser failures. I then verified that the
generated code is the same as before this change.
Differential Revision: https://phabricator.services.mozilla.com/D46697
--HG--
extra : moz-landing-system : lando
This patch was generated by my modeline.py script.
MozReview-Commit-ID: EbVjPLwiUAT
Depends on D4159
Differential Revision: https://phabricator.services.mozilla.com/D4161
--HG--
extra : moz-landing-system : lando
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
Boris Zbarsky
Cosmin Sabou
Andrew McCreight
Kris Maglione
Margareta Eliza Balazs