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
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
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
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
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
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
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
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
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
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
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
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
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
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
