Before P1, GetCurrentThreadSerialEventTarget would have always returned the same data as NS_GetCurrentThread, making the comment incorrect Now it will properly return the running TaskQueue if any.
This change of name more clearly exposes what they are doing, as we aren't always dealing with threads directly; but a nsISerialEventTarget
Differential Revision: https://phabricator.services.mozilla.com/D80354
We can just use BrowsingContext::BrowserId directly, so it's unnecessary to have
the field on nsFrameLoaderOwner as well.
This also makes it so that we only ever generate browser IDs in
BrowsingContext::CreatedDetached.
Differential Revision: https://phabricator.services.mozilla.com/D80121
The existing comment in BrowserChild::RecvUpdateDimensions may have been
accurate at some point in the past, but I'm seeing cases where setting
the content viewer size itself triggers a reflow. Since the widget size
hasn't been updated yet, the reflow uses some stale values and produces
incorrect outcomes. This patch ensures both the content viewer and widget
get their sizes updated first, and only then do we do the reflow.
Differential Revision: https://phabricator.services.mozilla.com/D79885
Content process won't try to send IPC to parent process to update cursor if the
cursor isn't changed, and assume parent process would update cursor properly as
soon as the cursor re-enter to a remote target.
But BrowserParent cached the cursor information for a remote target only when the
remote target is allowed to update the cursor. It could possible that parent use
a stale cursor for a remote target and stuck in that state untill content
process tries to update cursor again.
Differential Revision: https://phabricator.services.mozilla.com/D79985
CLOSED TREE
Backed out changeset 8c4a24b91c88 (bug 1646088)
Backed out changeset ef746bdcbaf6 (bug 1646088)
Backed out changeset 77d15266af3c (bug 1646088)
The about:home startup cache needs this so that it knows when a content process has transitioned
to the privileged about content process (since, at that point, it then sends the nsIInputStreams
for the cache down to that process).
Differential Revision: https://phabricator.services.mozilla.com/D78908
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
This removes the diagnostic warnings which used to be logged when the
Large-Allocation header was present, but failed to switch into a
Large-Allocation process. Due to the low adoption of the header, this shouldn't
be too large of a problem, but we can look into re-adding the diagnostics if
needed in the future.
The new codepath no longer performs multiple network requests for
Large-Allocation resources, and now relies on the battle-tested
DocumentLoadListener codepath for process switching.
Differential Revision: https://phabricator.services.mozilla.com/D78998
These were only used by process switches triggered via DocumentChannel, which
now take the PROCESS_BEHAVIOR_STANDARD codepath.
Differential Revision: https://phabricator.services.mozilla.com/D78973
This new process switching behavior is only enabled for some browser elements,
which have specified a specific attribute. Turning this on for all browsers with
a `remote` attribute causes breakage in reftests.
The initial version does not handle switching from remote to parent or
vice-versa, that is covered in a later part.
Differential Revision: https://phabricator.services.mozilla.com/D78969
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
There are a number of system parameters that return simple floats and bools
and are just different forms of system parameter query.
This introduces a new singleton and IPDL calls to send these values from parent
to content processes and cache them in content.
I started with these 2 variables because their values don't go stale. In a
later changeset, I will add more logic to invalidate cached values that go
stale, such as for the SPI_GETFLATMENU metric.
Differential Revision: https://phabricator.services.mozilla.com/D76639
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 effect 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 removes the diagnostic warnings which used to be logged when the
Large-Allocation header was present, but failed to switch into a
Large-Allocation process. Due to the low adoption of the header, this shouldn't
be too large of a problem, but we can look into re-adding the diagnostics if
needed in the future.
The new codepath no longer performs multiple network requests for
Large-Allocation resources, and now relies on the battle-tested
DocumentLoadListener codepath for process switching.
Differential Revision: https://phabricator.services.mozilla.com/D78998
These were only used by process switches triggered via DocumentChannel, which
now take the PROCESS_BEHAVIOR_STANDARD codepath.
Differential Revision: https://phabricator.services.mozilla.com/D78973
This new process switching behavior is only enabled for some browser elements,
which have specified a specific attribute. Turning this on for all browsers with
a `remote` attribute causes breakage in reftests.
The initial version does not handle switching from remote to parent or
vice-versa, that is covered in a later part.
Differential Revision: https://phabricator.services.mozilla.com/D78969
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
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
Previously we only set some fields as part of WindowGlobalInit, but WindowGlobalParent sets itself as the current window global on the CanonicalBrowsingContext.
This exposes a period of time where only part of the document state was set, and this was observable to consumers.
This makes OnNewDocument only run when there is a new Document for the same WindowGlobal.
Differential Revision: https://phabricator.services.mozilla.com/D75446
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
Previously we only set some fields as part of WindowGlobalInit, but WindowGlobalParent sets itself as the current window global on the CanonicalBrowsingContext.
This exposes a period of time where only part of the document state was set, and this was observable to consumers.
This makes OnNewDocument only run when there is a new Document for the same WindowGlobal.
Differential Revision: https://phabricator.services.mozilla.com/D75446
This should fix the issue for preallocated processes that still don't
host any document, and also send a few less IPC messages.
Differential Revision: https://phabricator.services.mozilla.com/D76537
Firing eMouseExitFromWidget means we are leaving a specific remote target, then
we should not update sLastMouseRemoteTarget. Otherwise the subsequent event
might trigger sending eMouseExitFromWidget again.
Differential Revision: https://phabricator.services.mozilla.com/D75916
Top-level content WindowGlobalParents now keep track of the site origins of the
documents in their document tree. When the WindowGlobalParent is torn down, the
maximum of the number of unique site origins is submitted for telemetry.
Differential Revision: https://phabricator.services.mozilla.com/D71493
I don't think all this complexity is worth it for having a
marginally-more-realistic testing story. Using the pref just works and we should
do that, I think.
Differential Revision: https://phabricator.services.mozilla.com/D59980
This enables navigating by index in session history go through the
session history in the parent (if enabled with the pref).
If the pref is enabled, then ChildSHistory::Go will send an IPC message
to the parent with the index to navigate to. The parent calls the
existing nsSHistory implementation and starts the loads, and
asynchronously returns the index that we actually navigated to. The
child process then uses that result to update the session history
implementation in the child process (this part is temporary, while we
have session history both in parent and in child). We also make the
parent send an updated length to the child process over IPC, so that
history.length always the length for the implementation in the parent.
Differential Revision: https://phabricator.services.mozilla.com/D65330
This adds a new implementation of nsISHEntry
(mozilla::dom::SessionHistoryEntry). When session history in the parent
is turned on, we'll instantiate the existing nsSHistory in the parent
process, but it will store entries of this new type. The nsSHistory in
the child process will also be instantiated for now, to avoid breaking
too many assumptions, and we try to keep parent and child
implementations in sync.
mozilla::dom::SessionHistoryEntry stores most of its data in a new
structure (mozilla::dom::SessionHistoryInfo) which can be sent over IPC.
When a load starts through the DocumentChannel we create an entry of
this new type for it in the parent process in
DocumentLoadListener::Open. The SessionHistoryInfo for that entry (with
an associated ID) is then sent over IPC in the RedirectToRealChannelArgs
to the process that does the actual load, where we store it in the
nsDocShell in mLoadingEntry (and mLoadingEntryId). The parent process
keeps track of outstanding loading entries in an array (mLoadingEntries)
in the CanonicalBrowsingContext. When a load finishes the nsDocShell
transfers mLoadingEntry into mActiveEntry, and notifies the parent
process through an IPC message (HistoryCommit) with the id of that
entry. The CanonicalBrowsingContext then removes the entry from the
array and stores it in its mActiveEntry, and adds the entry to the
nsSHistory object.
There are a number of things in this patch that are broken, and a lot of
FIXME comments. However, with the pref turned off things should just be
working as before. The goal is to land this first part, and then iterate
on the new implementation until we can switch over.
Differential Revision: https://phabricator.services.mozilla.com/D65329
This patch makes the triggering princpal to be propagated to the
BrowserChild when calling LoadURL in nsFrameLoader. And use it as the
triggering principal for loading instead of the system principal.
Differential Revision: https://phabricator.services.mozilla.com/D75965
We already have an architecture to sync the storage access granted
result to all 3rd-party frames with the same tracking origin.
We use the same way to sync HasStorageAccess flag instead of relying
on permission manager update permissions to child processes.
Differential Revision: https://phabricator.services.mozilla.com/D73711
Before this patch, in non-fission mode, we cache storage access granted result
in the top-level window so we don't have to iterate all the browsing contexts
in the same tree while syncing the storage permission granted decision.
However, since we plan to rely on the current update mechanism to sync
mHasStorageAccess flag for different documents in the same tab (instead of using
the syncing mechanism of permission manager), we will eventually need to iterate
the browsing context tree to find all the documents to sync. Base on this,
we no longer have to maintain different method for fission and non-fission.
In this patch, we store the permission granted result in the inner
window instead of using permission key and store the key in the top-level
window.
Differential Revision: https://phabricator.services.mozilla.com/D73710
We already have an architecture to sync the storage access granted
result to all 3rd-party frames with the same tracking origin.
We use the same way to sync HasStorageAccess flag instead of relying
on permission manager update permissions to child processes.
Differential Revision: https://phabricator.services.mozilla.com/D73711
Before this patch, in non-fission mode, we cache storage access granted result
in the top-level window so we don't have to iterate all the browsing contexts
in the same tree while syncing the storage permission granted decision.
However, since we plan to rely on the current update mechanism to sync
mHasStorageAccess flag for different documents in the same tab (instead of using
the syncing mechanism of permission manager), we will eventually need to iterate
the browsing context tree to find all the documents to sync. Base on this,
we no longer have to maintain different method for fission and non-fission.
In this patch, we store the permission granted result in the inner
window instead of using permission key and store the key in the top-level
window.
Differential Revision: https://phabricator.services.mozilla.com/D73710
The patch also removes the ignoreRootScrollFrame option from
APZCCallbackHelper::DispatchMouseEvent() altogether as it is
no longer used.
Depends on D75735
Differential Revision: https://phabricator.services.mozilla.com/D75736
In this bug we're moving away from monolithic JNI headers to class-specific
headers so that we don't have to rebuild the world every time we make a change
to a JNI interface.
Differential Revision: https://phabricator.services.mozilla.com/D75373
This patch will do :
- make all functions which are used to update information from the content process become a part of `IMediaInfoUpdater`
The advantage of doing so :
- It's clear to use `IMediaInfoUpdater` as the only surface to update the media related status
- explictly restrict which functions are available which can avoid using control related functions on those situations
Differential Revision: https://phabricator.services.mozilla.com/D73489
This patch will do :
- move the logic of determining `actual playback state` to `MediaSessionController`
The advantage of doing so :
- increate the cohesion of `MediaSessionController` because it should be the class to determine the final playback status, not `MediaController`
Differential Revision: https://phabricator.services.mozilla.com/D73488
This patch will do :
- move the instance of `MediaPlaybackStatus` to the `MediaSessionController` to allow `MediaSessionController` handle all media related status
The advantage of doing so :
- encapsulate all media related status details to `MediaSessionController` and simplify the code in `MediaController`
Differential Revision: https://phabricator.services.mozilla.com/D73487
This patch will do :
- make `NotifyMediaPlaybackChanged` and `NotifyMediaAudibleChanged` accept one more paramter that indicates where those update come from
The advantage of doing so :
- we would use that to maintain separated media status for each different context in the future patch.
Differential Revision: https://phabricator.services.mozilla.com/D72471
This enables navigating by index in session history go through the
session history in the parent (if enabled with the pref).
If the pref is enabled, then ChildSHistory::Go will send an IPC message
to the parent with the index to navigate to. The parent calls the
existing nsSHistory implementation and starts the loads, and
asynchronously returns the index that we actually navigated to. The
child process then uses that result to update the session history
implementation in the child process (this part is temporary, while we
have session history both in parent and in child). We also make the
parent send an updated length to the child process over IPC, so that
history.length always the length for the implementation in the parent.
Differential Revision: https://phabricator.services.mozilla.com/D65330
This adds a new implementation of nsISHEntry
(mozilla::dom::SessionHistoryEntry). When session history in the parent
is turned on, we'll instantiate the existing nsSHistory in the parent
process, but it will store entries of this new type. The nsSHistory in
the child process will also be instantiated for now, to avoid breaking
too many assumptions, and we try to keep parent and child
implementations in sync.
mozilla::dom::SessionHistoryEntry stores most of its data in a new
structure (mozilla::dom::SessionHistoryInfo) which can be sent over IPC.
When a load starts through the DocumentChannel we create an entry of
this new type for it in the parent process in
DocumentLoadListener::Open. The SessionHistoryInfo for that entry (with
an associated ID) is then sent over IPC in the RedirectToRealChannelArgs
to the process that does the actual load, where we store it in the
nsDocShell in mLoadingEntry (and mLoadingEntryId). The parent process
keeps track of outstanding loading entries in an array (mLoadingEntries)
in the CanonicalBrowsingContext. When a load finishes the nsDocShell
transfers mLoadingEntry into mActiveEntry, and notifies the parent
process through an IPC message (HistoryCommit) with the id of that
entry. The CanonicalBrowsingContext then removes the entry from the
array and stores it in its mActiveEntry, and adds the entry to the
nsSHistory object.
There are a number of things in this patch that are broken, and a lot of
FIXME comments. However, with the pref turned off things should just be
working as before. The goal is to land this first part, and then iterate
on the new implementation until we can switch over.
Differential Revision: https://phabricator.services.mozilla.com/D65329
If a mouse is over a remote target A, and then moves to remote target B,
we'd deliver the event directly to remote target B after the moving, A would
never get notified that the mouse left. And A would synthesizes mousemove event
on an incorrect point which then generates an unexpected mouseleave.
Differential Revision: https://phabricator.services.mozilla.com/D67408
This patch persists the CrossOriginEmbedderPolicy on the Document and
WindowContext.
The WindowContext's embedder policy is set in
WindowGlobalActor::BaseInitializer by either adopting the policy of the HTTP
channel that loaded the document, or in WindowGlobalChild::OnNewDocument
by inheriting the one from the browsingContext's windowContext.
Differential Revision: https://phabricator.services.mozilla.com/D46903
When a new document is loaded in a WindowContext, various pieces of state need
to be updated in the parent process. This is currently done in an ad-hoc manner
in nsGlobalWindowOuter::SetNewDocument. This change moves the updating logic
into a common method on WindowGlobalChild.
Differential Revision: https://phabricator.services.mozilla.com/D74325
This should make the flow of how data gets into the initial WindowContext state
more clear, and allows the setting of initial synced WindowContext fields.
Differential Revision: https://phabricator.services.mozilla.com/D74324
This is a temporary workaround for the crashes this can cause. A more thorough
fix to discarded ancestor issues will be implemented in bug 1634759.
Differential Revision: https://phabricator.services.mozilla.com/D74101
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
This is an initial step. In the future it may be nice to avoid loading remote
tabs within windows without `useRemoteTabs` in general.
Differential Revision: https://phabricator.services.mozilla.com/D72936
This variant was only used for service workers' openWindow method, which has
been changed to no longer behave in this way, meaning that the type can be
removed. The follow-up simplification of removing
'ContentChild::ProvideWindowCommon', and moving the logic directly into
'BrowserChild' is not done in this bug, and will be done in a follow-up instead.
Differential Revision: https://phabricator.services.mozilla.com/D72935
The 'Id' variant was only used with b2g for remote `mozbrowser`s, and is no
longer relevant. The new code instead uses `PBrowser` directly in all cases.
Differential Revision: https://phabricator.services.mozilla.com/D72933
This variant was only used for service workers' openWindow method, which has
been changed to no longer behave in this way, meaning that the type can be
removed. The follow-up simplification of removing
'ContentChild::ProvideWindowCommon', and moving the logic directly into
'BrowserChild' is not done in this bug, and will be done in a follow-up instead.
Differential Revision: https://phabricator.services.mozilla.com/D72935
The 'Id' variant was only used with b2g for remote `mozbrowser`s, and is no
longer relevant. The new code instead uses `PBrowser` directly in all cases.
Differential Revision: https://phabricator.services.mozilla.com/D72933
This patch will do :
- rename `PlaybackController` to `ContentPlaybackController`
The advantage of doing so :
- explicitly mention this class is only used in the content, to help its readbility
Differential Revision: https://phabricator.services.mozilla.com/D72939
This patch will do :
- rename `MediaActionHandler` to `ContentMediaActionHandler`
The advantage of doing so :
- explicitly mention this class is only used in the content, to help its readbility
Differential Revision: https://phabricator.services.mozilla.com/D72938
This variant was only used for service workers' openWindow method, which has
been changed to no longer behave in this way, meaning that the type can be
removed. The follow-up simplification of removing
'ContentChild::ProvideWindowCommon', and moving the logic directly into
'BrowserChild' is not done in this bug, and will be done in a follow-up instead.
Differential Revision: https://phabricator.services.mozilla.com/D72935
The 'Id' variant was only used with b2g for remote `mozbrowser`s, and is no
longer relevant. The new code instead uses `PBrowser` directly in all cases.
Differential Revision: https://phabricator.services.mozilla.com/D72933
Note that the propagation of the target guid to places where the transform
will be applied is best-effort at the moment. In particular, the
InputAPZContext will result in the correct guid being available in places
that are called synchronously from the Recv*() functions, but not places
called asynhcronously (e.g. via DelayedFireSingleTapEvent).
To mitigate this, places where the transform is applied fall back on the
RCD-RSF if a guid is not available via InputAPZContext (added in a
subsequent patch).
The cases that this gets wrong are fairly edge casey (it requires (a) an
asynchronous codepath, (b) an event targeting a subframe, and (c) that
subframe having a "could not accept the APZ scroll position" transform),
so we just punt on them for now. If it turns out to be important to handle,
then options for doing so include (1) propagating the guid through each of
the affected asynchronous codepaths, or (2) attaching the guid to the event
itself.
Differential Revision: https://phabricator.services.mozilla.com/D68723
The cast in InitWithNode is wrong. AsElement() asserts instead of
checking the flag, so we always pass an element (and if we didn't we'd
have type confusion problems). I audited the callers and we're fine.
Anyhow, always require an element, and add two convenience constructors
for C++ code.
Differential Revision: https://phabricator.services.mozilla.com/D73636
The cast in InitWithNode is wrong. AsElement() asserts instead of
checking the flag, so we always pass an element (and if we didn't we'd
have type confusion problems). I audited the callers and we're fine.
Anyhow, always require an element, and add two convenience constructors
for C++ code.
Differential Revision: https://phabricator.services.mozilla.com/D73636
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 set opener policy from the channel of the new document when creating a
WindowGlobalChild. However, we need to check if it's crossOriginIsolated even
when the WindowGlobalChild hasn't been created for the new inner window in some
cases.
To avoid checking the unset value of opener policy from the BrowsingContext,
this patch moves the setting the opener policy right before creating a native
global for a new inner window. So that the value of opener policy should always
be correct when validating it (IsSharedMemoryAllowed).
Differential Revision: https://phabricator.services.mozilla.com/D71534
Previously the BrowsingContext was also being sent down, despite it being
obvious from the PBrowserBridge actor which the message was sent over.
Differential Revision: https://phabricator.services.mozilla.com/D72929
After the recent simplifications to the zoom code, they only take care
of forwarding the enlarge / decrease zoom messages.
We can do that via PBrowser instead, and get rid of the actors. We can
also remove ZoomChangeUsingMouseWheel. Zooming with the mouse wheel will
end up in a *ZoomChange event anyways, and the only consumer already
listened for them.
Differential Revision: https://phabricator.services.mozilla.com/D73175
Jean-Yves Avenard
Narcis Beleuzu
Chris Fronk
Matt Woodrow
Kashav Madan
Nika Layzell
Kris Maglione
Kartikaya Gupta
Edgar Chen
Gijs Kruitbosch
Mihai Alexandru Michis
Mike Conley
Neil Deakin
Razvan Maries
Nicholas Nethercote
Dave Townsend
Andrea Marchesini
Butkovits Atila
Bogdan Tara
julianwels
Chris Martin
Logan Smyth
Tim Huang
Noemi Erli
Dorel Luca
David Teller
Randell Jesup
Alexis Beingessner
alwu
Simon Giesecke
Christoph Kerschbaumer
nchevobbe
Emilio Cobos Álvarez
Sebastian Streich
Csoregi Natalia
Olli Pettay
Andrew McCreight
Jonathan Kew
Bob Owen
Barret Rennie
Peter Van der Beken
Tom Tung
Dimi Lee
Botond Ballo
Jeff Gilbert
Aaron Klotz
Andreea Pavel
ssengupta
Valentin Gosu
Sylvestre Ledru
Tom Schuster
Henri Sivonen
Dan Glastonbury
Steven MacLeod
Cosmin Sabou
Stefan Hindli