Currently, when a page enters BFCache, it updates the parent process
for the active BC; however, the page that is about to show will do the
same. These two operations are triggered in different processes with
different active id, they are racy and problematic.
This patch fixes the above issue by not updating the parent process
when a page enters BFCache.
This only applies to BFCacheInParent is enabled.
Differential Revision: https://phabricator.services.mozilla.com/D215818
I'm sorry. This is a big change to recent stuff, and worst of all is a big commit.
Decisions I made while implementing credential discovery backed me into a corner
where I couldn't have the UI actually get rendered. Particularly around where the
IPCs needed to happen and at what point we called into the main process and when
we returned.
The way it works now is that we do ONE IPC for a credentials.get call, doing most of
the work in the main process and only maybe doing one IPC down to the content process
to tell it to navigate.
This is neater and more secure to a compromised content process. However, a lot happens in
this patch.
Differential Revision: https://phabricator.services.mozilla.com/D215009
I'm sorry. This is a big change to recent stuff, and worst of all is a big commit.
Decisions I made while implementing credential discovery backed me into a corner
where I couldn't have the UI actually get rendered. Particularly around where the
IPCs needed to happen and at what point we called into the main process and when
we returned.
The way it works now is that we do ONE IPC for a credentials.get call, doing most of
the work in the main process and only maybe doing one IPC down to the content process
to tell it to navigate.
This is neater and more secure to a compromised content process. However, a lot happens in
this patch.
Differential Revision: https://phabricator.services.mozilla.com/D215009
I'm sorry. This is a big change to recent stuff, and worst of all is a big commit.
Decisions I made while implementing credential discovery backed me into a corner
where I couldn't have the UI actually get rendered. Particularly around where the
IPCs needed to happen and at what point we called into the main process and when
we returned.
The way it works now is that we do ONE IPC for a credentials.get call, doing most of
the work in the main process and only maybe doing one IPC down to the content process
to tell it to navigate.
This is neater and more secure to a compromised content process. However, a lot happens in
this patch.
Differential Revision: https://phabricator.services.mozilla.com/D215009
I'm sorry. This is a big change to recent stuff, and worst of all is a big commit.
Decisions I made while implementing credential discovery backed me into a corner
where I couldn't have the UI actually get rendered. Particularly around where the
IPCs needed to happen and at what point we called into the main process and when
we returned.
The way it works now is that we do ONE IPC for a credentials.get call, doing most of
the work in the main process and only maybe doing one IPC down to the content process
to tell it to navigate.
This is neater and more secure to a compromised content process. However, a lot happens in
this patch.
Differential Revision: https://phabricator.services.mozilla.com/D215009
I'm sorry. This is a big change to recent stuff, and worst of all is a big commit.
Decisions I made while implementing credential discovery backed me into a corner
where I couldn't have the UI actually get rendered. Particularly around where the
IPCs needed to happen and at what point we called into the main process and when
we returned.
The way it works now is that we do ONE IPC for a credentials.get call, doing most of
the work in the main process and only maybe doing one IPC down to the content process
to tell it to navigate.
This is neater and more secure to a compromised content process. However, a lot happens in
this patch.
Differential Revision: https://phabricator.services.mozilla.com/D215009
NewsSite-Nuxt does a scrollTo(0, 0) which seems to get measured and
seems it might be responsible for bug 1850809.
Chrome doesn't flush at all, and it general it shouldn't be needed. If
there's no scrollframe, the default scroll position is 0,0.
Do the same optimization to ScrollBy(0, 0) and co while at it.
Differential Revision: https://phabricator.services.mozilla.com/D216104
This is the content side state to hold the (guaruanteed singular) pending identity credential request that had to call out
to the main process.
Differential Revision: https://phabricator.services.mozilla.com/D212942
This is the content side state to hold the (guaruanteed singular) pending identity credential request that had to call out
to the main process.
Differential Revision: https://phabricator.services.mozilla.com/D212942
`PresShell::GetRootScrollFrameAsScrollable()` is equivalent to
`PresShell::GetRootScrollContainerFrame()`.
In ScrollContainerFrame.h, `DecideScrollableLayer()` has two versions, one has
four parameters, and the other has five parameters with the fifth parameter
`aDirtyRectHasBeenOverriden` having a default value `nullptr`. When we switch
the caller from `nsIScrollableFrame` to `ScrollContainerFrame`, we need to
remove the default value for the fifth parameter to avoid ambiguity.
Differential Revision: https://phabricator.services.mozilla.com/D211494
`PresShell::GetRootScrollFrameAsScrollable()` is equivalent to
`PresShell::GetRootScrollContainerFrame()`.
In ScrollContainerFrame.h, `DecideScrollableLayer()` has two versions, one has
four parameters, and the other has five parameters with the fifth parameter
`aDirtyRectHasBeenOverriden` having a default value `nullptr`. When we switch
the caller from `nsIScrollableFrame` to `ScrollContainerFrame`, we need to
remove the default value for the fifth parameter to avoid ambiguity.
Differential Revision: https://phabricator.services.mozilla.com/D211494
To collect the gamepad information on the user device, we introduce a
chrome only function called RequestAllGamepads to Navigator. The
function will return a promise which resolves when we get all gamepads
info from the parent process.
Note that we cannot rely on The existing navigator.getGamepads()
function because it cannot allow us collecting gamepads info
without the user interacts with the gamepads.
Differential Revision: https://phabricator.services.mozilla.com/D207979
To collect the gamepad information on the user device, we introduce a
chrome only function called RequestAllGamepads to Navigator. The
function will return a promise which resolves when we get all gamepads
info from the parent process.
Note that we cannot rely on The existing navigator.getGamepads()
function because it cannot allow us collecting gamepads info
without the user interacts with the gamepads.
Differential Revision: https://phabricator.services.mozilla.com/D207979
