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
We were incorrectly not performing an EnsureSubscribed for the origin
process which a BrowsingContext came from. Normally this would mean that
the BrowsingContext could die in the parent process before the
WindowGlobalParent listener arrived, but that didn't generally happen
due to the low likelihood of a CC occuring between the two messages.
It's likely that this crash was caused by people on lower-end hardware
triggering a print. This would be a longer-running operation in the
content process between the first and second message than usual. On
systems with memory pressure, there would be a higher chance of a CC
occuring between the messages, which would then cause this crash.
This patch correctly connects the origin ContentParent to the
BrowsingContextGroup, which will prevent the CC from destroying our
objects.
In the future, it may be desirable to ensure that this doesn't happen
more reliably by using a ContentParent-local table for looking up
BrowsingContext IDs sent over IPC. This would prevent our current
dependency on the weak pointer behaviour of the current global ID cache.
Unfortunately, this patch adds no tests, and I'm not aware of a good way
to test this edge case to confirm it has been fixed. I believe that this
patch should fix the issue I mention, however.
Differential Revision: https://phabricator.services.mozilla.com/D29563
--HG--
extra : moz-landing-system : lando
This patch adds an ID to ensure that we avoid canceling content JS if the next
page already started loading by the time we're ready to try canceling the JS.
Differential Revision: https://phabricator.services.mozilla.com/D25164
--HG--
extra : moz-landing-system : lando
Bug 1487964 changed loadInfo to have a concrete type, so this cast is
no longer needed.
Differential Revision: https://phabricator.services.mozilla.com/D29246
--HG--
extra : moz-landing-system : lando
This makes restoring from bfcache send less messages. It also
separates detach/attach from the caching logic, making it more clear
that caching is going on.
Differential Revision: https://phabricator.services.mozilla.com/D28670
--HG--
extra : moz-landing-system : lando
This test fails intermitently on many test platforms, but mostly on android-em-7-0-x86_64
(geckoview); I'd like to skip it there as I'm trying to get those jobs passing more
reliably.
Differential Revision: https://phabricator.services.mozilla.com/D28748
--HG--
extra : moz-landing-system : lando
Per the discussion in:
https://groups.google.com/d/msg/mozilla.dev.platform/P79pwa9z5m8/iPYPAWPHCAAJ
They should be CamelCase, and that's what most of them already do. This converts
the rest, which are a few.
For the ones that already used `e` or `k` prefixes, I've mostly done:
for file in $(rg Type::e layout | cut -d : -f 1 | sort | uniq); do sed -i 's#Type::e#Type::#g' $file; done
For the ones that used uppercase, I've removed the prefix if it was already in
the type name, and turn them into CamelCase.
Depends on D28680
Differential Revision: https://phabricator.services.mozilla.com/D28681
--HG--
extra : moz-landing-system : lando
This patch moves some `enum` in `nsIPresShell` which are in public scope into
`mozilla` namespace and change them as `enum class`es.
Unfortunately, only "where to scroll" enum is just defines constants of
percentages of scroll destination. Therefore, this patch makes only them
as `static const`.
Differential Revision: https://phabricator.services.mozilla.com/D28606
--HG--
extra : moz-landing-system : lando
Next, we should mark `PresShell::ScrollContentIntoView()` as
`MOZ_CAN_RUN_SCRIPT` because it's used widely.
This patch marks its `PresShell` users, `GoToAnchor()` and `ScrollToAnchor()`,
as `MOZ_CAN_RUN_SCRIPT`. Additionally, this patch moves them from
`nsIPresShell` to `PresShell` because all callers refers `PresShell` directly.
Differential Revision: https://phabricator.services.mozilla.com/D28319
--HG--
extra : moz-landing-system : lando
Similarly to nsITabParent, TabChild is exposed to frontend code via nsITabChild. It's not clear what the future of this interface will be, but for now we can just rename it to nsIBrowserChild.
Differential Revision: https://phabricator.services.mozilla.com/D28134
--HG--
rename : dom/interfaces/base/nsITabChild.idl => dom/interfaces/base/nsIBrowserChild.idl
extra : rebase_source : a6c42a661e35b19e46c60f6f6a6f3dab64c0a1bc
extra : histedit_source : 1eb475bd840bf37a3f86294685c9b3c250684e79
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 patch adds an ID to ensure that we avoid canceling content JS if the next
page already started loading by the time we're ready to try canceling the JS.
Differential Revision: https://phabricator.services.mozilla.com/D25164
--HG--
extra : moz-landing-system : lando
This code builds on top of the E10S "remote tabs" configuration system to add a
system for specifying that remote subframes should be used. Fission can be
enabled for a window by including the "fission" flag in options when opening
the window.
Differential Revision: https://phabricator.services.mozilla.com/D26560
--HG--
extra : moz-landing-system : lando
This is required to support getting the `parent` and `top` properties from
within remote subframes.
Differential Revision: https://phabricator.services.mozilla.com/D26559
--HG--
extra : moz-landing-system : lando
Bogdan Tara
Andrea Marchesini
Barret Rennie
Gurzau Raul
Thomas Nguyen
Nika Layzell
Brindusan Cristian
Noemi Erli
Cosmin Sabou
Mike Conley
Jim Porter
Andreas Farre
Andrew McCreight
Emilio Cobos Álvarez
Geoff Brown
Masayuki Nakano
Brian Grinstead
Christoph Kerschbaumer
Mike de Boer
Ryan Hunt
Coroiu Cristina
Ehsan Akhgari
Dale Harvey