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
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
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
Currently, with Fission enabled we are not able to create a proper LoadInfo
object when doing a subdocument load because we do not have access to a loading
context if the load is happening inside of an OOP frame. To solve this problem,
we can create LoadInfo object from scratch in the parent process where we have
all of the required information.
Differential Revision: https://phabricator.services.mozilla.com/D68893
Currently, with Fission enabled we are not able to create a proper LoadInfo
object when doing a subdocument load because we do not have access to a loading
context if the load is happening inside of an OOP frame. To solve this problem,
we can create LoadInfo object from scratch in the parent process where we have
all of the required information.
Differential Revision: https://phabricator.services.mozilla.com/D68893
Previously, the PWindowGlobal actor was managed by the PBrowser which hosted it,
however this could cause issues when the tab containing the PWindowGlobal was
being destroyed. Due to the slightly different lifecycles of the PBrowser actor
and the nsGlobalWindowInner which the PWindowGlobal was trying to match the
lifetime of, the actor would sometimes not fire 'willDestroy' events correctly.
This patch moves PWindowGlobal to be directly managed by PContent, and changes
logic which previously used `Manager()` to get `Browser{Parent,Child}` to
instead use a pointer member.
Differential Revision: https://phabricator.services.mozilla.com/D68596
Previously, the PWindowGlobal actor was managed by the PBrowser which hosted it,
however this could cause issues when the tab containing the PWindowGlobal was
being destroyed. Due to the slightly different lifecycles of the PBrowser actor
and the nsGlobalWindowInner which the PWindowGlobal was trying to match the
lifetime of, the actor would sometimes not fire 'willDestroy' events correctly.
This patch moves PWindowGlobal to be directly managed by PContent, and changes
logic which previously used `Manager()` to get `Browser{Parent,Child}` to
instead use a pointer member.
Differential Revision: https://phabricator.services.mozilla.com/D68596
