This helps retrieving the NodeId for any JS Object you pass in.
This allows identifying a particular object when using HeapSnapshot API.
`HeapSnapshot.computeDominatorTree()` returns a tree of object,
but there is no way to identify a given JS object in it.
Getting the node id of a given JS object helps you browse this tree
from a given object you know is leaking.
Differential Revision: https://phabricator.services.mozilla.com/D53971
--HG--
extra : moz-landing-system : lando
The `setCompositionRecording` API on nsIDOMWindowUtils has been broken up into
two new APIs:
* `startCompositionRecording()`, which starts the composition recorder; and
* `stopCompositionRecording(bool writeToDisk)` which stops the composition
recorder and either returns a Promise that resolves to the collected frames
or returns a Promise that resolves when the frames have been written to disk.
The collected frames are serialized over IPC as part of a Shmem as to not
approach the IPC data transfer limit.
Differential Revision: https://phabricator.services.mozilla.com/D47818
--HG--
extra : moz-landing-system : lando
The `setCompositionRecording` API on nsIDOMWindowUtils has been broken up into
two new APIs:
* `startCompositionRecording()`, which starts the composition recorder; and
* `stopCompositionRecording(bool writeToDisk)` which stops the composition
recorder and either returns a Promise that resolves to the collected frames
or returns a Promise that resolves when the frames have been written to disk.
The collected frames are serialized over IPC as part of a Shmem as to not
approach the IPC data transfer limit.
Differential Revision: https://phabricator.services.mozilla.com/D47818
--HG--
extra : moz-landing-system : lando
These methods are only callable from the parent process, so it doesn't make
sense to have the method available driectly on BrowsingContext.
Differential Revision: https://phabricator.services.mozilla.com/D50854
--HG--
extra : moz-landing-system : lando
This patch adds support for including content_scripts CSP in the extensions
manifest, along with all interfaces necessary to access the CSP value. This does not
implement actual use of the CSP for content scripts.
Differential Revision: https://phabricator.services.mozilla.com/D46824
--HG--
extra : moz-landing-system : lando
Dictionaries that we never initialize with JS values don't need a full-featured
Init() method. Instead, we output a cut-down Init() method that doesn't even
take a JSContext and Value as argument, and skips as much work as it can. It
uses constant-false for "is the value present?", but also, to avoid compilation
errors due to use of `cx` and `val` in now-dead conversion code, it tells the
native-to-JS conversion machinery that the value is always missing, which lets
it skip most of the the work it would normally try to do and just output
initialization to the default value. We only need to do this for members that
have default values; the others either remain no-passed or are required members
with no default-initialization behavior.
This saves about 330KB of codesize on Linux64 without PGO and 285KB with PGO.
Differential Revision: https://phabricator.services.mozilla.com/D48007
--HG--
extra : moz-landing-system : lando
This saves about 270KB of codesize on Linux64 without LTO, or 20KB with LTO.
The basic idea is that we can flag dictionaries that need to-JS conversion
(hence ToObjectInternal) based on various IDL uses (return value in normal
interface, argument in callback, etc) and then annotate the ones that are
converted to JS manually in C++ code.
The mozwebidlcodegen changes are needed because non-local changes (e.g. whether
a dictionary is used as a return value somewhere) can now affect the code
generation for a dictionary and hence whether the relevant binding file should
be regenerated. Since these changes can happen in any .webidl file, we need to
check for them. We can't track this via the dependency set on the dictionary
itself, because that would not notice new uses being added.
Differential Revision: https://phabricator.services.mozilla.com/D48006
--HG--
extra : moz-landing-system : lando
This saves about 200KB of codesize on Linux64 without LTO. No effect with LTO,
but is needed for the following patches to work.
Very few dictionaries need these conversions, so explicit opt-in is fine.
Differential Revision: https://phabricator.services.mozilla.com/D48005
--HG--
extra : moz-landing-system : lando
This is where it should have been in the first place. Those attributes belong there.
Differential Revision: https://phabricator.services.mozilla.com/D49577
--HG--
extra : moz-landing-system : lando
The changes to the IDL files were done by running this in dom/webidl:
perl -pi -e 'BEGIN { $/ = undef; } s/\[HTMLConstructor,\n Exposed=Window\]\ninterface ([A-Za-z]+) : HTMLElement \{/[Exposed=Window]\ninterface \1 : HTMLElement {\n [HTMLConstructor] constructor();\n/g' *.webidl
and then fixing any remaining parser failures. That involved hand-editing the
following files:
TestCodeGen.webidl
XULFrameElement.webidl
XULMenuElement.webidl
XULTextElement.webidl
XULTreeElement.webidl
HTMLAudioElement.webidl
HTMLDialogElement.webidl
HTMLElement.webidl
HTMLEmbedElement.webidl
HTMLFormElement.webidl
HTMLImageElement.webidl
HTMLObjectElement.webidl
HTMLOptionElement.webidl
HTMLSlotElement.webidl
HTMLVideoElement.webidl
XULElement.webidl
XULPopupElement.webidl
Differential Revision: https://phabricator.services.mozilla.com/D49349
--HG--
extra : moz-landing-system : lando
This flips the direction in which the BrowserBridge actor is generally created
such that it is generally created in the parent and sent down to a child
process.
This is done by making the decision about what kind of switch to perform in the
parent, and sending messages down to child processes async to orchestrate these
process changes.
Process launching is changed to use an async `MozPromise`-returning API in this
patch, though the actual process launching still occurs synchronously. A future
patch will enable performing async process launching through the
NewOrUsedBrowserProcess mechanism.
I know of at least a few timing issues which exist with the new logic,
especially around the state of the BrowsingContext during the process
transition. I decided to not try to fix all of these issues in this patch, as
many are complex and will require changing how we manage the lifecycle of
BrowsingContext substantially. I do, however, think that the new logic is more
reliable and has fewer timing issues than the previous logic.
Differential Revision: https://phabricator.services.mozilla.com/D47310
--HG--
extra : moz-landing-system : lando
These still fail or timeout because of missing platform features, but at least
the tests will pass once those platform features are fixed after this.
Differential Revision: https://phabricator.services.mozilla.com/D48221
--HG--
extra : moz-landing-system : lando
This flips the direction in which the BrowserBridge actor is generally created
such that it is generally created in the parent and sent down to a child
process.
This is done by making the decision about what kind of switch to perform in the
parent, and sending messages down to child processes async to orchestrate these
process changes.
Process launching is changed to use an async `MozPromise`-returning API in this
patch, though the actual process launching still occurs synchronously. A future
patch will enable performing async process launching through the
NewOrUsedBrowserProcess mechanism.
I know of at least a few timing issues which exist with the new logic,
especially around the state of the BrowsingContext during the process
transition. I decided to not try to fix all of these issues in this patch, as
many are complex and will require changing how we manage the lifecycle of
BrowsingContext substantially. I do, however, think that the new logic is more
reliable and has fewer timing issues than the previous logic.
Differential Revision: https://phabricator.services.mozilla.com/D47310
--HG--
extra : moz-landing-system : lando
This flips the direction in which the BrowserBridge actor is generally created
such that it is generally created in the parent and sent down to a child
process.
This is done by making the decision about what kind of switch to perform in the
parent, and sending messages down to child processes async to orchestrate these
process changes.
Process launching is changed to use an async `MozPromise`-returning API in this
patch, though the actual process launching still occurs synchronously. A future
patch will enable performing async process launching through the
NewOrUsedBrowserProcess mechanism.
I know of at least a few timing issues which exist with the new logic,
especially around the state of the BrowsingContext during the process
transition. I decided to not try to fix all of these issues in this patch, as
many are complex and will require changing how we manage the lifecycle of
BrowsingContext substantially. I do, however, think that the new logic is more
reliable and has fewer timing issues than the previous logic.
Differential Revision: https://phabricator.services.mozilla.com/D47310
--HG--
extra : moz-landing-system : lando
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
The fact that mixins can't include mixins and can't inherit makes the message
manager setup a bit annoying...
Differential Revision: https://phabricator.services.mozilla.com/D46520
--HG--
extra : moz-landing-system : lando
This also allows us to remove TabGroup::FindItemWithName, which is a
big step towards removing TabGroup entirely.
Differential Revision: https://phabricator.services.mozilla.com/D46285
--HG--
extra : moz-landing-system : lando
