When the docshell is being destroyed, HttpChannelChild::CompleteRedirectSetup is not called and HttpChannelChild::mListener is not also assigned. In this case, I think we should cancel the channel and propagate the error to the http channel parent.
Differential Revision: https://phabricator.services.mozilla.com/D41515
--HG--
extra : moz-landing-system : lando
If we don't update the resultPrincipalURI, then things that examine it
(e.g. Location APIs and the URL bar) will show the wrong (pre-replaceState) URL.
I believe there is no effective difference between setting the result principal
URI to null and setting it to aNewURI here: the ultimate consumer of it is
NS_GetFinalChannelURI, which will fall back to the originalURI if it's null, and
in this case the originalURI is aNewURI.
Differential Revision: https://phabricator.services.mozilla.com/D41788
--HG--
extra : moz-landing-system : lando
The main part of the change is the change to ChildSHistory - make it possible to have Go() to be called asynchronously
and also let one to cancel pending history navigations. History object (window.history) can then use either the sync or
async Go(), depending on the dom.window.history.async pref.
LoadDelegate, which is used by GeckoView, needs special handling, since
it spins event loop nestedly. With session history loads and same-document loads we can just
bypass it.
To deal with same-document case, MaybeHandleSameDocumentNavigation is split to IsSameDocumentNavigation,
which collects relevant information about the request and returns true if same-document navigation should happen,
and then later HandleSameDocumentNavigation uses that information to trigger the navigation.
SameDocumentNavigationState is used to pass the information around.
referrer-policy-test-case.sub.js is buggy causing tests to pass only on Firefox with sync history API.
nested-context-navigations-iframe.html.ini is added because of https://bugzilla.mozilla.org/show_bug.cgi?id=1572932
Differential Revision: https://phabricator.services.mozilla.com/D41199
--HG--
extra : moz-landing-system : lando
This patch cleans up remote outer window proxies when we navigate back
into the process.
It adds a flag to mDanglingRemoteOuterProxies that is set in between
BrowsingContext::SetDocShell(), where we can tell that the browsing
context is going from being remote to being local, to
nsGlobalWindowOuter::SetNewDocument(), where the local outer window
proxy is actually created. Once the outer window is created, the
remote window proxies can be cleaned up in
CleanUpDanglingRemoteOuterWindowProxies().
The clean up is done by a process that is similar to object
transplanting, except that instead of looking in the cross-compartment
wrapper table for each compartment to find objects to be turned into
CCWs to the new object, it looks in the remote proxy map for each
compartment. SpiderMonkey doesn't know about the proxy maps, so this
has to be done by a new callback object CompartmentTransplantCallback.
Now that this cleanup is being done, it shouldn't be possible to wrap
a remote outer window proxy when the browsing context is local, so
MaybeWrapWindowProxy() can be simplified. I had to drop the assert
here that the browsing context has a window proxy because during clean
up we call wrap on a local outer window proxy before the BC gets the
window proxy set on it. I had the assert because my original plan was
to implicitly fix remote proxies during wrapping, but that is no
longer necessary.
Differential Revision: https://phabricator.services.mozilla.com/D38343
--HG--
extra : moz-landing-system : lando
The main part of the change is the change to ChildSHistory - make it possible to have Go() to be called asynchronously
and also let one to cancel pending history navigations. History object (window.history) can then use either the sync or
async Go(), depending on the dom.window.history.async pref.
LoadDelegate, which is used by GeckoView, needs special handling, since
it spins event loop nestedly. With session history loads and same-document loads we can just
bypass it.
To deal with same-document case, MaybeHandleSameDocumentNavigation is split to IsSameDocumentNavigation,
which collects relevant information about the request and returns true if same-document navigation should happen,
and then later HandleSameDocumentNavigation uses that information to trigger the navigation.
SameDocumentNavigationState is used to pass the information around.
referrer-policy-test-case.sub.js is buggy causing tests to pass only on Firefox with sync history API.
nested-context-navigations-iframe.html.ini is added because of https://bugzilla.mozilla.org/show_bug.cgi?id=1572932
Differential Revision: https://phabricator.services.mozilla.com/D41199
--HG--
extra : moz-landing-system : lando
This patch implements how to use MediaController to control corresponding media in content processes.
Differential Revision: https://phabricator.services.mozilla.com/D38145
--HG--
extra : moz-landing-system : lando
I believe it's the right thing to do.
COEP inherits opener's COEP and is overwritten if COEP by response is stricter.
i.e., we no more need the inherited one.
Differential Revision: https://phabricator.services.mozilla.com/D40143
--HG--
extra : moz-landing-system : lando
(a) Substitute Cross-Origin header with COEP
(b) Forcing cors in FetchDriver is removed since COEP doesn't need to IIUC
Differential Revision: https://phabricator.services.mozilla.com/D38788
--HG--
extra : moz-landing-system : lando
This also renames the existing infallible nsDocShell:GetBrowsingContext()
getter to BrowsingContextRef(), and changes the return type, since several
callers rely on it returning a raw pointer rather than an already_AddRefed.
Differential Revision: https://phabricator.services.mozilla.com/D40312
--HG--
extra : moz-landing-system : lando
Currently, TabGroups know to break their reference cycles only when the last
window leaves them. For TabGroups which have never had a window join (which
happens under Fission), this means they also never see a window leave, and
therefore never break their reference cycles, and leak.
This patch adds a check to break reference cycles if no windows have joined by
the time a BrowserChild they belong to is destroyed.
MANUAL PUSH: Lando fails to rebase.
Differential Revision: https://phabricator.services.mozilla.com/D40669
--HG--
extra : source : 03acb28ab60fb77fa06064385a62cc46cf4ad1bd
extra : amend_source : 0a71625d99951bebe45ee6f62570de491a714e97
This patch implements how to use MediaController to control corresponding media in content processes.
Differential Revision: https://phabricator.services.mozilla.com/D38145
--HG--
extra : moz-landing-system : lando
This is the first step in making it possible to return remote WindowProxy
objects from window.open() and related APIs.
This patch also incidentally fixes a bug where getContentWindowOrOpenURI
returned the top-level browser window rather than the new content window when
passed OPEN_NEWWINDOW for the `aWhere` parameter. This was not the expected
behavior, and was a potentially major footgun for any new users who expected
to always get the content window for the URL they were loading, rather than
sometimes getting a chrome browser window instead.
For now, that case just returns null, which is only a minor footgun, rather
than the major one we had before.
Differential Revision: https://phabricator.services.mozilla.com/D35688
--HG--
extra : moz-landing-system : lando
This change is necessary in order to support named targeting of remote
BrowsingContexts, since the current arrangement only supports in-process
contexts. It also considerably simplifies the logic, since named targetting is
now restricted to the same TabGroup/BrowsingContextGroup, which in and of
itself guarantees that origin attributes will always match in the cases that
we care about.
Differential Revision: https://phabricator.services.mozilla.com/D39991
--HG--
extra : rebase_source : 77795886ef762bd778ddd782608ffca294b7aee0
This functionality is currently unused, and blocks work needed to support
Fission.
Differential Revision: https://phabricator.services.mozilla.com/D39542
--HG--
extra : rebase_source : 1d8fdea73d48c714112d13844f5110f7f1892dda
Ensure that IsFormSubmission is set in all constructors and can be serialized
Differential Revision: https://phabricator.services.mozilla.com/D39935
--HG--
extra : moz-landing-system : lando
For some reason, these timeouts aren't reported as timeouts on automation. The
tests just fail after sitting for 5 minutes doing nothing. Locally, though,
they are reported as timeouts.
Either way, they make the test group run 15 minutes longer than necessary.
Differential Revision: https://phabricator.services.mozilla.com/D39930
--HG--
extra : moz-landing-system : lando
Some failures crept in and out after my last sets of annotations landed. This
patch updates most of the annotations to deal with them.
MANUAL PUSH: Lando won't let me land.
Differential Revision: https://phabricator.services.mozilla.com/D39462
--HG--
extra : rebase_source : 4cfccf95c5bb2521533a9f5c4c25d67f414fb6f5
extra : histedit_source : c19187a3b3002e0eebdd809738b57641e1e432cd
This requires replacing inclusions of it with inclusions of more specific prefs
files.
The exception is that StaticPrefsAll.h, which is equivalent to StaticPrefs.h,
and is used in `Codegen.py` because doing something smarter is tricky and
suitable for a follow-up. As a result, any change to StaticPrefList.yaml will
still trigger recompilation of all the generated DOM bindings files, but that's
still a big improvement over trigger recompilation of every file that uses
static prefs.
Most of the changes in this commit are very boring. The only changes that are
not boring are modules/libpref/*, Codegen.py, and ServoBindings.toml.
Differential Revision: https://phabricator.services.mozilla.com/D39138
--HG--
extra : moz-landing-system : lando
When a BrowsingContext changes from being local to remote, we have to
change all window proxies from being local to remote, using
transplanting. The actual window proxy becomes a remote window
proxy. Cross compartment wrappers (CCWs) to the window proxy also
become remote window proxies in their respective compartments, rather
than CCWs to a remote proxy in the old compartment of the window
proxy, because the window is no longer actually in that
compartment. This also avoids having to figure out what Xray behavior
for remote window proxies should be.
This patch uses the transplanting support I added to
GetRemoteOuterWindowProxy() in the previous patch to ensure that the
remote proxy map holds the correct value after transplanting finishes.
It drops the requirement that both arguments to JS_TransplantObject
have the same class, because we need to transplant a window proxy with
a remote window proxy. It also deals with this by not adding origobj
to the wrapper map unless it is a CCW, to handle transplanting to a
remote proxy.
The core design here, with the remote window proxies in every
compartment, is taken from a patch by peterv.
Differential Revision: https://phabricator.services.mozilla.com/D35730
--HG--
extra : moz-landing-system : lando
When we call GetRemoteOuterWindowProxy in the middle of a transplant,
the remote proxy that the function returns will be almost immediately
swapped with some other object. Rather than trying to fix up the
remote proxy map when that happens, this patch adds a new argument
that is a pointer to the object, if any, that the remote proxy is
going to be swapped to. This will be used in the remote proxy map.
Having a value in the remote proxy map that is not a remote proxy
could cause issues if somebody ends up calling
GetRemoteOuterWindowProxy() a second time before the transplant has
finished. To avoid that, my patch asserts that we are returning an
object with the appropriate class.
Differential Revision: https://phabricator.services.mozilla.com/D37598
--HG--
extra : moz-landing-system : lando
When a BrowsingContext changes from being local to remote, we have to
change all window proxies from being local to remote, using
transplanting. The actual window proxy becomes a remote window
proxy. Cross compartment wrappers (CCWs) to the window proxy also
become remote window proxies in their respective compartments, rather
than CCWs to a remote proxy in the old compartment of the window
proxy, because the window is no longer actually in that
compartment. This also avoids having to figure out what Xray behavior
for remote window proxies should be.
This patch uses the transplanting support I added to
GetRemoteOuterWindowProxy() in the previous patch to ensure that the
remote proxy map holds the correct value after transplanting finishes.
It drops the requirement that both arguments to JS_TransplantObject
have the same class, because we need to transplant a window proxy with
a remote window proxy. It also deals with this by not adding origobj
to the wrapper map unless it is a CCW, to handle transplanting to a
remote proxy.
The core design here, with the remote window proxies in every
compartment, is taken from a patch by peterv.
Differential Revision: https://phabricator.services.mozilla.com/D35730
--HG--
extra : moz-landing-system : lando
When we call GetRemoteOuterWindowProxy in the middle of a transplant,
the remote proxy that the function returns will be almost immediately
swapped with some other object. Rather than trying to fix up the
remote proxy map when that happens, this patch adds a new argument
that is a pointer to the object, if any, that the remote proxy is
going to be swapped to. This will be used in the remote proxy map.
Having a value in the remote proxy map that is not a remote proxy
could cause issues if somebody ends up calling
GetRemoteOuterWindowProxy() a second time before the transplant has
finished. To avoid that, my patch asserts that we are returning an
object with the appropriate class.
Differential Revision: https://phabricator.services.mozilla.com/D37598
--HG--
extra : moz-landing-system : lando
My preference was to annotate most of the failing tests with `fail-if` so that
if they start passing, the `fail-if` needs to be removed and they need to keep
passing. That doesn't work for tests that timeout, or which trigger failures
from their cleanup functions, however, so those tests need skip-if. And tests
with fail in their cleanup functions likely leave the browser in an
inconsistent state for subsequent tests, anyway, so really should be skipped
regardless.
There are some remaining tests which still fail because of crashes. I chose
not to skip them here, but to fix the crashes in separate bugs instead.
Differential Revision: https://phabricator.services.mozilla.com/D38247
--HG--
extra : rebase_source : 39ba8fec2e882cfe577c5f2b58ab7e4b461f1178
This also adds an extra assertion against browsing context mismatches that
happen when we don't get this right.
Differential Revision: https://phabricator.services.mozilla.com/D36852
--HG--
extra : source : 4b07deb4cd2ef4c98b6d6ee961a20705f4f2deae
When searching for a target by name, don't select a window if its associated
BrowsingContext is closed, discarded, or cached.
Differential Revision: https://phabricator.services.mozilla.com/D37876
--HG--
extra : moz-landing-system : lando
Renames IsActive to IsTargetable, and updates its implementation to check that
the current browsing context is neither closed nor cached.
Differential Revision: https://phabricator.services.mozilla.com/D36670
--HG--
extra : moz-landing-system : lando
We can remove references held in the ContentChild and the ContentParent once the BrowsingContextGroup becomes empty.
This allows to break the cycles and the BrowsingContextGroup to be deleted.
Differential Revision: https://phabricator.services.mozilla.com/D38180
--HG--
extra : moz-landing-system : lando
This should help us more easily identify where the crashing issues are coming
from. The issue in part 1 was found due to these assertion changes.
Differential Revision: https://phabricator.services.mozilla.com/D36996
--HG--
extra : moz-landing-system : lando
This ensures that the object is not discarded while there are still in-flight
messages from the parent process, and vice-versa, which could cause crashes if a
CC was run before any pending messages have arrived.
Differential Revision: https://phabricator.services.mozilla.com/D36995
--HG--
extra : moz-landing-system : lando
We shouldn't perform an anti-tracking check here, since that may result
in us picking the node principal unintentionally.
Differential Revision: https://phabricator.services.mozilla.com/D37811
--HG--
extra : moz-landing-system : lando
In the bug which introduced mIsDiscarded, the code was changed to not set
mClosed during Detach, and only set mIsDiscarded. This was a mistake because a
bunch of places are only reading mClosed. Specifically when creating a
BrowsingContext for an iframe, we check GetClosed() to see whether to skip
creating it. Not doing this check can lead to assertions like the one in this
bug.
This patch changes the behaviour to continue setting `mClosed`, and also updates
the relevant `GetClosed()` checks to correctly check `IsDiscarded()`
Differential Revision: https://phabricator.services.mozilla.com/D37267
--HG--
extra : moz-landing-system : lando
Failures are affecting all platforms now. Let's skip the test entirely until
you can make it more reliable.
Differential Revision: https://phabricator.services.mozilla.com/D37022
--HG--
extra : moz-landing-system : lando
The tests still fail under Fission, because the mechanisms they use to
navigate the frames don't work, but at least the checks for whether the
navigation succeeded now do. That means the tests should start passing when
the necessary APIs become Fission-compatible.
Differential Revision: https://phabricator.services.mozilla.com/D35473
--HG--
extra : rebase_source : 6abaf14899403beec1b00ee78e4796a4446a5f64
extra : source : bf0f0e95c61c2a57d176699f05e71e967a13d3e8
And move the useful bits of it somewhere else (ServoStyleConstInlines.h for the
inline function definitions, and nsFrame.cpp for the static assertions).
Differential Revision: https://phabricator.services.mozilla.com/D36120
And move the useful bits of it somewhere else (ServoStyleConstInlines.h for the
inline function definitions, and nsFrame.cpp for the static assertions).
Differential Revision: https://phabricator.services.mozilla.com/D36120
--HG--
extra : moz-landing-system : lando
Always move browsing contexts to the cache, even if we're not caching
the docshell. If we're not moving to bfcache, BrowsingContext::Detach
will detach as normal.
Differential Revision: https://phabricator.services.mozilla.com/D35594
--HG--
extra : moz-landing-system : lando
This is pretty much the same as ScrollStyles::IsSmoothScroll right now,
but in the next commit, we will no longer propagate scroll-behavior on <body> to
the root element so that nsIScrollableFrame::IsSmoothScroll will be changed
to reflect it.
Differential Revision: https://phabricator.services.mozilla.com/D35737
--HG--
extra : moz-landing-system : lando
Changes:
- migrate over `mochitest-plain` to macosx1014
- disable some tests that are known to be problematic on macosx1014; they are noted in the comments
Differential Revision: https://phabricator.services.mozilla.com/D34589
--HG--
extra : moz-landing-system : lando
This change comes in two parts. First, the code in WindowGlobalChild was changed
to detect the in-process case, and instruct the nsFrameLoader to become a
non-remote nsFrameLoader, and second the logic in WindowGlobalParent was updated
to ensure that the OwnerProcessID is updated after the change.
Differential Revision: https://phabricator.services.mozilla.com/D35060
--HG--
extra : moz-landing-system : lando
Waiting for docshells and frameloaders to destroy will leave attached
browsing contexts attached too long. In case the children of a
browsing contexts cannot be cached we want to detach all of them as
soon as possible.
Also normalizes the use of BrowsingContext::mGroup.
Differential Revision: https://phabricator.services.mozilla.com/D33602
--HG--
extra : moz-landing-system : lando
Waiting for docshells and frameloaders to destroy will leave attached
browsing contexts attached too long. In case the children of a
browsing contexts cannot be cached we want to detach all of them as
soon as possible.
Also normalizes the use of BrowsingContext::mGroup.
Differential Revision: https://phabricator.services.mozilla.com/D33602
--HG--
extra : moz-landing-system : lando
This patch adds the ability to load cross domain iframes in the
background to make the top level documents finish earlier.
This is an experiment feature that we'll keep it disabled by default.
Differential Revision: https://phabricator.services.mozilla.com/D24938
--HG--
extra : moz-landing-system : lando
This ensures that links in about:license to about:rights and about:buildconfig actually work.
Differential Revision: https://phabricator.services.mozilla.com/D34136
--HG--
extra : moz-landing-system : lando
This is sorta-part of the work for bug 1510760. Currently if you do a process
switch, the window proxy state is completely borked, and a lot of stuff doesn't
work.
This patch aims to make it so that, while not transplanted correctly, methods
generally don't return the wrong WindowProxy object anymore after a process
swap.
Differential Revision: https://phabricator.services.mozilla.com/D33082
--HG--
extra : moz-landing-system : lando
Also, in many place, we use document uri as referrer. It is not right
for the case srdoc iframe. We should use the last non-srdoc parent
document's uri
Differential Revision: https://phabricator.services.mozilla.com/D30191
--HG--
rename : testing/web-platform/tests/referrer-policy/generic/iframe-inheritance.html => testing/web-platform/tests/referrer-policy/generic/inheritance/iframe-inheritance-data.html
rename : testing/web-platform/tests/referrer-policy/generic/iframe-inheritance.html => testing/web-platform/tests/referrer-policy/generic/inheritance/iframe-inheritance-srcdoc.html
extra : moz-landing-system : lando
This patch makes several changes to the kinds of URLs where we can cancel
content JS when navigating between them:
1) When navigating directly to a URL (e.g. by typing something into the
location bar and hitting Enter), we allow canceling content JS if the URLs
differ in any way *except* their ref ("#"). To help with this, we also
attempt to fix up the URL (e.g. by prepending "http://" to it).
2) When navigating through history, we allow canceling content JS if the
`prePath` part of the URLs differ. Most notably, this allows canceling
content JS when one of the URLs is an `about:` page (e.g. when hitting the
Home button).
3) We explicitly disallow cancelling content JS if the currently-running JS
is trusted or if the page being navigated away from is anything but
http(s): or file:.
4) We also disallow cancelling content JS for windows that are still being
created (e.g. when creating a new tab or window via `window.open`). For
more background on this, see the comments about `mCreatingWindow` in
dom/ipc/BrowserParent.h.
5) We ensure that, when attempting to cancel JS, the tab ID of the
currently-running script matches the original tab that requested the
cancellation. This avoids a race condition in which a particular JSContext
has already moved on to executing another tab's JS by the time we hit our
interrupt callback.
Differential Revision: https://phabricator.services.mozilla.com/D31875
--HG--
extra : moz-landing-system : lando
This is sorta-part of the work for bug 1510760. Currently if you do a process
switch, the window proxy state is completely borked, and a lot of stuff doesn't
work.
This patch aims to make it so that, while not transplanted correctly, methods
generally don't return the wrong WindowProxy object anymore after a process
swap.
Differential Revision: https://phabricator.services.mozilla.com/D33082
--HG--
extra : moz-landing-system : lando
Right now there's some duplicated code with the focus manager and the
DOMWindowFocus event.
Android didn't handle the new framefocusrequested event, so the test-cases in
bug 416771 still didn't work there.
I think using the focus manager codepath everywhere is preferable. I confirmed
manually that the stuff that sent DOMWindowFocus events still works as expected
with this patch (i.e., switching to the right tab when you click on a
notification, etc.).
This fixes it so that it works in Fennec, and it sends the focus events right in
GeckoView Example (i.e., we get here[1] properly).
The snippet that Snorp provided on IRC to implement the "bring activity to
front" stuff (`startActivity(getIntent())`) didn't actually work for me, but I
confirmed that the right message is sent when the focus is requested, and that
we get there.
[1]: https://searchfox.org/mozilla-central/rev/952521e6164ddffa3f34bc8cfa5a81afc5b859c4/mobile/android/geckoview_example/src/main/java/org/mozilla/geckoview_example/GeckoViewActivity.java#503
Depends on D32353
Differential Revision: https://phabricator.services.mozilla.com/D32354
--HG--
extra : moz-landing-system : lando
These are generally:
- Code comments to browser.xhtml
- Testcases, assertions that were mostly using browser.xul as a generic chrome URL
- References to the browser.xul path in tree
Differential Revision: https://phabricator.services.mozilla.com/D33208
We do this because we will be introducing more privileged content processes
and we want to be able to distinguish them.
Differential Revision: https://phabricator.services.mozilla.com/D30274
--HG--
rename : browser/base/content/test/tabs/browser_new_tab_in_privileged_process_pref.js => browser/base/content/test/tabs/browser_new_tab_in_privilegedabout_process_pref.js
extra : moz-landing-system : lando
The requestor should be ourselves: the toplevel docshell that the tabgroup does
not need to look in when doing the search.
Differential Revision: https://phabricator.services.mozilla.com/D32422
--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
This bug will use the browsing context to notify content tab to mute/unmute media, instead of using MessageManager. We would use the top level canonical browsing context to
set the media mute property for the top level window and propagate it to other top level windows in other processes.
If we don't do so, we're not able to mute/unmute media in the different process when we we enable Fission, because the current way we use can only notify one process and would cause the media on other process can't be muted/unmuted.
Differential Revision: https://phabricator.services.mozilla.com/D32077
--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
This prepares nsFrameLoader for replacing mBrowserParent and mBrowserBridgeChild
with a common interface by making special case code use a getter method instead
of direct access.
Differential Revision: https://phabricator.services.mozilla.com/D31437
--HG--
extra : source : 32eeee79d628dade8109454c636d5f8aaff0c93e
This prepares nsFrameLoader for replacing mBrowserParent and mBrowserBridgeChild
with a common interface by making special case code use a getter method instead
of direct access.
Differential Revision: https://phabricator.services.mozilla.com/D31437
--HG--
extra : rebase_source : a3493579481b7b79086c34486b7342783fd68070
extra : histedit_source : d4a2909d13575822d36611879d2e14211ef2cf3a
Still having lots of issues with tests failing, but need to get this
landed for various reasons. Followup to pref on at Bug 1550571.
Differential Revision: https://phabricator.services.mozilla.com/D30563
We shouldn't be creating browsing contexts in chrome. Add
assertion (behind pref that guards the rest of this patch set) to make
sure that doesn't happen.
Differential Revision: https://phabricator.services.mozilla.com/D30561
In order to not have detach called on non-existent BrowsingContexts,
we need to hold browsing contexts alive until the lifetime of
ContentChild has ended.
Differential Revision: https://phabricator.services.mozilla.com/D29782
When changing processes and therefore destroying/rebuilding
frameloaders, add ability to keep the browsing context around and add
it to the new frameloader.
Differential Revision: https://phabricator.services.mozilla.com/D26267
We can run /debug mochitests against geckoview for the cost of another dozen
or so test annotations. Both /opt and /debug mochitests are nearly worthy of
tier 1, but still waiting for bug 1534732.
Differential Revision: https://phabricator.services.mozilla.com/D30931
--HG--
extra : moz-landing-system : lando
If an XPIDL interface has a method or attribute that is [notxpcom],
then it is implicitly treated as [builtinclass], even if it is not
marked as such. For clarity, this patch goes through and marks every
place that relies on this behavior (aside from some test code).
Differential Revision: https://phabricator.services.mozilla.com/D30714
--HG--
extra : moz-landing-system : lando
`nsIDocumentStateListener` is a scriptable interface and each method may run
any script. So, we should mark them as `can_run_script`. Then, we need to
mark a lot of editing methods because we need to mark
`EditorBase::EndTransactionInternal()` and `EditorBase::DoTransactionInternal()`
as `MOZ_CAN_RUN_SCRIPT`.
Differential Revision: https://phabricator.services.mozilla.com/D30360
--HG--
extra : moz-landing-system : lando
This is essentially equal to restoring cached children and removing
current children from a BrowsingContext, which is the correct
behaviour. It would've been better if the current children were
removed in a more transparent manner, but it is more important to
remove an assert that too eagerly triggers.
Differential Revision: https://phabricator.services.mozilla.com/D29945
--HG--
extra : moz-landing-system : lando
These tests need to be disabled to get a green run on the Android x86_64
test platform. The failures in toolkit/components/extensions are
concerning and definitely require follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D29843
--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
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
Kershaw Chang
Kris Maglione
Brindusan Cristian
Jon Coppeard
Boris Zbarsky
Olli Pettay
Coroiu Cristina
Andrew McCreight
Sylvestre Ledru
Cosmin Sabou
alwu
Daniel Varga
Junior Hsu
Nika Layzell
Jared Wein
Bogdan Tara
Brian Hackett
Kannan Vijayan
Emilio Cobos Álvarez
Benjamin
Will Hawkins
James Willcox
Thomas Nguyen
Nicholas Nethercote
Ciure Andrei
Cameron McCormack
Oana Pop Rus
Noemi Erli
Kashav Madan
Jean-Yves Avenard
Gijs Kruitbosch
Dorel Luca
Ehsan Akhgari
Jonathan Kingston
Geoff Brown
Victor Porof
Razvan Maries
arthur.iakab
Sebastian Streich
Andreas Farre
Valentin Gosu
Narcis Beleuzu
Hiroyuki Ikezoe
Edwin Gao
Sean Feng
Christoph Kerschbaumer
Jim Porter
shindli
Henri Sivonen
Melvin George
Honza Bambas
Brian Grinstead
Tom Ritter
Mihai Alexandru Michis
Barret Rennie
Edgar Chen
Tim Nguyen
Carolina
Brendan Dahl
Ryan Hunt
Gurzau Raul
Jonathan Watt
Kyle Machulis
Masayuki Nakano
Andrea Marchesini
Mike Conley