The entries in the parent process stores some data in a shared state for some of
the entries that share a document. We also need to store some of this data in
the info objects in the child process, but it doesn't make sense to have it be
shared: the data shouldn't be mutated in the child process, and we probably only
have one of the info objects anyway. This adds a structure that holds the shared
data for an info object in the child process, but without actually sharing it.
As we use info objects in both parent and child, we hold a void pointer that's a
strong reference to a shared state in the parent process, and an owning pointer
to the pseudo-shared state in the child process.
Differential Revision: https://phabricator.services.mozilla.com/D87038
Checking for an nsISHEntry doesn't work anymore with session history in the
parent. For that we can check that the loading session history info's
mIsLoadFromSessionHistory is true. If there is no loading session history info
we can fall back to the old way of checking for a non-null nsISHEntry (which
will only ever be true if session history in the parent is turned off).
Differential Revision: https://phabricator.services.mozilla.com/D87037
Do this by spinning the event loop until we've done the clone for
preview as appropriate.
This should be much less risky than finishing the previous patches
which would still be nice, but realistically landing them for 81 is not
going to happen.
This just returns without doing nothing in a couple cases, like when
there's already another modal dialog or such. That seems acceptable to
me, it's not clear what better way to do would be.
Differential Revision: https://phabricator.services.mozilla.com/D87484
If we're after shutdown, then this variable will have been cleared.
This is the remaining use that was failing to do a null check, and
it was manifesting as a very low-volume crash.
Differential Revision: https://phabricator.services.mozilla.com/D87503
It has some properties which make it footgunny, especially in the face of
Fission. Callers should use WindowGlobalChild.innerWindowId instead.
Differential Revision: https://phabricator.services.mozilla.com/D82801
There is the same information exposed in DocShellLoadStateInit.
And we don't really need to query user action from BrowsingContext, this
information would be carried in `nsDocShellLoadState`.
Depends on D86724
Differential Revision: https://phabricator.services.mozilla.com/D86773
SessionHistoryEntry::MaybeSynchronizeSharedStateToInfo call is a tad controversial, but
something like that is needed for the cases when the actual value lives in the SHEntrySharedParentState.
Differential Revision: https://phabricator.services.mozilla.com/D86640
SessionHistoryEntry::MaybeSynchronizeSharedStateToInfo call is a tad controversial, but
something like that is needed for the cases when the actual value lives in the SHEntrySharedParentState.
Differential Revision: https://phabricator.services.mozilla.com/D86640
Popup permissions initialized with the result of checking if the
constructing WindowContext's principal is allowed to open a popup. The
field is updated for all WindowContexts sharing a principal whenever
the popup permission for that nsIPrincipal changes.
Differential Revision: https://phabricator.services.mozilla.com/D86378
A new `BrowsingContext` field, `isActiveBrowserWindow`, has been added
to track the active browser window for the `:-moz-window-inactive`
pseudoclass. This field takes the place of
`nsPIDOMWindowOuter::mIsActive`.
With this change `:-moz-window-inactive` is now fission compatible.
Differential Revision: https://phabricator.services.mozilla.com/D86422
We currently start with screen-relative coordinates, translate them to
widget-relative coordinates, and then translate them back to screen-relative
coordinates when actually showing the tooltip in XULBrowserWindow.showTooltip().
There's no reason for the extra conversions, so we can just send screen-relative
coordinates directly.
Since the widget origin for out-of-process frames is the origin of the frame
itself (instead of the tab, which is the case for in-process frames), the
screen-to-widget conversion was incorrect, and was causing a bug in how the
tooltip was being positioned. Avoiding that conversion altogether also fixes
that bug.
Differential Revision: https://phabricator.services.mozilla.com/D86750