Previously the `WebNavigationChild` would keep track of when triggering its
`nsIWebNavigation`, `goForward`, `goBack`, `gotoIndex`, and `loadURI` methods.
It's `nsIWebNavigation` instance is always an `nsIDocShell` and as part of
porting `OnStateChange` and `OnLocationChange` events from
`WebProgressChild`/`RemoteWebProgress` to `BrowserChild`/`BrowserParent`, this
informations needs to be available from the `BrowserChild`. As it stands, it is
currently an expando property on the `WebProgressChild`.
Instead of introducing yet another XPCOM interface for the WebProgressChild, we
now store this information directly on the `nsDocShell`. Furthermore, instead
of having the `WebNavigationChild` manage this part of the `nsDocShell`'s
state, we can have the `nsDocShell` manage this state itself so it is always
consistent.
Differential Revision: https://phabricator.services.mozilla.com/D28124
--HG--
extra : moz-landing-system : lando
Previously the `WebNavigationChild` would keep track of when triggering its
`nsIWebNavigation`, `goForward`, `goBack`, `gotoIndex`, and `loadURI` methods.
It's `nsIWebNavigation` instance is always an `nsIDocShell` and as part of
porting `OnStateChange` and `OnLocationChange` events from
`WebProgressChild`/`RemoteWebProgress` to `BrowserChild`/`BrowserParent`, this
informations needs to be available from the `BrowserChild`. As it stands, it is
currently an expando property on the `WebProgressChild`.
Instead of introducing yet another XPCOM interface for the WebProgressChild, we
now store this information directly on the `nsDocShell`. Furthermore, instead
of having the `WebNavigationChild` manage this part of the `nsDocShell`'s
state, we can have the `nsDocShell` manage this state itself so it is always
consistent.
Differential Revision: https://phabricator.services.mozilla.com/D28124
--HG--
extra : moz-landing-system : lando
If we're doing a process switch due to the cross origin opener policy
being mismatched, we don't want to preserve the browsing context.
Differential Revision: https://phabricator.services.mozilla.com/D26392
If we're doing a process switch due to the cross origin opener policy
being mismatched, we don't want to preserve the browsing context.
Differential Revision: https://phabricator.services.mozilla.com/D26392
This patch introduces a new type of content process, which has a dynamic name.
This type of content process is labeled as `webIsolated=${SITE_ORIGIN}` and is
used within fission-enabled windows.
To enable this, additional information about the fission status of the target
window must be passed into E10SUtils. This was done by updating every call site
manually to pass an extra boolean. A better solution perhaps should be used in
the future.
With this patch enabled, we now perform process switches, but only when
navigating to HTTP URIs. If we navigate to a non-HTTP URI in an iframe with
fission enabled, it will not behave correctly. This must be done in a
follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D29570
--HG--
extra : moz-landing-system : lando
Previously the `WebNavigationChild` would keep track of when triggering its
`nsIWebNavigation`, `goForward`, `goBack`, `gotoIndex`, and `loadURI` methods.
It's `nsIWebNavigation` instance is always an `nsIDocShell` and as part of
porting `OnStateChange` and `OnLocationChange` events from
`WebProgressChild`/`RemoteWebProgress` to `BrowserChild`/`BrowserParent`, this
informations needs to be available from the `BrowserChild`. As it stands, it is
currently an expando property on the `WebProgressChild`.
Instead of introducing yet another XPCOM interface for the WebProgressChild, we
now store this information directly on the `nsDocShell`. Furthermore, instead
of having the `WebNavigationChild` manage this part of the `nsDocShell`'s
state, we can have the `nsDocShell` manage this state itself so it is always
consistent.
Differential Revision: https://phabricator.services.mozilla.com/D28124
--HG--
extra : moz-landing-system : lando
Previously the `WebNavigationChild` would keep track of when triggering its
`nsIWebNavigation`, `goForward`, `goBack`, `gotoIndex`, and `loadURI` methods.
It's `nsIWebNavigation` instance is always an `nsIDocShell` and as part of
porting `OnStateChange` and `OnLocationChange` events from
`WebProgressChild`/`RemoteWebProgress` to `BrowserChild`/`BrowserParent`, this
informations needs to be available from the `BrowserChild`. As it stands, it is
currently an expando property on the `WebProgressChild`.
Instead of introducing yet another XPCOM interface for the WebProgressChild, we
now store this information directly on the `nsDocShell`. Furthermore, instead
of having the `WebNavigationChild` manage this part of the `nsDocShell`'s
state, we can have the `nsDocShell` manage this state itself so it is always
consistent.
Differential Revision: https://phabricator.services.mozilla.com/D28124
--HG--
extra : moz-landing-system : lando
nsITabParent is exposed to frontend code and is generally used as a representation of a remote tab. We could just rename the interface to nsIBrowserParent and worry about it later, but I think it's better to rename the interface to nsIRemoteTab so that we can later work on splitting the interface away from the PBrowser protocol.
Note: Some frontend code refers to a TabParentId. This commit renames this to RemoteTabId. We need to figure out the purpose of TabId with fission.
Differential Revision: https://phabricator.services.mozilla.com/D28132
--HG--
rename : dom/interfaces/base/nsITabParent.idl => dom/interfaces/base/nsIRemoteTab.idl
extra : rebase_source : 9d8a1790a7bb10195ad063644d1a93d63b2afb72
This should make it easier to tell whether a particular window is
fission-enabled as testing with fission enabled improves.
Differential Revision: https://phabricator.services.mozilla.com/D26561
--HG--
extra : moz-landing-system : lando
Moved tab context menu out of browser.dtd to browser.xul except for sendPageToDevice, sendLinkToDevice, moveTabOptions, moveSelectedTabOptions, undoCloseTab. Not sure if tabbrowser.js and tabbrowser.xul are working as intended.
Differential Revision: https://phabricator.services.mozilla.com/D19312
--HG--
extra : moz-landing-system : lando
Replaced instances of callers in both C++ and JS files to query the state from the principal directly.
Differential Revision: https://phabricator.services.mozilla.com/D22532
--HG--
extra : moz-landing-system : lando
Since we now have a method on nsFrameLoaderOwner/MozFrameLoaderOwner
that can update remoteness, we should no longer need to unbind and
rebind browser elements to the tree to change their remoteness
attributes. We can just call the method and have the Frameloaders
rebuilt in the backend.
We're still getting some test breakage in Marionette and browser
chrome with this patch. Putting this behind a pref so the fission
team can still work with it while the tests are being fixed.
Depends on D22790
Differential Revision: https://phabricator.services.mozilla.com/D22791
--HG--
extra : moz-landing-system : lando
Just set the RemoteType in the options object argument, instead of
doubling up the information.
Differential Revision: https://phabricator.services.mozilla.com/D23250
--HG--
extra : moz-landing-system : lando
This centralizes the checks for system shortcuts into ShortcutUtils.jsm, so
they can be checked for in the add-on shortcut assignment UI. It also
introduces a mechanism for skipping the system event handler if it is already
being handled by the shortcuts UI.
Differential Revision: https://phabricator.services.mozilla.com/D17586
--HG--
extra : moz-landing-system : lando
This commit provides a simple fix to reduce the time spent
rendering larger data URLs (such as large screenshots) in
the status panel when the Highlights tab is hovered over.
By limiting the number of characters displayed, this
decreases the time spent in the _showDelayed function.
Differential Revision: https://phabricator.services.mozilla.com/D21593
--HG--
extra : moz-landing-system : lando
If we're opening a private browsing window on startup, we won't run the
session restore code, and thus we won't end up cleaning up the preopened
tabs. This raises the question: are there other scenarios where we won't
run restoreWindow at all? Eyeballing the code I think not, but I'm not
sure.
Depends on D22195
Differential Revision: https://phabricator.services.mozilla.com/D22216
--HG--
extra : moz-landing-system : lando
This commit provides a simple fix to reduce the time spent
rendering larger data URLs (such as large screenshots) in
the status panel when the Highlights tab is hovered over.
By limiting the number of characters displayed, this
decreases the time spent in the _showDelayed function.
Differential Revision: https://phabricator.services.mozilla.com/D21593
--HG--
extra : moz-landing-system : lando
When we open firefox with pinned tabs, we first paint a window with
one tab open, and then that tab gets displaced after the pinned tabs
come in. This aims to ensure that our first paint contains the
pinned tab, so that we don't have tabs moving around after first
paint.
MozReview-Commit-ID: GC1y6NlgLTd
Differential Revision: https://phabricator.services.mozilla.com/D18742
--HG--
extra : moz-landing-system : lando
This also changes the name of 'canceledAuthenticationPromptCounter' to account for the
fact that we no longer count up when the prompt was cancelled, but when it was shown.
Differential Revision: https://phabricator.services.mozilla.com/D21680
--HG--
extra : moz-landing-system : lando
This removes the need to go through the browser-to-tab mapping when discarding
a tab and simplifies the relevant code. Besides being renamed discardBrowser()
was also split so that one can check if a tab can be discarded prior to trying
it.
Differential Revision: https://phabricator.services.mozilla.com/D20475
--HG--
extra : moz-landing-system : lando
