In order to be able to reasonably debug error results from things like
JSWindowActor.sendQuery, we need to be able to clone errors across process
boundaries, so that they can be propagated to the caller that initiated a
query. The standard for the structured clone algorithm does not allow cloning
errors directly, so this patch instead adds a chrome-only wrapper object which
supports structured clone writing, and on reading, automatically decodes to
the error object it wraps. Callers who wish to clone an Error or Exception
object simply need to wrap it in a ClonedErrorHolder before sending.
Differential Revision: https://phabricator.services.mozilla.com/D50881
--HG--
extra : moz-landing-system : lando
In order to be able to reasonably debug error results from things like
JSWindowActor.sendQuery, we need to be able to clone errors across process
boundaries, so that they can be propagated to the caller that initiated a
query. The standard for the structured clone algorithm does not allow cloning
errors directly, so this patch instead adds a chrome-only wrapper object which
supports structured clone writing, and on reading, automatically decodes to
the error object it wraps. Callers who wish to clone an Error or Exception
object simply need to wrap it in a ClonedErrorHolder before sending.
Differential Revision: https://phabricator.services.mozilla.com/D50881
--HG--
extra : moz-landing-system : lando
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
Emilio Cobos Álvarez
Kris Maglione
Ciure Andrei
Sean Feng
Razvan Maries
Micah Tigley
Gurzau Raul
Brindusan Cristian
Alexandre Poirot
Gijs Kruitbosch
Barret Rennie
Daniel Varga
Peter Van der Beken
Nika Layzell
Shane Caraveo
Junior Hsu
Andreea Pavel
Andrea Marchesini
Mihai Alexandru Michis
Boris Zbarsky
Edgar Chen
Andreas Farre
Jean-Yves Avenard
Narcis Beleuzu
Matt Woodrow
Brian Hackett
Csoregi Natalia