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
After enable Fission, we're not able to resume media in the different process, because the current way we use can only notify one process and would cause the media on other process can't be resumed.
Therefore, we should use the browsing context to notify the web content which might be on different processes.
Differential Revision: https://phabricator.services.mozilla.com/D18136
--HG--
extra : moz-landing-system : lando
Currently when we have an in-process WindowProxy object, we will attempt
to either use the cached mWindowProxy value, or fetch the
nsGlobalWindowOuter object from through the nsDocShell. Unfortunately,
when the BrowsingContext is detached, we will fail to get the
nsGlobalWindowOuter object. This happens to be OK for our test cases, as
the cached mWindowProxy value doesn't have the chance to go away, but
isn't acceptable long-term.
These patches exascerbated that issue by causing the nsDocShell pointer
itself to be cleared when it is destroyed, which caused the Remote
WindowProxy logic to be triggered. To deal with that case, this patch
adds a new mIsInProcess flag to continue to act like the old code-path.
In the future, we will need to also handle ensuring that the
nsGlobalWindowOuter lives for long enough, however that is not being
done in this patch in order to land it sooner rather than later.
Depends on D22763
Differential Revision: https://phabricator.services.mozilla.com/D22764
--HG--
extra : moz-landing-system : lando
This is important to allow creating BrowsingContexts outside of the process
where they are going to be used. This is largely a re-arrangement of existing
code.
There is currently no way to do this type of attaching for browsing contexts in
existing BrowsingContextGroups, which creates some limitations, but happens to
be sufficient for us in the current situation.
Differential Revision: https://phabricator.services.mozilla.com/D21095
--HG--
extra : moz-landing-system : lando
This is important to allow creating BrowsingContexts outside of the process
where they are going to be used. This is largely a re-arrangement of existing
code.
There is currently no way to do this type of attaching for browsing contexts in
existing BrowsingContextGroups, which creates some limitations, but happens to
be sufficient for us in the current situation.
Differential Revision: https://phabricator.services.mozilla.com/D21095
--HG--
extra : moz-landing-system : lando
This implements the step of choosing a browsing context with
FindWithName, which should be equivalent to calling
nsIDocShellTreeItem.findItemWithName passing null for 'aRequestor' and
'aOriginalRequestor' and false for 'aSkipTabGroup'.
Differential Revision: https://phabricator.services.mozilla.com/D15190
--HG--
extra : moz-landing-system : lando
This patch changes the logic such that we use the new direct
BrowsingContext ParamTraits implementation when possible, and avoids
doing manual lookups.
Depends on D19178
Differential Revision: https://phabricator.services.mozilla.com/D19179
--HG--
extra : moz-landing-system : lando
This patch takes the approach of taking a reference, so that we can land
it into the tree more quickly & fix issues we have.
This isn't a final solution by any means, we should also do something
along the lines of the StableState approach, but it should be sufficient
for now.
Depends on D19177
Differential Revision: https://phabricator.services.mozilla.com/D19178
--HG--
extra : moz-landing-system : lando
As the user gesture activation flag is a flag which is used to reflect whether the corresponding document of browsing context has been activated by user or not, we should reset the flag when the top level window changes its document.
Differential Revision: https://phabricator.services.mozilla.com/D16094
--HG--
extra : moz-landing-system : lando
This patch moves the user gesture activation flag from saving in document to saving in browsing context. The flag would be saved in the top level browsing context and then every time we need to check for that flag, we will request it from top level browsing context.
Differential Revision: https://phabricator.services.mozilla.com/D15435
--HG--
extra : moz-landing-system : lando
Make the WindowProxyHolder hold a strong reference to a BrowsingContext, as in the future
we might not have a nsPIDOMWindowOuter (if the document is loaded in a different process).
Differential Revision: https://phabricator.services.mozilla.com/D12651
--HG--
extra : moz-landing-system : lando
Add top-level and auxiliary browsing contexts to a group of
BrowsingContexts on creation and store a pointer to that group in all
children of the BrowsingContexts in the group. With this it is
possible to compute the transitive closure of related browsing
contexts.
Since we'll not be using linked lists of BrowsingContexts for neither
groups nor children we can move children to be an array of
BrowsingContexts and adjust to use a the more convenient HashMap for
roots.
Differential Revision: https://phabricator.services.mozilla.com/D13227
--HG--
extra : moz-landing-system : lando
This serves 2 purposes:
1. Provides an object corresponding to an inner window which Chrome JS can hold onto.
2. Provides the object to JS which Chrome JS per-window actors will be attached to.
3. Provides useful information to Chrome JS in the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D9394
This allows getting the set of all window globals for a given browsing context.
This is less useful at the moment as the active window global is not exposed as
such. That will be added as a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D9393
By replacing nsWebBrowser's implementation of the
nsIBaseWindow.initWindow and nsIBaseWindow.create with a new static
nsWebBrowser::Create method we make it possible to pass arguments
directly when creating an nsWebBrowser, for example the opener
BrowsingContext. As a bonus we can do away with
nsWebBrowser::mInitInfo!
Differential Revision: https://phabricator.services.mozilla.com/D12634
--HG--
extra : moz-landing-system : lando
Create ChromeBrowsingContext and move parent process specific parts
from BrowsingContext there. After that make sure that all
BrowsingContexts created in the parent process is actually
ChromeBrowsingContexts and all BrowsingContexts in the child processes
are BrowsingContexts.
Differential Revision: https://phabricator.services.mozilla.com/D5419
--HG--
extra : moz-landing-system : lando
Expose Chrome only WebIDL to interface with BrowsingContext from
script. The API consists of parent, firstChild and nextSibling
attributes for BrowsingContext, and the browsingContext attribute for
Window.
--HG--
extra : rebase_source : 772d25e8b4e5526453545ddb2b1607845f3b65ea
