This attribute can be used to force non-tab extension browsers to be loaded in
the correct BrowsingContextGroup, and also subsumes the existing
sameProcessAsFrameLoader uses in extension code.
Differential Revision: https://phabricator.services.mozilla.com/D85652
This is an alternative approach from D84307, which avoids needing an extra
script runner by avoiding needing to access `nsIBrowser` from
XULFrameElement::LoadSrc.
Differential Revision: https://phabricator.services.mozilla.com/D85446
We have already had these functions on `MediaController` so we just need to expose them on the media controller's webidl interface, and they can be used in testing and the future plan of supporting media hub.
Differential Revision: https://phabricator.services.mozilla.com/D85230
Add an event handler `onactivated/ondeactivated` and a readonly attribute `isActive` on the media control webidl interface, and they can be used in testing and the future plan of supporting media hub.
Differential Revision: https://phabricator.services.mozilla.com/D85229
This is necessary because otherwise callers of policy.readyPromise can
get stuck when an extension fails to start up.
Differential Revision: https://phabricator.services.mozilla.com/D83143
This patch introduces a makeDirectory method to the IOUtils interface, which
allows for creating directories on disk.
Differential Revision: https://phabricator.services.mozilla.com/D83996
This patch introduces a remove method to the IOUtils interface, which allows
for removing files and directories on disk. It is a simple wrapper around
the nsIFile::Remove method.
Differential Revision: https://phabricator.services.mozilla.com/D83663
This patch introduces a remove method to the IOUtils interface, which allows
for removing files and directories on disk. It is a simple wrapper around
the nsIFile::Remove method.
Differential Revision: https://phabricator.services.mozilla.com/D83663
This patch refactors the existing IOUtils::writeAtomic method to add support for the `tmpPath` and `backupFile` options.
Differential Revision: https://phabricator.services.mozilla.com/D82601
This patch introduces a move method to the IOUtils interface, which allows
for renaming/moving files or directories on disk. Source and destination
files may be specified either by an absolute path, or a relative path from
the current working directory.
This method has well-defined behaviour similar to the POSIX mv command
(except that this may create missing directories as necessary).
The behaviour is briefly summarized below:
1. If the source is a file that exists:
a. If the destination is a file that does not exist, the source is
renamed (and re-parented as a child of the destination parent
directory). The destination parent directory will be created if
necessary.
b. If the destination is a file that does exist, the destination is
replaced with the source (unless the noOverwrite option is true).
2. If the source is a directory that exists:
a. If the destination is a directory, then the source directory is
re-parented such that it becomes a child of the destination.
b. If the destination does not exist, then the source is renamed,
creating additional directories if needed.
c. If the destination is a file, then an error occurs.
3. If the source does not exist, an error occurs.
Differential Revision: https://phabricator.services.mozilla.com/D82202
This patch refactors the existing IOUtils::writeAtomic method to add support for the `tmpPath` and `backupFile` options.
Differential Revision: https://phabricator.services.mozilla.com/D82601
This patch introduces a move method to the IOUtils interface, which allows
for renaming/moving files or directories on disk. Source and destination
files may be specified either by an absolute path, or a relative path from
the current working directory.
This method has well-defined behaviour similar to the POSIX mv command
(except that this may create missing directories as necessary).
The behaviour is briefly summarized below:
1. If the source is a file that exists:
a. If the destination is a file that does not exist, the source is
renamed (and re-parented as a child of the destination parent
directory). The destination parent directory will be created if
necessary.
b. If the destination is a file that does exist, the destination is
replaced with the source (unless the noOverwrite option is true).
2. If the source is a directory that exists:
a. If the destination is a directory, then the source directory is
re-parented such that it becomes a child of the destination.
b. If the destination does not exist, then the source is renamed,
creating additional directories if needed.
c. If the destination is a file, then an error occurs.
3. If the source does not exist, an error occurs.
Differential Revision: https://phabricator.services.mozilla.com/D82202
This is similar to JSWindowActor's includeChrome option, and defaults to
'false'. If users want to also instantiate the actor in-process, they can set
this option to 'true'.
Differential Revision: https://phabricator.services.mozilla.com/D82449
CLOSED TREE
Backed out changeset 51d7c644a1e6 (bug 1650163)
Backed out changeset 3d2b6908447a (bug 1650163)
Backed out changeset 79141707d47b (bug 1650163)
- Adds the new about:config pref "extensions.backgroundServiceWorker.enabled" (currently defaults to false).
- Adds the background.service_worker property to the manifest JSON schema definition
- Locks background.service_worker manifest property behind the new preference
- Adds a new BackgroundWorker class to ext-backgroundPage.js (responsible for managing the background
service worker for the extension, e.g. make sure that the expected worker script is registered
as expected when the extension is starting up)
- Adds to the ServiceWorkerManager a new method to allow the WebExtension Framework to register the
background service worker without an existing extension page
- Allows the "moz-extension" schema in the dom/serviceworkers and dom/cache internals
Depends on D63697
Differential Revision: https://phabricator.services.mozilla.com/D60244
This patch introduces a minimal, asynchronous Web IDL interface for
reading/writing whole files in privileged chrome code (main-thread and web
workers). All I/O is performed on a background thread. Pending I/O blocks
Firefox shutdown.
Differential Revision: https://phabricator.services.mozilla.com/D78134
What this patch do are
- add `onpositionstatechange` event handler on MediaController
- `PositionStateEvent` would be sent to `positionstatechange` event handler
The advantage of doing so is
- to allow us to listen to the position change on the media controller interface (that can be used for testing and the future plan, the media hub)
Differential Revision: https://phabricator.services.mozilla.com/D80791
This patch introduces a minimal, asynchronous Web IDL interface for
reading/writing whole files in privileged chrome code (main-thread and web
workers). All I/O is performed on a background thread. Pending I/O blocks
Firefox shutdown.
Differential Revision: https://phabricator.services.mozilla.com/D78134
- Adds the new about:config pref "extensions.backgroundServiceWorker.enabled" (currently defaults to false).
- Adds the background.service_worker property to the manifest JSON schema definition
- Locks background.service_worker manifest property behind the new preference
- Adds a new BackgroundWorker class to ext-backgroundPage.js (responsible for managing the background
service worker for the extension, e.g. make sure that the expected worker script is registered
as expected when the extension is starting up)
- Adds to the ServiceWorkerManager a new method to allow the WebExtension Framework to register the
background service worker without an existing extension page
- Allows the "moz-extension" schema in the dom/serviceworkers and dom/cache internals
Depends on D63697
Differential Revision: https://phabricator.services.mozilla.com/D60244
This switches the `nsIContent{Parent,Child}` interface to be
`nsIDOMProcess{Parent,Child}`, and also implements it on
`InProcess{Parent,Child}`, along with the `ProcessActor` interface.
Differential Revision: https://phabricator.services.mozilla.com/D80582
This switches the `nsIContent{Parent,Child}` interface to be
`nsIDOMProcess{Parent,Child}`, and also implements it on
`InProcess{Parent,Child}`, along with the `ProcessActor` interface.
Differential Revision: https://phabricator.services.mozilla.com/D80582
I think at this point we can remove all of RemoteWebProgressManager, some/all of the TabProgressListener recreations, and probably a bunch more.
Differential Revision: https://phabricator.services.mozilla.com/D79240
I think at this point we can remove all of RemoteWebProgressManager, some/all of the TabProgressListener recreations, and probably a bunch more.
Differential Revision: https://phabricator.services.mozilla.com/D79240
This adds a `browserId` property to all browsing contexts. This ID is the same
for the entire tree of contexts inside a frame element. Each new top-level
context created for a given frame also inherits this ID. This allows identifying
the frame element for a given browsing context.
Originally authored by :mossop in D56245.
Differential Revision: https://phabricator.services.mozilla.com/D77911
This adds a `browserId` property to all browsing contexts. This ID is the same
for the entire tree of contexts inside a frame element. Each new top-level
context created for a given frame also inherits this ID. This allows identifying
the frame element for a given browsing context.
Originally authored by :mossop in D56245.
Differential Revision: https://phabricator.services.mozilla.com/D77911
I think at this point we can remove all of RemoteWebProgressManager, some/all of the TabProgressListener recreations, and probably a bunch more.
Differential Revision: https://phabricator.services.mozilla.com/D79240
This patch will
- remove `MediaControlKeysEvent` and use `MediaControlKey` to replace it
- rename names for all `MediaControlKey` related methods, functions, classes and descriptions
The advantage of doing so are
- remove the duplicated type so that we only need to maintain `MediaControlKey`
Differential Revision: https://phabricator.services.mozilla.com/D78140
This patch will
- create a chrome-only webdil interface `MediaController`
- expose supported keys via `MediaController` webidl interface
The advantage of doing so are
- to have a dedicated interface that is only used for MediaController that can be used for testing and our future plan (media hub)
More Details :
Currently, we access media controller's from `ChromeUtils` [1], but it causes a problem of creating a duplicated enum of the enum which we want to expose into Chrome JS.
Instead, we should create a media controller interface to access all its attibutes, which is more easier and clean.
In addition, we're planning to have a something like Chrome's media hub [2]. In order to do that, we have to expose some JS methods to allow us to control playback directly from Chrome JS.
[1] https://searchfox.org/mozilla-central/rev/559b25eb41c1cbffcb90a34e008b8288312fcd25/dom/chrome-webidl/ChromeUtils.webidl#485-493
[2] https://blog.google/products/chrome/manage-audio-and-video-in-chrome/
Differential Revision: https://phabricator.services.mozilla.com/D77757
Adds a `browserId` property to all browsing contexts which the same for the
entire tree of contexts inside a frame element. If a new top-level context is
created for the frame then it is assigned the same value.
This allows identifying the frame element for a given browsing context.
Currently this is only done for XUL frame elements (browser/iframe). Not sure
if we want this for others.
Differential Revision: https://phabricator.services.mozilla.com/D56245
Adds a `browserId` property to all browsing contexts which the same for the
entire tree of contexts inside a frame element. If a new top-level context is
created for the frame then it is assigned the same value.
This allows identifying the frame element for a given browsing context.
Currently this is only done for XUL frame elements (browser/iframe). Not sure
if we want this for others.
Differential Revision: https://phabricator.services.mozilla.com/D56245
This removes all docshell nsISecureBrowserUI and mixed content properties, and moves them into CanonicalBrowsingContext/WindowGlobalParent. It makes the mixed content blocker just compute the state for the current load, and then send the results to the parent process, where we update the security state accordingly.
I think we could in the future remove onSecurityChange entirely, and instead just fire an event to the <browser> element notifying it of changes to the queryable securityUI.
Unfortunately we have a lot of existing code that depends on specific ordering between onSecurityChange and onLocationChange, so I had to hook into the RemoteWebProgress implementation in BrowserParent to mimic the same timings.
Differential Revision: https://phabricator.services.mozilla.com/D75447
This removes all docshell nsISecureBrowserUI and mixed content properties, and moves them into CanonicalBrowsingContext/WindowGlobalParent. It makes the mixed content blocker just compute the state for the current load, and then send the results to the parent process, where we update the security state accordingly.
I think we could in the future remove onSecurityChange entirely, and instead just fire an event to the <browser> element notifying it of changes to the queryable securityUI.
Unfortunately we have a lot of existing code that depends on specific ordering between onSecurityChange and onLocationChange, so I had to hook into the RemoteWebProgress implementation in BrowserParent to mimic the same timings.
Differential Revision: https://phabricator.services.mozilla.com/D75447
This value is determined in Parent process and passed down to nsDocShell. Delete
the messages to pass the setting down and set it on the BrowsingContext in the
Parent process.
Refactor the code that determines to opt-out of using global history. Code
inspection determines that windowless browsing contexts want to opt-out as well
as any frame with `disableglobalhistory` attribute set on it.
Differential Revision: https://phabricator.services.mozilla.com/D72279
There are various times when it would be useful to get the toplevel or parent
WindowContext from a window or browsing context. While this is already possible,
it's currently somewhat inconvenient.
Differential Revision: https://phabricator.services.mozilla.com/D73500
We need it to live in BrowsingContext instead of WindowContext, because
we need to preserve the zoom level across same-origin navigation.
It'd be nice if it only lived in the top BC, but that's not possible at
the moment because a lot of tests rely on zooming only iframes. Some of
them can be adjusted for scaling the top instead, but not sure it's
worth it's worth fixing them and moving the zoom to be top-only, as it'd
be a bunch of effort, and the complexity and overhead of propagating the
zoom is not so big.
The print-preview-specific code in nsContentViewer is from before we did
the document cloning setup, and it seems useless. I've tested print
preview scaling before and after my patch and both behave the same.
The rest is just various test changes to use the SpecialPowers APIs or
BrowsingContext as needed instead of directly poking at the content
viewer.
I named the pres context hook RecomputeBrowsingContextDependentData, as
more stuff should move there like overrideDPPX and other media emulation
shenanigans.
I also have some ideas to simplify or even remove ZoomChild and such,
but that's followup work.
Differential Revision: https://phabricator.services.mozilla.com/D71969
When I first added this method last year, I added it in JS, handled from within
SessionStore.jsm, as that was the easiest place to do it. Now that
DocumentLoadListener exists, it makes more sense to handle this logic directly
from within that code.
Many parts of the process switch are still handled by frontend JS, such as
selecting remote types, and performing toplevel process switches.
Differential Revision: https://phabricator.services.mozilla.com/D68594
When I first added this method last year, I added it in JS, handled from within
SessionStore.jsm, as that was the easiest place to do it. Now that
DocumentLoadListener exists, it makes more sense to handle this logic directly
from within that code.
Many parts of the process switch are still handled by frontend JS, such as
selecting remote types, and performing toplevel process switches.
Differential Revision: https://phabricator.services.mozilla.com/D68594
This commit:
- removes sendRpcMessage, which was unused;
- removes the CPOW argument to sendAsyncMessage, broadcastAsyncMessage, and
sendSyncMessage;
- removes the aIsSync argument used internally to distinguish sendRpcMessage
and sendSyncMessage;
- removes CPOW tests;
- updates the few remaining callsites that use more than 2 arguments in
sendAsyncMessage for the removal of the cpows argument.
Differential Revision: https://phabricator.services.mozilla.com/D71514
These were added for the sake of app browsers, and all of the code which
actually needed them has since been removed.
Differential Revision: https://phabricator.services.mozilla.com/D70741
These were added for the sake of app browsers, and all of the code which
actually needed them has since been removed.
Differential Revision: https://phabricator.services.mozilla.com/D70741
When I first added this method last year, I added it in JS, handled from within
SessionStore.jsm, as that was the easiest place to do it. Now that
DocumentLoadListener exists, it makes more sense to handle this logic directly
from within that code.
Many parts of the process switch are still handled by frontend JS, such as
selecting remote types, and performing toplevel process switches.
Differential Revision: https://phabricator.services.mozilla.com/D68594
These were added for the sake of app browsers, and all of the code which
actually needed them has since been removed.
Differential Revision: https://phabricator.services.mozilla.com/D70741
When I first added this method last year, I added it in JS, handled from within
SessionStore.jsm, as that was the easiest place to do it. Now that
DocumentLoadListener exists, it makes more sense to handle this logic directly
from within that code.
Many parts of the process switch are still handled by frontend JS, such as
selecting remote types, and performing toplevel process switches.
Differential Revision: https://phabricator.services.mozilla.com/D68594
--HG--
extra : moz-landing-system : lando
When I first added this method last year, I added it in JS, handled from within
SessionStore.jsm, as that was the easiest place to do it. Now that
DocumentLoadListener exists, it makes more sense to handle this logic directly
from within that code.
Many parts of the process switch are still handled by frontend JS, such as
selecting remote types, and performing toplevel process switches.
Differential Revision: https://phabricator.services.mozilla.com/D68594
--HG--
extra : moz-landing-system : lando
Right now, we have a ContentBlockingAllowListPrincipal in the
WindowGlobalParent. So, the browse element can directly get this
principal from there. And we can stop sending the
ContentBlockingAllowListPrincipal from the content to parent when
OnLocationChange happens.
Differential Revision: https://phabricator.services.mozilla.com/D66212
--HG--
extra : moz-landing-system : lando
On X11, there is an universal definition for `None`, and it conflicts with the `None` in the enum of `MediaSessionPlaybackTestState`, which causes a build fail on X11. Also, as the `MediaSessionPlaybackTestState` is defined in the `ChromeUtilsBinding.h`, which is automatically generated by the code gen, we can't include `X11UndefineNone.h` to workaround this problem.
Therefore, we have to change its name to avoid using the same name.
[1] from `/usr/include/X11/X.h:115`
#define None 0L /* universal null resource or null atom */
Differential Revision: https://phabricator.services.mozilla.com/D66445
--HG--
extra : moz-landing-system : lando
Implement a chrome-only method `getCurrentMediaSessionPlaybackState()` to expose current actual playback state in testing.
The reason we create an new enum `MediaSessionPlaybackTestState` is because of building issue. If we use `MediaSessionPlaybackState` directly in the `ChromeUtils.webidl`, then the codegen would automatically add an header include of `MediaSessionBinding.h` in the `ChromeUtilsBinding.h`, which would cause the complier complaining about lots of undeclared identifier.
Differential Revision: https://phabricator.services.mozilla.com/D66344
--HG--
extra : moz-landing-system : lando
Create a chrome-only method to get the current media metadata to know if we correctly update the media metadata or not. That method would only be used for testing.
Differential Revision: https://phabricator.services.mozilla.com/D64849
--HG--
extra : moz-landing-system : lando
It allows us to share the same event name when writing test code like the following:
```
const action = "previoustrack";
mediaSession.setActionHandler(action, () => { ... });
specialPower.generateMediaControlKeyTestEvent(action);
```
Differential Revision: https://phabricator.services.mozilla.com/D60784
--HG--
extra : moz-landing-system : lando
This allows us to access contentBlockingLog in the parent process
through a WindowGlobalParent object.
Differential Revision: https://phabricator.services.mozilla.com/D55779
--HG--
extra : moz-landing-system : lando
This allows us to access contentBlockingEvents in the parent process
through a WindowGlobalParent object.
Differential Revision: https://phabricator.services.mozilla.com/D55621
--HG--
extra : moz-landing-system : lando
Support cancel reason so devtools, download panel, etc. can understand that an extension cancelled a request.
Differential Revision: https://phabricator.services.mozilla.com/D57537
--HG--
extra : moz-landing-system : lando
Now that we have UTF8String in the WebIDL, we can remove quite a few of the
conversions. Do that, and lift the remaining string conversions up as needed.
Also deindent Servo_ComputeColor while touching it.
Most of the remaining copies are because either bug 1606994, or because they're
WebIDL attributes that we still need to serialize back as UTF-16 (bug 1606995).
Differential Revision: https://phabricator.services.mozilla.com/D58687
--HG--
extra : moz-landing-system : lando
We handle media control key events differently from normal key events, and at this point we haven't finished the implementation of capturing media control key events on each platform. Therefore, create a method to generate platform-independent events in order to help testing.
Differential Revision: https://phabricator.services.mozilla.com/D57911
--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
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
Nika Layzell
Csoregi Natalia
David Teller
Coroiu Cristina
alwu
Andreas Farre
Kashav Madan
Keefer Rourke
Jonathan Watt
Narcis Beleuzu
Rob Wu
Sebastian Streich
Tomislav Jovanovic
Bogdan Tara
Mihai Alexandru Michis
Kris Maglione
Luca Greco
Sebastian Hengst
Alexandre Poirot
Butkovits Atila
Matt Woodrow
Gabriel Luong
Cosmin Sabou
manas
Gijs Kruitbosch
Razvan Maries
Dave Townsend
Dorel Luca
Liang-Heng Chen
Randell Jesup
Neil Deakin
Botond Ballo
Andreea Pavel
Emilio Cobos Álvarez
Christoph Kerschbaumer
Dan Glastonbury
Zibi Braniecki
Stefan Hindli
Tom Schuster
Arthur Iakab
Noemi Erli
Ciure Andrei
Daniel Varga
Micah Tigley
Oana Pop Rus
Florian Quèze
Andrew Swan
Peter Van der Beken
Tim Huang
chujun
Siddhant085
Dimi Lee
Shane Caraveo
Thinker Li
Sean Feng
Gurzau Raul
Brindusan Cristian
Barret Rennie
Junior Hsu
Andrea Marchesini
Boris Zbarsky
Edgar Chen
Jean-Yves Avenard