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
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
This excludes dom/, otherwise the file size is too large for phabricator to handle.
This is an autogenerated commit to handle scripts loading mochitest harness files, in
the simple case where the script src is on the same line as the tag.
This was generated with https://bug1544322.bmoattachments.org/attachment.cgi?id=9058170
using the `--part 2` argument.
Differential Revision: https://phabricator.services.mozilla.com/D27456
--HG--
extra : moz-landing-system : lando
Additionally, this patch makes `nsDocumentViewer` which is the only
implementation of `nsIContentViewer` use `mozilla::PresShell` directly
rather than via `nsIPresShell`.
Differential Revision: https://phabricator.services.mozilla.com/D27470
--HG--
extra : moz-landing-system : lando
So, this patch makes all caller of it safe including its arguments unless
they come from other methods.
Differential Revision: https://phabricator.services.mozilla.com/D27225
--HG--
extra : moz-landing-system : lando
This patch makes `nsDocShell::GetPresShell()` and
`nsDocShell::GetEldestPresShell()` return `mozilla::PresShell*` and
some non-public methods use `mozilla::PresShell*` directly.
Differential Revision: https://phabricator.services.mozilla.com/D26424
--HG--
extra : moz-landing-system : lando
Bug 304860 and bug 1364364 have disabled the bfcache for subframes, so we only
store the contentviewer in the root entry.
Depends on D25761
Differential Revision: https://phabricator.services.mozilla.com/D25763
--HG--
extra : moz-landing-system : lando
`nsPICommandUpdater` is a scriptable interface, but nobody refers it from JS,
and it's implemented only by `nsCommandManager`. Therefore, we can get rid
of this interface.
Additionally, `nsCommandManager::Init()` is called only by `nsDocShell`, which
is the only instantiater of the class, and returns error only when given window
is nullptr. Therefore, we can make the constructor take the window instead.
Differential Revision: https://phabricator.services.mozilla.com/D25729
--HG--
extra : moz-landing-system : lando
`nsICommandManager` isn't implemented by JS even in comm-central nor
BlueGriffon. Therefore, we can make it a builtinclass.
Additionally, this patch makes all users in C++ use `nsCommandManager` which is
the only implementation of `nsICommandManager`. This avoids QI from
`nsICommandManager` to `nsPICommandUpdater`.
Differential Revision: https://phabricator.services.mozilla.com/D25726
--HG--
extra : moz-landing-system : lando
`nsPresContext` should use `mozilla::PresShell` directly instead of
`nsIPresShell`. This patch makes it.
Unfortunately, `nsPresContext` and `nsIFrame` have `PresShell()`. Therefore,
we cannot use `PresShell*` in its methods so that this patch uses `mozilla::`
namespace prefix.
It might be better to rename them as `PresShellPtr()` in another bug.
Differential Revision: https://phabricator.services.mozilla.com/D25721
--HG--
extra : moz-landing-system : lando
`nsIEditingSession.SetupEditorOnWindow` is used in `nsDocShellEditorData`.
To get rid of it, I would like to use `nsEditSession` directly instead of
`nsIEditingSession`.
Differential Revision: https://phabricator.services.mozilla.com/D25537
--HG--
extra : moz-landing-system : lando
This patch marks `EditorBase::InsertNodeTransaction()` **and** its callers as `MOZ_CAN_RUN_SCRIPT`.
Unfortunately, this patch tells us that some `GetSomething()` methods may destroy the editor since `HTMLEditRules::GetNodesForOperation()`, `HTMLEditRules::GetNodesFromPoint()` and `HTMLEditRules::GetNodesFromSelection()` may change the DOM tree. Additionally, initialization methods may destroy the editor since it may insert a bogus `<br>` node.
Note that this patch also removes some unused methods. I.e., they are not result of some cleaning up the code. This patch just avoids marking unused methods as `MOZ_CAN_RUN_SCRIPT`.
Differential Revision: https://phabricator.services.mozilla.com/D25027
--HG--
extra : moz-landing-system : lando
This makes `Document::GetShell()` return `PresShell*` instead of `nsIPresShell`.
Additonally, "shell" is unclear ("docshell" vs. "presshell"). Therefore, this
also renames `Document::GetShell()` to `Document::GetPresShell()`.
Similarly, some other method names of `Document` are also renamed from
`*Shell*` to `*PresShell*`.
Differential Revision: https://phabricator.services.mozilla.com/D25338
--HG--
extra : moz-landing-system : lando
This makes `Document::GetShell()` return `PresShell*` instead of `nsIPresShell`.
Additonally, "shell" is unclear ("docshell" vs. "presshell"). Therefore, this
also renames `Document::GetShell()` to `Document::GetPresShell()`.
Similarly, some other method names of `Document` are also renamed from
`*Shell*` to `*PresShell*`.
Differential Revision: https://phabricator.services.mozilla.com/D25338
--HG--
extra : moz-landing-system : lando
This patch marks `EditorBase::InsertNodeTransaction()` **and** its callers as `MOZ_CAN_RUN_SCRIPT`.
Unfortunately, this patch tells us that some `GetSomething()` methods may destroy the editor since `HTMLEditRules::GetNodesForOperation()`, `HTMLEditRules::GetNodesFromPoint()` and `HTMLEditRules::GetNodesFromSelection()` may change the DOM tree. Additionally, initialization methods may destroy the editor since it may insert a bogus `<br>` node.
Note that this patch also removes some unused methods. I.e., they are not result of some cleaning up the code. This patch just avoids marking unused methods as `MOZ_CAN_RUN_SCRIPT`.
Differential Revision: https://phabricator.services.mozilla.com/D25027
--HG--
extra : moz-landing-system : lando
Add a new nsExternalHelperAppService derived class named nsOSHelperAppServiceChild to be used for the MIME service, external helper app service, and external protocol service interfaces in child processes. nsOSHelperAppServiceChild overrides some methods used to get MIME and external protocol handler information from the OS and implements these methods by remoting the calls to the parent process.
This is necessary because, on Mac, querying the OS for helper application info from sandboxed content processes is unreliable and has buggy side effects.
For now, only use the new class on Mac.
Android and unix file changes r+ by gcp.
Windows files changes r+ by bobowen.
Sync messages review r+ by nfroyd.
MozReview-Commit-ID: 63BiS6VCxfn
Differential Revision: https://phabricator.services.mozilla.com/D15620
--HG--
extra : moz-landing-system : lando
Add a new nsExternalHelperAppService derived class named nsOSHelperAppServiceChild to be used for the MIME service, external helper app service, and external protocol service interfaces in child processes. nsOSHelperAppServiceChild overrides some methods used to get MIME and external protocol handler information from the OS and implements these methods by remoting the calls to the parent process.
This is necessary because, on Mac, querying the OS for helper application info from sandboxed content processes is unreliable and has buggy side effects.
For now, only use the new class on Mac.
Android and unix file changes r+ by gcp.
Windows files changes r+ by bobowen.
Sync messages review r+ by nfroyd.
MozReview-Commit-ID: 63BiS6VCxfn
Differential Revision: https://phabricator.services.mozilla.com/D15620
--HG--
extra : moz-landing-system : lando
This allows this enumeration to be used from nsIPresShell.h without introducing
a circular dependency.
Its new home in layout/base/ScrollTypes.h, included as mozilla/ScrollTypes.h.
Others similar enums can be added to that file if desired.
This patch also makes ScrollMode an enum class (as it's no longer nested
inside a class) and switches its enumerators to the |eName| naming convention.
Differential Revision: https://phabricator.services.mozilla.com/D24796
--HG--
extra : moz-landing-system : lando
This patch uses the flag to exempt channels from classification, but it
doesn't include the use cases of this flag.
See Bug 1442496 for the list of the call sites should use this flag.
Differential Revision: https://phabricator.services.mozilla.com/D22112
--HG--
extra : moz-landing-system : lando
nsIChannel.LOAD_CLASSIFY_URI is no longer required so we can remove it from
the codebase.
In the mean time, we add a new LOAD_BYPASS_URL_CLASSIFIER load flag for
channel creator to be able to force channel to bypass URL classifier check.
The use of the new LOAD_BYPASS_URL_CLASSIFIER flag will be addressed in
the other patches.
Differential Revision: https://phabricator.services.mozilla.com/D22111
--HG--
extra : moz-landing-system : lando
Replaced instances of callers in both C++ and JS files to query the state from the principal directly.
Differential Revision: https://phabricator.services.mozilla.com/D22532
--HG--
extra : moz-landing-system : lando
This patch renames nsIPresShell::SetPendingVisualScrollUpdate() to
ScrollToVisual(), and adds an instant vs. smooth option.
SetPendingVisualScrollUpdate() still exists, as a helper for the instant case.
Differential Revision: https://phabricator.services.mozilla.com/D24553
--HG--
extra : moz-landing-system : lando
This patch uses the flag to exempt channels from classification, but it
doesn't include the use cases of this flag.
See Bug 1442496 for the list of the call sites should use this flag.
Differential Revision: https://phabricator.services.mozilla.com/D22112
--HG--
extra : moz-landing-system : lando
nsIChannel.LOAD_CLASSIFY_URI is no longer required so we can remove it from
the codebase.
In the mean time, we add a new LOAD_BYPASS_URL_CLASSIFIER load flag for
channel creator to be able to force channel to bypass URL classifier check.
The use of the new LOAD_BYPASS_URL_CLASSIFIER flag will be addressed in
the other patches.
Differential Revision: https://phabricator.services.mozilla.com/D22111
--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
Honza Bambas
Ehsan Akhgari
Brian Grinstead
Tom Ritter
Andreas Farre
Mihai Alexandru Michis
Henri Sivonen
Sylvestre Ledru
Nika Layzell
Boris Zbarsky
Barret Rennie
Edgar Chen
arthur.iakab
Tim Nguyen
Carolina
Bogdan Tara
Alastor Wu
Christoph Kerschbaumer
Noemi Erli
Cosmin Sabou
Brendan Dahl
Ryan Hunt
Gurzau Raul
Jonathan Watt
Brian Hackett
Daniel Varga
Brindusan Cristian
Kyle Machulis
Sean Feng
Geoff Brown
Andrew McCreight
Hiroyuki Ikezoe
Masayuki Nakano
Andrea Marchesini
Thomas Nguyen
Mike Conley
Jim Porter
Emilio Cobos Álvarez
Mike de Boer
Coroiu Cristina
Dale Harvey
Khyati Agarwal
Peter Van der Beken
Olli Pettay
Csoregi Natalia
Valentin Gosu
Gijs Kruitbosch
Makoto Kato
Oana Pop Rus
Dorel Luca
Mark Banner
Haik Aftandilian
Botond Ballo
Randell Jesup
Ian Moody
dlee
sakshaat
Mellina Yonashiro
Edwin Gao
Sebastian Hengst