In order to delegate the permission to the top-level window, in this
patch, we pre-compute the permissions of the top-level context and set
them to the top-level WindowContext. So, the cross-origin iframe can
know the permission of the top-level window through the WindowContext.
Thus, the permission can be delegated in Fission.
Differential Revision: https://phabricator.services.mozilla.com/D79132
The 'asyncStack' flag on JS execution contexts is used as a general switch
to enable async stack capture across all locations in SpiderMonkey, but
this causes problems because it can at times be too much of a performance
burden to general and track all of these stacks.
Since the introduction of this option, we have only enabled it on Nightly
and DevEdition for non-mobile builds, which has left a lot of users unable
to take advantage of this data while debugging.
This patch enables async stack traces across all of Firefox, but introduces
a new pref to toggle the scope of the actual expensive part of async stacks,
which is _capturing_ them and keeping them alive in memory. The new pref
limits the capturing of async stack traces to only debuggees, unless an
explicit pref is flipped to capture async traces for all cases.
This means that while async stacks are technically enabled, and code could
manually capture a stack and pass it back to SpiderMonkey and see that stack
reflected in later captured stacks, SpiderMonkey itself and related async
DOM APIs, among others, will not capture stacks or pass them to SpiderMonkey,
so there should be no general change in performance by enabling the broader
feature itself, unless the user is actively debugging the page.
One affect of this patch is that if you have the debugger open and then close
it, objects that have async stacks associated with them will retain those
stacks and they will continue to show up in stack traces, no _new_ stacks
will be captured. jorendorff and I have decided that this is okay because
the expectation that the debugger fully revert every possible effect that it
could have on a page is a nice goal but not a strict requirement.
Differential Revision: https://phabricator.services.mozilla.com/D68503
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
- tell the media controll supported action changes when media session updates its action handler
The advantage of doing so are
- to sync the status between media session in content process and the `MediaSessionInfo` in chrome process
Differential Revision: https://phabricator.services.mozilla.com/D77199
This patch will
- `ContentMediaAgent` as the only class to propagate the information to chrome process
The advantage of doing so are
- to group all methods involving IPC in one place, that would be easier to see what information would be propagated to chrome process
Differential Revision: https://phabricator.services.mozilla.com/D77197
This patch will
- make `ContentMediaAgent` inherit from `IMediaInfoUpdater`
- move `MediaPlaybackState` and `MediaAudibleState` to `MediaPlaybackStatus.h`
The advantage of doing so are
- to force all methods which are related with updating information from content process to chrome process to be manged by `IMediaInfoUpdater`. It can help us only put the descriptive comment for methods on one place. (on `IMediaInfoUpdater`)
Differential Revision: https://phabricator.services.mozilla.com/D77196
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 will be useful in DevTools land to discriminate those messages that we
might also get directly by directly connecting to content processes.
Differential Revision: https://phabricator.services.mozilla.com/D76792
This will be useful in DevTools land to discriminate those messages that we
might also get directly by directly connecting to content processes.
Differential Revision: https://phabricator.services.mozilla.com/D76792
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
