Add a new FIXUP_FLAG_PRIVATE_CONTEXT to nsIURIFixup, make it use the default
private search engine when it's set.
Update consumers to pass the new flag when necessary.
Differential Revision: https://phabricator.services.mozilla.com/D48741
--HG--
extra : moz-landing-system : lando
When we have a parser-created iframe which starts out in-process, transitions
to remote, and then transitions back to in-process, we create separate
DocShells for the first and last in-process loads. Since both are
network-created, and have the same child index, they both try to add
themselves as children to their parent's SHistory at the same index. And since
the entry for the first DocShell already exists at that index when we try to
add the second, that triggers an assertion.
This isn't really ideal, but it is expected given the current state of session
history under Fission. It should hopefully be solved more gracefully when the
Fission-aware session history rewrite is done, but in the mean time, I think
we should just ignore the conflict, since it's expected.
Differential Revision: https://phabricator.services.mozilla.com/D48437
--HG--
extra : moz-landing-system : lando
We attempt to enforce the same (approximate) access checks to Location-based
navigation that we use for loads that use named targeting (e.g., via
window.open), so that a frame that can't be navigated via, e.g., window.open,
also can't be navigated via, e.g., window.parent[1].location = url. For the
in-process case, this is handled by a somewhat hidden call to
CheckLoadingPermissions() in nsDocShell::InternalLoad, where the former checks
whether the principal of whatever JS context happens to be on the stack
subsumes the principal of the target DocShell or any of its ancestors, and
blocks the load if it doesn't.
Since there is no JS context on the stack when we call into the DocShell
loading code in the cross-process case, the check is simply ignored.
So we need to instead do the check in BrowsingContext::LoadURI, where we
already have an explicit accessor, and can simply use the standard access
checks that we use elsewhere.
Differential Revision: https://phabricator.services.mozilla.com/D48443
--HG--
extra : moz-landing-system : lando
We were keeping nsDocShell::mHistoryId and nsDocShell::mOSHE as keys. They
weren't quite good because:
1. While loading an iframe, they were being registered twice with the same
ids(for about:blank and the real URL) sometimes.
2. It wasn't possible to access to the parent mHistoryId and mOSHE from a child
processes if the parent is in a different process. That may not be the case for
now, but it will be after fission.
So we had to find other IDs to:
1. Determine the Tab of the frames.
2. Determine the URLs of the frames.
For the first use case, we were using nsDocShell::mHistoryId for that purpose
but that was wrong. The closest thing that we can get to a tab ID is
BrowsingContext ID because they don't change after a navigation. But iframes
have different BrowsingContext's, so we still need to create a tree to
construct a tab content. That can be either in the front-end or capture time.
For the second use case, we were using a key pair of mHistoryId and mOSHE. We
now chose to keep inner window IDs for that purpose. Inner window IDs are
unique for each navigation loads because inner window correspond to each JS
window global objects. That's why we can use that without any problem. But one
problem is that we cannot handle `history.pushState` and `history.replaceState`
changes with that change since window global objects won't change during those.
But that was the best thing we can do after fission. So this will be a small
sacrifice for us to keep that functionality working after fission.
In that patch we also remove the registration/unregistration calls. We are
going to add those calls in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D47065
--HG--
extra : moz-landing-system : lando
These still fail or timeout because of missing platform features, but at least
the tests will pass once those platform features are fixed after this.
Differential Revision: https://phabricator.services.mozilla.com/D48221
--HG--
extra : moz-landing-system : lando
The key change here is to use SpecialPowers.spawn to access `location.href`
and `location.reload()` for remote windows in the correct proceses. The
remaining changes are refactorings to make it easier to encorporate async
operations like `SpecialPowers.spawn` in the test logic.
Differential Revision: https://phabricator.services.mozilla.com/D48220
--HG--
extra : moz-landing-system : lando
This flips the direction in which the BrowserBridge actor is generally created
such that it is generally created in the parent and sent down to a child
process.
This is done by making the decision about what kind of switch to perform in the
parent, and sending messages down to child processes async to orchestrate these
process changes.
Process launching is changed to use an async `MozPromise`-returning API in this
patch, though the actual process launching still occurs synchronously. A future
patch will enable performing async process launching through the
NewOrUsedBrowserProcess mechanism.
I know of at least a few timing issues which exist with the new logic,
especially around the state of the BrowsingContext during the process
transition. I decided to not try to fix all of these issues in this patch, as
many are complex and will require changing how we manage the lifecycle of
BrowsingContext substantially. I do, however, think that the new logic is more
reliable and has fewer timing issues than the previous logic.
Differential Revision: https://phabricator.services.mozilla.com/D47310
--HG--
extra : moz-landing-system : lando
This test was skipped on Android for a long time, then recently enabled by
bug 1582884. Current failures are infrequent, but let's avoid them anyway.
Differential Revision: https://phabricator.services.mozilla.com/D47795
--HG--
extra : moz-landing-system : lando
This flips the direction in which the BrowserBridge actor is generally created
such that it is generally created in the parent and sent down to a child
process.
This is done by making the decision about what kind of switch to perform in the
parent, and sending messages down to child processes async to orchestrate these
process changes.
Process launching is changed to use an async `MozPromise`-returning API in this
patch, though the actual process launching still occurs synchronously. A future
patch will enable performing async process launching through the
NewOrUsedBrowserProcess mechanism.
I know of at least a few timing issues which exist with the new logic,
especially around the state of the BrowsingContext during the process
transition. I decided to not try to fix all of these issues in this patch, as
many are complex and will require changing how we manage the lifecycle of
BrowsingContext substantially. I do, however, think that the new logic is more
reliable and has fewer timing issues than the previous logic.
Differential Revision: https://phabricator.services.mozilla.com/D47310
--HG--
extra : moz-landing-system : lando
We can remove isOnlyToplevelInTabGroup entirely since we have
BrowsingContext/BrowsingContextGroup exposed through
chrome-webidl. Checking if a browsing context is the only top level
(auxilliary or otherwise) is only a matter of checking that there
isn't a parent, and that the size of the browsing context group is 1.
Differential Revision: https://phabricator.services.mozilla.com/D46590
--HG--
extra : moz-landing-system : lando
We can remove isOnlyToplevelInTabGroup entirely since we have
BrowsingContext/BrowsingContextGroup exposed through
chrome-webidl. Checking if a browsing context is the only top level
(auxilliary or otherwise) is only a matter of checking that there
isn't a parent, and that the size of the browsing context group is 1.
Differential Revision: https://phabricator.services.mozilla.com/D46590
--HG--
extra : moz-landing-system : lando
This also allows us to remove TabGroup::FindItemWithName, which is a
big step towards removing TabGroup entirely.
Differential Revision: https://phabricator.services.mozilla.com/D46285
--HG--
extra : moz-landing-system : lando
This also allows us to remove TabGroup::FindItemWithName, which is a
big step towards removing TabGroup entirely.
Differential Revision: https://phabricator.services.mozilla.com/D46285
--HG--
extra : moz-landing-system : lando
People keep adding useless null-checks and it was not clear what the consensus
was from bug 1441165, but this should be unobjectionable I guess.
Differential Revision: https://phabricator.services.mozilla.com/D46781
--HG--
extra : moz-landing-system : lando
Also while doing it:
* Ensure activity observers get notified after visibility is computed already.
This is how we notify all other activity observers already, and we are
double-notifying in the case we actually get a page show _and_ a visibility
change, but this is a pre-existing problem.
* Remove special-cases for InFrameSwap() from MediaRecorder. Now that pagehide
doesn't mess up with our visibility state the regular check just works. I
ensured I didn't regress bug 1444541.
* Had to fix a UITour test that relied on the visibility changing back and
forth for the detached tab. It seems there's no real place in UITour that
listens to that event so we should be good.
* Added tests, verifying that they both fail without the patch.
After this we can remove nsDocShell::InFrameSwap(), as the only caller is the
assertion, but I wanted to keep it regardless, at least for now, until this
patch has been in for a bit.
Differential Revision: https://phabricator.services.mozilla.com/D45906
--HG--
extra : moz-landing-system : lando
Also while doing it:
* Ensure activity observers get notified after visibility is computed already.
This is how we notify all other activity observers already, and we are
double-notifying in the case we actually get a page show _and_ a visibility
change, but this is a pre-existing problem.
* Remove special-cases for InFrameSwap() from MediaRecorder. Now that pagehide
doesn't mess up with our visibility state the regular check just works. I
ensured I didn't regress bug 1444541.
* Had to fix a UITour test that relied on the visibility changing back and
forth for the detached tab. It seems there's no real place in UITour that
listens to that event so we should be good.
* Added tests, verifying that they both fail without the patch.
After this we can remove nsDocShell::InFrameSwap(), as the only caller is the
assertion, but I wanted to keep it regardless, at least for now, until this
patch has been in for a bit.
Differential Revision: https://phabricator.services.mozilla.com/D45906
--HG--
extra : moz-landing-system : lando
BrowsingContext.findWithName is required to do access checks based on the
requestor, which can only be done in the process which owns it. This change
also alters the behavior of the existing CanAccess origin checks, which
typically treat any item as same-origin, but only when the docshells are
actually same process.
Removing the exemption fixes the behavior discrepancy between Fission and
non-Fission runs, but also requires that the test be updated to expect proper
access checks. Which is the situation we really want to test, anyway.
Differential Revision: https://phabricator.services.mozilla.com/D45837
--HG--
extra : moz-landing-system : lando
In the Quantum Bar it's usually the urlbar code that decides whether a search
string should be visited or searched. if dns_first_for_single_words is set,
we can't make a final decision, because that depends on a dns lookup. For now
we don't want to duplicate the docshell code, also because we must keep the
old behavior functioning for cases where the urlbar value is set without input.
Similarly, when the docshell decides to search for a single word host, and a
dns lookup resolves it, it also shows a prompt asking the user if he meant to
visit it instead of searching. Because the urlbar skips the docshell decision
making, we must manually call the fixup prompt code from the urlbar.
Differential Revision: https://phabricator.services.mozilla.com/D45743
--HG--
extra : moz-landing-system : lando
The (non-normative) window.open spec does not specify what should happen when
window.open is called on a window with a null/discarded browsing context, but
in general the lookup and creation rules do not make sense when the window has
no BC. It does, however, specify that we should return null when a target BC
cannot be found or created, and gives us broad discretion over when we decide
to ignore a load request and return null. Since we can't trigger a
cross-process load from a discarded BC, simply aborting in that case seems
like the logical solution.
For Location objects, the spec is more specific, and requires that we ignore
load attempts on Location objects whose documents are null, which in our
implementation corresponds to a discarded BrowsingContext.
LocationBase::SetURI already enforces this, but a second check in
BrowsingContext::LoadURI is probably a good idea as well.
Differential Revision: https://phabricator.services.mozilla.com/D45635
--HG--
extra : moz-landing-system : lando
To be able to reach all BrowsingContexts in
BrowsingContextGroup::EnsureSubscribed we need to make sure that if a
BrowsingContext is detached, we need to cache all of its children in
case we call BrowsingContextGroup::EnsureSubscribed before the
children in turn are detached.
Differential Revision: https://phabricator.services.mozilla.com/D45337
--HG--
extra : moz-landing-system : lando
The CommonCreateWindow code requires having a BrowserHost for the tab that's
creating the window, which it tries to get from the requestor's BrowserParent.
For remote BrowserParents, though, there is no BrowserHost, so we need to get
it from the top-level embedder instead.
Differential Revision: https://phabricator.services.mozilla.com/D45172
--HG--
extra : moz-landing-system : lando
Remove test manifest annotations that specifically target fennec,
or likely target the android 4.3 emulator.
Differential Revision: https://phabricator.services.mozilla.com/D45018
--HG--
extra : moz-landing-system : lando
DocumentChannel acts as a replacement for HttpChannel where redirects are now entirely handled in the DocumentChannelParent. The ContentChild will receive the final nsIChannel once all redirects have been handled.
Differential Revision: https://phabricator.services.mozilla.com/D37490
Add a new callback to session history listener to listen for content
viewers being evicted.
Differential Revision: https://phabricator.services.mozilla.com/D32731
--HG--
extra : rebase_source : 29c8e9299af718e75029dfae4e937a3d4f18900d
extra : amend_source : 19e679c6d2721dd7e8d7da1ec7af3033439210b4
extra : source : 5e4d0ab9e52ce1e1d1684fdb59534a66e9f9d9b9
extra : histedit_source : 44e9cb7ba0589c79c03b2dc58ec4d0d4c0c98422
When we need to evict content viewers, we group SHEntrySharedParentState,
corresponding to session history entries that need to be evicted, by their
content parent and send their id's to their corresponding parents for eviction.
Differential Revision: https://phabricator.services.mozilla.com/D32730
--HG--
extra : rebase_source : 17398d3ed2fdf5debba8224559c48f41b4cfbf2d
extra : source : 0feb286c5b85e6e2a0ac56058c596324ca28d817
extra : histedit_source : ba6c9eb5c6ce7013b80c407372eeab7146b07f51
Inside of nsDocShell::UpdateURLAndHistory, there are 4 sync IPC calls to
nsSHistory plus 1 static call, which contains at least one nsSHEntry::GetParent
sync IPC call. All of these calls can be moved inside of a new method
EvictContentViewersOrReplaceEntry on nsSHEntry, resulting in just 1 sync IPC
call.
Differential Revision: https://phabricator.services.mozilla.com/D32729
--HG--
extra : rebase_source : ad09a9061cd6fe8eb6796b2809ea191aceb3ac73
extra : source : 2cd5cd24763ff320719aedb2142a79822efd6de4
extra : histedit_source : fdc4f80cfd8807e46c2dc02e6ab82f2bd3acc391
Currently, nsDocShell::GetChildSHEntry calls 3 sync IPC calls on nsISHEntry,
and the method GetChildSHEntry only has one caller. By moving GetChildSHEntry
method to parent process for nsISHEntry, resulting in a new method
nsISHEntry::GetChildSHEntry, 3 sync IPC calls can be reduced to 1.
Differential Revision: https://phabricator.services.mozilla.com/D27633
--HG--
extra : rebase_source : 1e76a1b07d827b35bae7ed6acca25aa8732c9ed0
extra : source : 34d91f82faa36dd8d8ed721de365122d831f7b25
extra : histedit_source : 86592bc747d506c546ec660e57087e78b9719cf7
Inside of nsDocShell::OnNewURI there are 4 sync IPC calls
to nsSHistory that can be replaced with 1 sync IPC call
by adding a new method EnsureCorrectEntryAtCurrIndex to nsSHistory.
Differential Revision: https://phabricator.services.mozilla.com/D31539
--HG--
extra : rebase_source : 09d7738b2f2dc2334c8f6186e5918b9d0ea3e618
extra : source : 82a41bffcbbca24ad3e84b045d75e4cb01ae1445
extra : histedit_source : 96eb7d2dbed2ad8fe4cc2d37358ec2358f696442
In nsDocShell::LoadHistoryEntry method, when it gets called
from parent process, there are 13 sync IPC calls on nsISHEntry
that retrieve information from the session history entry and
create a doc shell load state object using the retrieved
information. By adding a new method 'CreateLoadInfo'on nsISHEntry,
inside of which the doc shell load state object will be
created (with appropriate data filled out) and returned,
we eliminate 12 sync IPC call, resulting in just 1 IPC call
to nsISHEntry::CreateLoadInfo.
Differential Revision: https://phabricator.services.mozilla.com/D26042
--HG--
extra : rebase_source : a4e1fa52932fd5caabb59bd133e9fbee7f4d0e4a
extra : amend_source : f4d9f01afac0337808ba347eb997ce83e6ae1488
extra : source : 6ad53b35c7b4be933a3db1e1d45fa3da8a57abad
extra : histedit_source : c08d0cebcc11a3a4f64d01566cb62d9a334a12ec
nsDocShell is the only consumer of nsISHEntry::Create, and
in AddToSessionHistory method, after calling nsISHEntry::Create,
it calls 8 setter methods on nsISHEntry, which results in a
total of 9 sync IPC calls.
With the proposed solution of setting everything via
nsISHEntry::Create, we get a total of 1 sync IPC call.
Differential Revision: https://phabricator.services.mozilla.com/D24979
--HG--
extra : rebase_source : af9c75043260a6333d789d3ca882173703f7bc29
extra : amend_source : 334281153e24f9e9f0abac3983d32fb99dae6995
extra : source : a8eed7c5d12c49366ad8acd706fa0e8464ed8549
extra : histedit_source : 653daabf83d43571803a1e33c95a4804e4275e7d
Currently, nsDocShell repeatedly calls nsISHEntry::GetChildAt and
nsISHEntry::RemoveChild in nsDocShell::AddToSessionHistory,
which results in twice as many IPC calls as the number of children
a session history entry has. Additionally, there is one extra
IPC sync call to nsISHEntry::AbandonBFCacheEntry after the loop.
With the proposed solution, there will only be 1 sync IPC call.
Differential Revision: https://phabricator.services.mozilla.com/D24978
--HG--
extra : rebase_source : ab98af417bcb28fdfcb1a115473b505fa8a70aa1
extra : source : 0270d6b952ffa1704690c777c55fcaed30125b38
extra : histedit_source : 9a031cb921ad8efa1bd96f7342e08337f3c0ca8a
Currently, nsDocShell repeatedly calls nsISHEntry::GetChildAt, which
results in as many IPC sync calls as the number of children
a session history entry has. Calling nsISHEntry::GetChildCount and
ChildSHistory::Index and incurs additional extra 2 sync IPC calls.
With the proposed solution, there will only be 1 sync IPC call.
Differential Revision: https://phabricator.services.mozilla.com/D24980
--HG--
extra : rebase_source : ffaaff5c9521fb4d3a53a85f4570bcb99f7317d1
extra : source : 3f4a092d8f6544a212ee8a80d9275ae68c6446d1
extra : histedit_source : b4166d997119092ba5657f9ca4216da62dc82d97
Also adds a legacy `GetSameProcessOpener()` method for callers which can only
deal with in-process windows and may need to be updated for Fission.
Differential Revision: https://phabricator.services.mozilla.com/D43692
--HG--
extra : source : 0ddbc451dcab431c2a1d934fa9baa5e8efc71545
This is currently only available on the outer window, but needs to move to
BrowsingContext in order from us to remove redundant opener tracking from the
former.
Differential Revision: https://phabricator.services.mozilla.com/D43690
--HG--
extra : source : be7cbc61f825fdfc36b20d476bef710ef275ad73
Also adds a legacy `GetSameProcessOpener()` method for callers which can only
deal with in-process windows and may need to be updated for Fission.
Differential Revision: https://phabricator.services.mozilla.com/D43692
--HG--
extra : moz-landing-system : lando
This is currently only available on the outer window, but needs to move to
BrowsingContext in order from us to remove redundant opener tracking from the
former.
Differential Revision: https://phabricator.services.mozilla.com/D43690
--HG--
extra : moz-landing-system : lando
ReferrerPolicy gets tossed back and forth as a uint32_t and
ReferrerPolicy enum in header file. Expose ReferrerPolicyValues from
webidl file and use consistently in native code.
Differential Revision: https://phabricator.services.mozilla.com/D41954
--HG--
extra : moz-landing-system : lando
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
Andreas Farre
Jorg K
Marco Bonardo
Kris Maglione
Matt Woodrow
Nazım Can Altınova
Nika Layzell
Brindusan Cristian
Narcis Beleuzu
Brendan Dahl
Dylan Roeh
Sylvestre Ledru
Csoregi Natalia
Geoff Brown
Gabriele Svelto
Christoph Kerschbaumer
Anny Gakhokidze
Peter Van der Beken
shindli
Emilio Cobos Álvarez
Bogdan Tara
arthur.iakab
Dorel Luca
Edgar Chen
Kashav Madan
Agi Sferro
Daniel Varga
Jonathan Watt
James Willcox
Jean-Yves Avenard
Ehsan Akhgari
Junior Hsu
Benjamin
Andreea Pavel
Mihai Alexandru Michis
Cosmin Sabou
Thomas Nguyen
Abdoulaye O. Ly
Kershaw Chang
Jon Coppeard
Boris Zbarsky
Olli Pettay
Coroiu Cristina
Andrew McCreight
alwu
Jared Wein
Brian Hackett
Kannan Vijayan
Will Hawkins