Bug 802366 - The main event: Let a browser process inherit its app's id. r=bz,cjones
The main bug fixed here is that in half of our interfaces, we use "is browser frame/element" to mean "browser or app", and in the other half, we use it to mean "is browser not app".
There's a related, functional bug also fixed here, which is that a browser process doesn't inherit its parent's app-id. This causes problems e.g. for IndexedDB: If a browser inside an app uses IndexedDB, the DB should have the app's app-id.
I also modified Tab{Parent,Child} and nsFrameLoader to call "app" "ownOrContainingApp", to emphasize that we might have inherited the app from a parent process. I left nsIDocShell::appId alone, because changing that would have necessitated changing nsILoadGroup and therefore a /lot/ of users in Necko; it's also not clear it would have clarified anything in those cases.
2012-11-10 10:32:37 -08:00
|
|
|
/* -*- Mode: C++; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
|
2015-05-03 12:32:37 -07:00
|
|
|
/* vim: set ts=8 sts=2 et sw=2 tw=80: */
|
Bug 802366 - The main event: Let a browser process inherit its app's id. r=bz,cjones
The main bug fixed here is that in half of our interfaces, we use "is browser frame/element" to mean "browser or app", and in the other half, we use it to mean "is browser not app".
There's a related, functional bug also fixed here, which is that a browser process doesn't inherit its parent's app-id. This causes problems e.g. for IndexedDB: If a browser inside an app uses IndexedDB, the DB should have the app's app-id.
I also modified Tab{Parent,Child} and nsFrameLoader to call "app" "ownOrContainingApp", to emphasize that we might have inherited the app from a parent process. I left nsIDocShell::appId alone, because changing that would have necessitated changing nsILoadGroup and therefore a /lot/ of users in Necko; it's also not clear it would have clarified anything in those cases.
2012-11-10 10:32:37 -08:00
|
|
|
/* This Source Code Form is subject to the terms of the Mozilla Public
|
|
|
|
* License, v. 2.0. If a copy of the MPL was not distributed with this
|
|
|
|
* file, You can obtain one at http://mozilla.org/MPL/2.0/. */
|
|
|
|
|
|
|
|
#include "mozilla/dom/TabContext.h"
|
2013-09-23 14:30:40 -07:00
|
|
|
#include "mozilla/dom/PTabContext.h"
|
Bug 802366 - The main event: Let a browser process inherit its app's id. r=bz,cjones
The main bug fixed here is that in half of our interfaces, we use "is browser frame/element" to mean "browser or app", and in the other half, we use it to mean "is browser not app".
There's a related, functional bug also fixed here, which is that a browser process doesn't inherit its parent's app-id. This causes problems e.g. for IndexedDB: If a browser inside an app uses IndexedDB, the DB should have the app's app-id.
I also modified Tab{Parent,Child} and nsFrameLoader to call "app" "ownOrContainingApp", to emphasize that we might have inherited the app from a parent process. I left nsIDocShell::appId alone, because changing that would have necessitated changing nsILoadGroup and therefore a /lot/ of users in Necko; it's also not clear it would have clarified anything in those cases.
2012-11-10 10:32:37 -08:00
|
|
|
#include "mozilla/dom/TabParent.h"
|
|
|
|
#include "mozilla/dom/TabChild.h"
|
|
|
|
#include "nsIAppsService.h"
|
2013-09-23 14:30:40 -07:00
|
|
|
#include "nsIScriptSecurityManager.h"
|
2013-09-10 13:56:05 -07:00
|
|
|
#include "nsServiceManagerUtils.h"
|
Bug 802366 - The main event: Let a browser process inherit its app's id. r=bz,cjones
The main bug fixed here is that in half of our interfaces, we use "is browser frame/element" to mean "browser or app", and in the other half, we use it to mean "is browser not app".
There's a related, functional bug also fixed here, which is that a browser process doesn't inherit its parent's app-id. This causes problems e.g. for IndexedDB: If a browser inside an app uses IndexedDB, the DB should have the app's app-id.
I also modified Tab{Parent,Child} and nsFrameLoader to call "app" "ownOrContainingApp", to emphasize that we might have inherited the app from a parent process. I left nsIDocShell::appId alone, because changing that would have necessitated changing nsILoadGroup and therefore a /lot/ of users in Necko; it's also not clear it would have clarified anything in those cases.
2012-11-10 10:32:37 -08:00
|
|
|
|
2013-07-30 14:42:34 -07:00
|
|
|
#define NO_APP_ID (nsIScriptSecurityManager::NO_APP_ID)
|
|
|
|
|
Bug 802366 - The main event: Let a browser process inherit its app's id. r=bz,cjones
The main bug fixed here is that in half of our interfaces, we use "is browser frame/element" to mean "browser or app", and in the other half, we use it to mean "is browser not app".
There's a related, functional bug also fixed here, which is that a browser process doesn't inherit its parent's app-id. This causes problems e.g. for IndexedDB: If a browser inside an app uses IndexedDB, the DB should have the app's app-id.
I also modified Tab{Parent,Child} and nsFrameLoader to call "app" "ownOrContainingApp", to emphasize that we might have inherited the app from a parent process. I left nsIDocShell::appId alone, because changing that would have necessitated changing nsILoadGroup and therefore a /lot/ of users in Necko; it's also not clear it would have clarified anything in those cases.
2012-11-10 10:32:37 -08:00
|
|
|
using namespace mozilla::dom::ipc;
|
2012-11-27 12:43:52 -08:00
|
|
|
using namespace mozilla::layout;
|
Bug 802366 - The main event: Let a browser process inherit its app's id. r=bz,cjones
The main bug fixed here is that in half of our interfaces, we use "is browser frame/element" to mean "browser or app", and in the other half, we use it to mean "is browser not app".
There's a related, functional bug also fixed here, which is that a browser process doesn't inherit its parent's app-id. This causes problems e.g. for IndexedDB: If a browser inside an app uses IndexedDB, the DB should have the app's app-id.
I also modified Tab{Parent,Child} and nsFrameLoader to call "app" "ownOrContainingApp", to emphasize that we might have inherited the app from a parent process. I left nsIDocShell::appId alone, because changing that would have necessitated changing nsILoadGroup and therefore a /lot/ of users in Necko; it's also not clear it would have clarified anything in those cases.
2012-11-10 10:32:37 -08:00
|
|
|
|
|
|
|
namespace mozilla {
|
|
|
|
namespace dom {
|
|
|
|
|
|
|
|
TabContext::TabContext()
|
|
|
|
: mInitialized(false)
|
2013-07-30 14:42:34 -07:00
|
|
|
, mContainingAppId(NO_APP_ID)
|
2015-10-06 20:47:46 -07:00
|
|
|
, mOriginAttributes()
|
Bug 802366 - The main event: Let a browser process inherit its app's id. r=bz,cjones
The main bug fixed here is that in half of our interfaces, we use "is browser frame/element" to mean "browser or app", and in the other half, we use it to mean "is browser not app".
There's a related, functional bug also fixed here, which is that a browser process doesn't inherit its parent's app-id. This causes problems e.g. for IndexedDB: If a browser inside an app uses IndexedDB, the DB should have the app's app-id.
I also modified Tab{Parent,Child} and nsFrameLoader to call "app" "ownOrContainingApp", to emphasize that we might have inherited the app from a parent process. I left nsIDocShell::appId alone, because changing that would have necessitated changing nsILoadGroup and therefore a /lot/ of users in Necko; it's also not clear it would have clarified anything in those cases.
2012-11-10 10:32:37 -08:00
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
bool
|
|
|
|
TabContext::IsBrowserElement() const
|
|
|
|
{
|
2015-10-06 20:47:46 -07:00
|
|
|
return mOriginAttributes.mInBrowser;
|
Bug 802366 - The main event: Let a browser process inherit its app's id. r=bz,cjones
The main bug fixed here is that in half of our interfaces, we use "is browser frame/element" to mean "browser or app", and in the other half, we use it to mean "is browser not app".
There's a related, functional bug also fixed here, which is that a browser process doesn't inherit its parent's app-id. This causes problems e.g. for IndexedDB: If a browser inside an app uses IndexedDB, the DB should have the app's app-id.
I also modified Tab{Parent,Child} and nsFrameLoader to call "app" "ownOrContainingApp", to emphasize that we might have inherited the app from a parent process. I left nsIDocShell::appId alone, because changing that would have necessitated changing nsILoadGroup and therefore a /lot/ of users in Necko; it's also not clear it would have clarified anything in those cases.
2012-11-10 10:32:37 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
bool
|
|
|
|
TabContext::IsBrowserOrApp() const
|
|
|
|
{
|
|
|
|
return HasOwnApp() || IsBrowserElement();
|
|
|
|
}
|
|
|
|
|
|
|
|
uint32_t
|
|
|
|
TabContext::OwnAppId() const
|
|
|
|
{
|
2015-10-06 20:47:46 -07:00
|
|
|
return mOriginAttributes.mAppId;
|
Bug 802366 - The main event: Let a browser process inherit its app's id. r=bz,cjones
The main bug fixed here is that in half of our interfaces, we use "is browser frame/element" to mean "browser or app", and in the other half, we use it to mean "is browser not app".
There's a related, functional bug also fixed here, which is that a browser process doesn't inherit its parent's app-id. This causes problems e.g. for IndexedDB: If a browser inside an app uses IndexedDB, the DB should have the app's app-id.
I also modified Tab{Parent,Child} and nsFrameLoader to call "app" "ownOrContainingApp", to emphasize that we might have inherited the app from a parent process. I left nsIDocShell::appId alone, because changing that would have necessitated changing nsILoadGroup and therefore a /lot/ of users in Necko; it's also not clear it would have clarified anything in those cases.
2012-11-10 10:32:37 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
already_AddRefed<mozIApplication>
|
|
|
|
TabContext::GetOwnApp() const
|
|
|
|
{
|
2013-07-30 14:42:34 -07:00
|
|
|
nsCOMPtr<mozIApplication> ownApp = mOwnApp;
|
|
|
|
return ownApp.forget();
|
Bug 802366 - The main event: Let a browser process inherit its app's id. r=bz,cjones
The main bug fixed here is that in half of our interfaces, we use "is browser frame/element" to mean "browser or app", and in the other half, we use it to mean "is browser not app".
There's a related, functional bug also fixed here, which is that a browser process doesn't inherit its parent's app-id. This causes problems e.g. for IndexedDB: If a browser inside an app uses IndexedDB, the DB should have the app's app-id.
I also modified Tab{Parent,Child} and nsFrameLoader to call "app" "ownOrContainingApp", to emphasize that we might have inherited the app from a parent process. I left nsIDocShell::appId alone, because changing that would have necessitated changing nsILoadGroup and therefore a /lot/ of users in Necko; it's also not clear it would have clarified anything in those cases.
2012-11-10 10:32:37 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
bool
|
|
|
|
TabContext::HasOwnApp() const
|
|
|
|
{
|
2013-07-30 14:42:34 -07:00
|
|
|
nsCOMPtr<mozIApplication> ownApp = GetOwnApp();
|
|
|
|
return !!ownApp;
|
Bug 802366 - The main event: Let a browser process inherit its app's id. r=bz,cjones
The main bug fixed here is that in half of our interfaces, we use "is browser frame/element" to mean "browser or app", and in the other half, we use it to mean "is browser not app".
There's a related, functional bug also fixed here, which is that a browser process doesn't inherit its parent's app-id. This causes problems e.g. for IndexedDB: If a browser inside an app uses IndexedDB, the DB should have the app's app-id.
I also modified Tab{Parent,Child} and nsFrameLoader to call "app" "ownOrContainingApp", to emphasize that we might have inherited the app from a parent process. I left nsIDocShell::appId alone, because changing that would have necessitated changing nsILoadGroup and therefore a /lot/ of users in Necko; it's also not clear it would have clarified anything in those cases.
2012-11-10 10:32:37 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
uint32_t
|
|
|
|
TabContext::BrowserOwnerAppId() const
|
|
|
|
{
|
2013-07-30 14:42:34 -07:00
|
|
|
if (IsBrowserElement()) {
|
Bug 802366 - The main event: Let a browser process inherit its app's id. r=bz,cjones
The main bug fixed here is that in half of our interfaces, we use "is browser frame/element" to mean "browser or app", and in the other half, we use it to mean "is browser not app".
There's a related, functional bug also fixed here, which is that a browser process doesn't inherit its parent's app-id. This causes problems e.g. for IndexedDB: If a browser inside an app uses IndexedDB, the DB should have the app's app-id.
I also modified Tab{Parent,Child} and nsFrameLoader to call "app" "ownOrContainingApp", to emphasize that we might have inherited the app from a parent process. I left nsIDocShell::appId alone, because changing that would have necessitated changing nsILoadGroup and therefore a /lot/ of users in Necko; it's also not clear it would have clarified anything in those cases.
2012-11-10 10:32:37 -08:00
|
|
|
return mContainingAppId;
|
|
|
|
}
|
2013-07-30 14:42:34 -07:00
|
|
|
return NO_APP_ID;
|
Bug 802366 - The main event: Let a browser process inherit its app's id. r=bz,cjones
The main bug fixed here is that in half of our interfaces, we use "is browser frame/element" to mean "browser or app", and in the other half, we use it to mean "is browser not app".
There's a related, functional bug also fixed here, which is that a browser process doesn't inherit its parent's app-id. This causes problems e.g. for IndexedDB: If a browser inside an app uses IndexedDB, the DB should have the app's app-id.
I also modified Tab{Parent,Child} and nsFrameLoader to call "app" "ownOrContainingApp", to emphasize that we might have inherited the app from a parent process. I left nsIDocShell::appId alone, because changing that would have necessitated changing nsILoadGroup and therefore a /lot/ of users in Necko; it's also not clear it would have clarified anything in those cases.
2012-11-10 10:32:37 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
already_AddRefed<mozIApplication>
|
|
|
|
TabContext::GetBrowserOwnerApp() const
|
|
|
|
{
|
2013-07-30 14:42:34 -07:00
|
|
|
nsCOMPtr<mozIApplication> ownerApp;
|
|
|
|
if (IsBrowserElement()) {
|
|
|
|
ownerApp = mContainingApp;
|
|
|
|
}
|
|
|
|
return ownerApp.forget();
|
Bug 802366 - The main event: Let a browser process inherit its app's id. r=bz,cjones
The main bug fixed here is that in half of our interfaces, we use "is browser frame/element" to mean "browser or app", and in the other half, we use it to mean "is browser not app".
There's a related, functional bug also fixed here, which is that a browser process doesn't inherit its parent's app-id. This causes problems e.g. for IndexedDB: If a browser inside an app uses IndexedDB, the DB should have the app's app-id.
I also modified Tab{Parent,Child} and nsFrameLoader to call "app" "ownOrContainingApp", to emphasize that we might have inherited the app from a parent process. I left nsIDocShell::appId alone, because changing that would have necessitated changing nsILoadGroup and therefore a /lot/ of users in Necko; it's also not clear it would have clarified anything in those cases.
2012-11-10 10:32:37 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
bool
|
|
|
|
TabContext::HasBrowserOwnerApp() const
|
|
|
|
{
|
2013-07-30 14:42:34 -07:00
|
|
|
nsCOMPtr<mozIApplication> ownerApp = GetBrowserOwnerApp();
|
|
|
|
return !!ownerApp;
|
Bug 802366 - The main event: Let a browser process inherit its app's id. r=bz,cjones
The main bug fixed here is that in half of our interfaces, we use "is browser frame/element" to mean "browser or app", and in the other half, we use it to mean "is browser not app".
There's a related, functional bug also fixed here, which is that a browser process doesn't inherit its parent's app-id. This causes problems e.g. for IndexedDB: If a browser inside an app uses IndexedDB, the DB should have the app's app-id.
I also modified Tab{Parent,Child} and nsFrameLoader to call "app" "ownOrContainingApp", to emphasize that we might have inherited the app from a parent process. I left nsIDocShell::appId alone, because changing that would have necessitated changing nsILoadGroup and therefore a /lot/ of users in Necko; it's also not clear it would have clarified anything in those cases.
2012-11-10 10:32:37 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
uint32_t
|
|
|
|
TabContext::AppOwnerAppId() const
|
|
|
|
{
|
2013-07-30 14:42:34 -07:00
|
|
|
if (HasOwnApp()) {
|
Bug 802366 - The main event: Let a browser process inherit its app's id. r=bz,cjones
The main bug fixed here is that in half of our interfaces, we use "is browser frame/element" to mean "browser or app", and in the other half, we use it to mean "is browser not app".
There's a related, functional bug also fixed here, which is that a browser process doesn't inherit its parent's app-id. This causes problems e.g. for IndexedDB: If a browser inside an app uses IndexedDB, the DB should have the app's app-id.
I also modified Tab{Parent,Child} and nsFrameLoader to call "app" "ownOrContainingApp", to emphasize that we might have inherited the app from a parent process. I left nsIDocShell::appId alone, because changing that would have necessitated changing nsILoadGroup and therefore a /lot/ of users in Necko; it's also not clear it would have clarified anything in those cases.
2012-11-10 10:32:37 -08:00
|
|
|
return mContainingAppId;
|
|
|
|
}
|
2013-07-30 14:42:34 -07:00
|
|
|
return NO_APP_ID;
|
Bug 802366 - The main event: Let a browser process inherit its app's id. r=bz,cjones
The main bug fixed here is that in half of our interfaces, we use "is browser frame/element" to mean "browser or app", and in the other half, we use it to mean "is browser not app".
There's a related, functional bug also fixed here, which is that a browser process doesn't inherit its parent's app-id. This causes problems e.g. for IndexedDB: If a browser inside an app uses IndexedDB, the DB should have the app's app-id.
I also modified Tab{Parent,Child} and nsFrameLoader to call "app" "ownOrContainingApp", to emphasize that we might have inherited the app from a parent process. I left nsIDocShell::appId alone, because changing that would have necessitated changing nsILoadGroup and therefore a /lot/ of users in Necko; it's also not clear it would have clarified anything in those cases.
2012-11-10 10:32:37 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
already_AddRefed<mozIApplication>
|
|
|
|
TabContext::GetAppOwnerApp() const
|
|
|
|
{
|
2013-07-30 14:42:34 -07:00
|
|
|
nsCOMPtr<mozIApplication> ownerApp;
|
|
|
|
if (HasOwnApp()) {
|
|
|
|
ownerApp = mContainingApp;
|
|
|
|
}
|
|
|
|
return ownerApp.forget();
|
Bug 802366 - The main event: Let a browser process inherit its app's id. r=bz,cjones
The main bug fixed here is that in half of our interfaces, we use "is browser frame/element" to mean "browser or app", and in the other half, we use it to mean "is browser not app".
There's a related, functional bug also fixed here, which is that a browser process doesn't inherit its parent's app-id. This causes problems e.g. for IndexedDB: If a browser inside an app uses IndexedDB, the DB should have the app's app-id.
I also modified Tab{Parent,Child} and nsFrameLoader to call "app" "ownOrContainingApp", to emphasize that we might have inherited the app from a parent process. I left nsIDocShell::appId alone, because changing that would have necessitated changing nsILoadGroup and therefore a /lot/ of users in Necko; it's also not clear it would have clarified anything in those cases.
2012-11-10 10:32:37 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
bool
|
|
|
|
TabContext::HasAppOwnerApp() const
|
|
|
|
{
|
2013-07-30 14:42:34 -07:00
|
|
|
nsCOMPtr<mozIApplication> ownerApp = GetAppOwnerApp();
|
|
|
|
return !!ownerApp;
|
Bug 802366 - The main event: Let a browser process inherit its app's id. r=bz,cjones
The main bug fixed here is that in half of our interfaces, we use "is browser frame/element" to mean "browser or app", and in the other half, we use it to mean "is browser not app".
There's a related, functional bug also fixed here, which is that a browser process doesn't inherit its parent's app-id. This causes problems e.g. for IndexedDB: If a browser inside an app uses IndexedDB, the DB should have the app's app-id.
I also modified Tab{Parent,Child} and nsFrameLoader to call "app" "ownOrContainingApp", to emphasize that we might have inherited the app from a parent process. I left nsIDocShell::appId alone, because changing that would have necessitated changing nsILoadGroup and therefore a /lot/ of users in Necko; it's also not clear it would have clarified anything in those cases.
2012-11-10 10:32:37 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
uint32_t
|
|
|
|
TabContext::OwnOrContainingAppId() const
|
|
|
|
{
|
2013-07-30 14:42:34 -07:00
|
|
|
if (HasOwnApp()) {
|
2015-10-06 20:47:46 -07:00
|
|
|
return mOriginAttributes.mAppId;
|
Bug 802366 - The main event: Let a browser process inherit its app's id. r=bz,cjones
The main bug fixed here is that in half of our interfaces, we use "is browser frame/element" to mean "browser or app", and in the other half, we use it to mean "is browser not app".
There's a related, functional bug also fixed here, which is that a browser process doesn't inherit its parent's app-id. This causes problems e.g. for IndexedDB: If a browser inside an app uses IndexedDB, the DB should have the app's app-id.
I also modified Tab{Parent,Child} and nsFrameLoader to call "app" "ownOrContainingApp", to emphasize that we might have inherited the app from a parent process. I left nsIDocShell::appId alone, because changing that would have necessitated changing nsILoadGroup and therefore a /lot/ of users in Necko; it's also not clear it would have clarified anything in those cases.
2012-11-10 10:32:37 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
return mContainingAppId;
|
|
|
|
}
|
|
|
|
|
|
|
|
already_AddRefed<mozIApplication>
|
|
|
|
TabContext::GetOwnOrContainingApp() const
|
|
|
|
{
|
2013-07-30 14:42:34 -07:00
|
|
|
nsCOMPtr<mozIApplication> ownOrContainingApp;
|
|
|
|
if (HasOwnApp()) {
|
|
|
|
ownOrContainingApp = mOwnApp;
|
|
|
|
} else {
|
|
|
|
ownOrContainingApp = mContainingApp;
|
|
|
|
}
|
|
|
|
|
|
|
|
return ownOrContainingApp.forget();
|
Bug 802366 - The main event: Let a browser process inherit its app's id. r=bz,cjones
The main bug fixed here is that in half of our interfaces, we use "is browser frame/element" to mean "browser or app", and in the other half, we use it to mean "is browser not app".
There's a related, functional bug also fixed here, which is that a browser process doesn't inherit its parent's app-id. This causes problems e.g. for IndexedDB: If a browser inside an app uses IndexedDB, the DB should have the app's app-id.
I also modified Tab{Parent,Child} and nsFrameLoader to call "app" "ownOrContainingApp", to emphasize that we might have inherited the app from a parent process. I left nsIDocShell::appId alone, because changing that would have necessitated changing nsILoadGroup and therefore a /lot/ of users in Necko; it's also not clear it would have clarified anything in those cases.
2012-11-10 10:32:37 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
bool
|
|
|
|
TabContext::HasOwnOrContainingApp() const
|
|
|
|
{
|
2013-07-30 14:42:34 -07:00
|
|
|
nsCOMPtr<mozIApplication> ownOrContainingApp = GetOwnOrContainingApp();
|
|
|
|
return !!ownOrContainingApp;
|
Bug 802366 - The main event: Let a browser process inherit its app's id. r=bz,cjones
The main bug fixed here is that in half of our interfaces, we use "is browser frame/element" to mean "browser or app", and in the other half, we use it to mean "is browser not app".
There's a related, functional bug also fixed here, which is that a browser process doesn't inherit its parent's app-id. This causes problems e.g. for IndexedDB: If a browser inside an app uses IndexedDB, the DB should have the app's app-id.
I also modified Tab{Parent,Child} and nsFrameLoader to call "app" "ownOrContainingApp", to emphasize that we might have inherited the app from a parent process. I left nsIDocShell::appId alone, because changing that would have necessitated changing nsILoadGroup and therefore a /lot/ of users in Necko; it's also not clear it would have clarified anything in those cases.
2012-11-10 10:32:37 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
bool
|
|
|
|
TabContext::SetTabContext(const TabContext& aContext)
|
|
|
|
{
|
|
|
|
NS_ENSURE_FALSE(mInitialized, false);
|
|
|
|
|
2013-07-30 14:42:34 -07:00
|
|
|
*this = aContext;
|
2013-07-30 12:50:46 -07:00
|
|
|
mInitialized = true;
|
2013-07-30 14:42:34 -07:00
|
|
|
|
Bug 802366 - The main event: Let a browser process inherit its app's id. r=bz,cjones
The main bug fixed here is that in half of our interfaces, we use "is browser frame/element" to mean "browser or app", and in the other half, we use it to mean "is browser not app".
There's a related, functional bug also fixed here, which is that a browser process doesn't inherit its parent's app-id. This causes problems e.g. for IndexedDB: If a browser inside an app uses IndexedDB, the DB should have the app's app-id.
I also modified Tab{Parent,Child} and nsFrameLoader to call "app" "ownOrContainingApp", to emphasize that we might have inherited the app from a parent process. I left nsIDocShell::appId alone, because changing that would have necessitated changing nsILoadGroup and therefore a /lot/ of users in Necko; it's also not clear it would have clarified anything in those cases.
2012-11-10 10:32:37 -08:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2015-11-02 17:50:54 -08:00
|
|
|
const DocShellOriginAttributes&
|
2015-10-06 20:47:46 -07:00
|
|
|
TabContext::OriginAttributesRef() const
|
|
|
|
{
|
|
|
|
return mOriginAttributes;
|
|
|
|
}
|
|
|
|
|
2015-10-21 20:44:00 -07:00
|
|
|
const nsACString&
|
|
|
|
TabContext::SignedPkgOriginNoSuffix() const
|
|
|
|
{
|
|
|
|
return mSignedPkgOriginNoSuffix;
|
|
|
|
}
|
2015-10-06 20:47:46 -07:00
|
|
|
|
Bug 802366 - The main event: Let a browser process inherit its app's id. r=bz,cjones
The main bug fixed here is that in half of our interfaces, we use "is browser frame/element" to mean "browser or app", and in the other half, we use it to mean "is browser not app".
There's a related, functional bug also fixed here, which is that a browser process doesn't inherit its parent's app-id. This causes problems e.g. for IndexedDB: If a browser inside an app uses IndexedDB, the DB should have the app's app-id.
I also modified Tab{Parent,Child} and nsFrameLoader to call "app" "ownOrContainingApp", to emphasize that we might have inherited the app from a parent process. I left nsIDocShell::appId alone, because changing that would have necessitated changing nsILoadGroup and therefore a /lot/ of users in Necko; it's also not clear it would have clarified anything in those cases.
2012-11-10 10:32:37 -08:00
|
|
|
bool
|
2015-10-06 20:47:46 -07:00
|
|
|
TabContext::SetTabContext(mozIApplication* aOwnApp,
|
|
|
|
mozIApplication* aAppFrameOwnerApp,
|
2015-11-02 17:50:54 -08:00
|
|
|
const DocShellOriginAttributes& aOriginAttributes,
|
2015-10-21 20:44:00 -07:00
|
|
|
const nsACString& aSignedPkgOriginNoSuffix)
|
Bug 802366 - The main event: Let a browser process inherit its app's id. r=bz,cjones
The main bug fixed here is that in half of our interfaces, we use "is browser frame/element" to mean "browser or app", and in the other half, we use it to mean "is browser not app".
There's a related, functional bug also fixed here, which is that a browser process doesn't inherit its parent's app-id. This causes problems e.g. for IndexedDB: If a browser inside an app uses IndexedDB, the DB should have the app's app-id.
I also modified Tab{Parent,Child} and nsFrameLoader to call "app" "ownOrContainingApp", to emphasize that we might have inherited the app from a parent process. I left nsIDocShell::appId alone, because changing that would have necessitated changing nsILoadGroup and therefore a /lot/ of users in Necko; it's also not clear it would have clarified anything in those cases.
2012-11-10 10:32:37 -08:00
|
|
|
{
|
|
|
|
NS_ENSURE_FALSE(mInitialized, false);
|
|
|
|
|
|
|
|
// Get ids for both apps and only write to our member variables after we've
|
|
|
|
// verified that this worked.
|
2013-07-30 14:42:34 -07:00
|
|
|
uint32_t ownAppId = NO_APP_ID;
|
Bug 802366 - The main event: Let a browser process inherit its app's id. r=bz,cjones
The main bug fixed here is that in half of our interfaces, we use "is browser frame/element" to mean "browser or app", and in the other half, we use it to mean "is browser not app".
There's a related, functional bug also fixed here, which is that a browser process doesn't inherit its parent's app-id. This causes problems e.g. for IndexedDB: If a browser inside an app uses IndexedDB, the DB should have the app's app-id.
I also modified Tab{Parent,Child} and nsFrameLoader to call "app" "ownOrContainingApp", to emphasize that we might have inherited the app from a parent process. I left nsIDocShell::appId alone, because changing that would have necessitated changing nsILoadGroup and therefore a /lot/ of users in Necko; it's also not clear it would have clarified anything in those cases.
2012-11-10 10:32:37 -08:00
|
|
|
if (aOwnApp) {
|
|
|
|
nsresult rv = aOwnApp->GetLocalId(&ownAppId);
|
|
|
|
NS_ENSURE_SUCCESS(rv, false);
|
2013-07-30 14:42:34 -07:00
|
|
|
NS_ENSURE_TRUE(ownAppId != NO_APP_ID, false);
|
Bug 802366 - The main event: Let a browser process inherit its app's id. r=bz,cjones
The main bug fixed here is that in half of our interfaces, we use "is browser frame/element" to mean "browser or app", and in the other half, we use it to mean "is browser not app".
There's a related, functional bug also fixed here, which is that a browser process doesn't inherit its parent's app-id. This causes problems e.g. for IndexedDB: If a browser inside an app uses IndexedDB, the DB should have the app's app-id.
I also modified Tab{Parent,Child} and nsFrameLoader to call "app" "ownOrContainingApp", to emphasize that we might have inherited the app from a parent process. I left nsIDocShell::appId alone, because changing that would have necessitated changing nsILoadGroup and therefore a /lot/ of users in Necko; it's also not clear it would have clarified anything in those cases.
2012-11-10 10:32:37 -08:00
|
|
|
}
|
|
|
|
|
2013-07-30 14:42:34 -07:00
|
|
|
uint32_t containingAppId = NO_APP_ID;
|
Bug 802366 - The main event: Let a browser process inherit its app's id. r=bz,cjones
The main bug fixed here is that in half of our interfaces, we use "is browser frame/element" to mean "browser or app", and in the other half, we use it to mean "is browser not app".
There's a related, functional bug also fixed here, which is that a browser process doesn't inherit its parent's app-id. This causes problems e.g. for IndexedDB: If a browser inside an app uses IndexedDB, the DB should have the app's app-id.
I also modified Tab{Parent,Child} and nsFrameLoader to call "app" "ownOrContainingApp", to emphasize that we might have inherited the app from a parent process. I left nsIDocShell::appId alone, because changing that would have necessitated changing nsILoadGroup and therefore a /lot/ of users in Necko; it's also not clear it would have clarified anything in those cases.
2012-11-10 10:32:37 -08:00
|
|
|
if (aAppFrameOwnerApp) {
|
2014-02-19 09:10:07 -08:00
|
|
|
nsresult rv = aAppFrameOwnerApp->GetLocalId(&containingAppId);
|
Bug 802366 - The main event: Let a browser process inherit its app's id. r=bz,cjones
The main bug fixed here is that in half of our interfaces, we use "is browser frame/element" to mean "browser or app", and in the other half, we use it to mean "is browser not app".
There's a related, functional bug also fixed here, which is that a browser process doesn't inherit its parent's app-id. This causes problems e.g. for IndexedDB: If a browser inside an app uses IndexedDB, the DB should have the app's app-id.
I also modified Tab{Parent,Child} and nsFrameLoader to call "app" "ownOrContainingApp", to emphasize that we might have inherited the app from a parent process. I left nsIDocShell::appId alone, because changing that would have necessitated changing nsILoadGroup and therefore a /lot/ of users in Necko; it's also not clear it would have clarified anything in those cases.
2012-11-10 10:32:37 -08:00
|
|
|
NS_ENSURE_SUCCESS(rv, false);
|
2013-07-30 14:42:34 -07:00
|
|
|
NS_ENSURE_TRUE(containingAppId != NO_APP_ID, false);
|
Bug 802366 - The main event: Let a browser process inherit its app's id. r=bz,cjones
The main bug fixed here is that in half of our interfaces, we use "is browser frame/element" to mean "browser or app", and in the other half, we use it to mean "is browser not app".
There's a related, functional bug also fixed here, which is that a browser process doesn't inherit its parent's app-id. This causes problems e.g. for IndexedDB: If a browser inside an app uses IndexedDB, the DB should have the app's app-id.
I also modified Tab{Parent,Child} and nsFrameLoader to call "app" "ownOrContainingApp", to emphasize that we might have inherited the app from a parent process. I left nsIDocShell::appId alone, because changing that would have necessitated changing nsILoadGroup and therefore a /lot/ of users in Necko; it's also not clear it would have clarified anything in those cases.
2012-11-10 10:32:37 -08:00
|
|
|
}
|
|
|
|
|
2015-10-06 20:47:46 -07:00
|
|
|
// Veryify that app id matches mAppId passed in originAttributes
|
|
|
|
MOZ_RELEASE_ASSERT((aOwnApp && aOriginAttributes.mAppId == ownAppId) ||
|
|
|
|
(aAppFrameOwnerApp && aOriginAttributes.mAppId == containingAppId) ||
|
|
|
|
aOriginAttributes.mAppId == NO_APP_ID);
|
|
|
|
|
Bug 802366 - The main event: Let a browser process inherit its app's id. r=bz,cjones
The main bug fixed here is that in half of our interfaces, we use "is browser frame/element" to mean "browser or app", and in the other half, we use it to mean "is browser not app".
There's a related, functional bug also fixed here, which is that a browser process doesn't inherit its parent's app-id. This causes problems e.g. for IndexedDB: If a browser inside an app uses IndexedDB, the DB should have the app's app-id.
I also modified Tab{Parent,Child} and nsFrameLoader to call "app" "ownOrContainingApp", to emphasize that we might have inherited the app from a parent process. I left nsIDocShell::appId alone, because changing that would have necessitated changing nsILoadGroup and therefore a /lot/ of users in Necko; it's also not clear it would have clarified anything in those cases.
2012-11-10 10:32:37 -08:00
|
|
|
mInitialized = true;
|
2015-10-06 20:47:46 -07:00
|
|
|
mOriginAttributes = aOriginAttributes;
|
Bug 802366 - The main event: Let a browser process inherit its app's id. r=bz,cjones
The main bug fixed here is that in half of our interfaces, we use "is browser frame/element" to mean "browser or app", and in the other half, we use it to mean "is browser not app".
There's a related, functional bug also fixed here, which is that a browser process doesn't inherit its parent's app-id. This causes problems e.g. for IndexedDB: If a browser inside an app uses IndexedDB, the DB should have the app's app-id.
I also modified Tab{Parent,Child} and nsFrameLoader to call "app" "ownOrContainingApp", to emphasize that we might have inherited the app from a parent process. I left nsIDocShell::appId alone, because changing that would have necessitated changing nsILoadGroup and therefore a /lot/ of users in Necko; it's also not clear it would have clarified anything in those cases.
2012-11-10 10:32:37 -08:00
|
|
|
mContainingAppId = containingAppId;
|
2013-07-30 14:42:34 -07:00
|
|
|
mOwnApp = aOwnApp;
|
|
|
|
mContainingApp = aAppFrameOwnerApp;
|
2015-10-21 20:44:00 -07:00
|
|
|
mSignedPkgOriginNoSuffix = aSignedPkgOriginNoSuffix;
|
Bug 802366 - The main event: Let a browser process inherit its app's id. r=bz,cjones
The main bug fixed here is that in half of our interfaces, we use "is browser frame/element" to mean "browser or app", and in the other half, we use it to mean "is browser not app".
There's a related, functional bug also fixed here, which is that a browser process doesn't inherit its parent's app-id. This causes problems e.g. for IndexedDB: If a browser inside an app uses IndexedDB, the DB should have the app's app-id.
I also modified Tab{Parent,Child} and nsFrameLoader to call "app" "ownOrContainingApp", to emphasize that we might have inherited the app from a parent process. I left nsIDocShell::appId alone, because changing that would have necessitated changing nsILoadGroup and therefore a /lot/ of users in Necko; it's also not clear it would have clarified anything in those cases.
2012-11-10 10:32:37 -08:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
IPCTabContext
|
|
|
|
TabContext::AsIPCTabContext() const
|
|
|
|
{
|
2015-10-06 20:47:46 -07:00
|
|
|
nsAutoCString originSuffix;
|
|
|
|
mOriginAttributes.CreateSuffix(originSuffix);
|
2015-10-21 20:44:00 -07:00
|
|
|
return IPCTabContext(FrameIPCTabContext(originSuffix,
|
|
|
|
mContainingAppId,
|
|
|
|
mSignedPkgOriginNoSuffix));
|
Bug 802366 - The main event: Let a browser process inherit its app's id. r=bz,cjones
The main bug fixed here is that in half of our interfaces, we use "is browser frame/element" to mean "browser or app", and in the other half, we use it to mean "is browser not app".
There's a related, functional bug also fixed here, which is that a browser process doesn't inherit its parent's app-id. This causes problems e.g. for IndexedDB: If a browser inside an app uses IndexedDB, the DB should have the app's app-id.
I also modified Tab{Parent,Child} and nsFrameLoader to call "app" "ownOrContainingApp", to emphasize that we might have inherited the app from a parent process. I left nsIDocShell::appId alone, because changing that would have necessitated changing nsILoadGroup and therefore a /lot/ of users in Necko; it's also not clear it would have clarified anything in those cases.
2012-11-10 10:32:37 -08:00
|
|
|
}
|
|
|
|
|
2013-07-30 14:42:34 -07:00
|
|
|
static already_AddRefed<mozIApplication>
|
|
|
|
GetAppForId(uint32_t aAppId)
|
2013-07-30 11:51:44 -07:00
|
|
|
{
|
2013-07-30 14:42:34 -07:00
|
|
|
nsCOMPtr<nsIAppsService> appsService = do_GetService(APPS_SERVICE_CONTRACTID);
|
|
|
|
NS_ENSURE_TRUE(appsService, nullptr);
|
2013-07-30 11:51:44 -07:00
|
|
|
|
2013-10-08 15:52:26 -07:00
|
|
|
nsCOMPtr<mozIApplication> app;
|
|
|
|
appsService->GetAppByLocalId(aAppId, getter_AddRefs(app));
|
2013-07-30 14:42:34 -07:00
|
|
|
|
|
|
|
return app.forget();
|
|
|
|
}
|
|
|
|
|
|
|
|
MaybeInvalidTabContext::MaybeInvalidTabContext(const IPCTabContext& aParams)
|
|
|
|
: mInvalidReason(nullptr)
|
|
|
|
{
|
|
|
|
uint32_t containingAppId = NO_APP_ID;
|
2015-11-02 17:50:54 -08:00
|
|
|
DocShellOriginAttributes originAttributes;
|
2015-10-06 20:47:46 -07:00
|
|
|
nsAutoCString originSuffix;
|
2015-10-21 20:44:00 -07:00
|
|
|
nsAutoCString signedPkgOriginNoSuffix;
|
2013-07-30 14:42:34 -07:00
|
|
|
|
2015-10-29 16:30:57 -07:00
|
|
|
switch(aParams.type()) {
|
|
|
|
case IPCTabContext::TPopupIPCTabContext: {
|
|
|
|
const PopupIPCTabContext &ipcContext = aParams.get_PopupIPCTabContext();
|
2013-07-30 14:42:34 -07:00
|
|
|
|
|
|
|
TabContext *context;
|
2014-10-29 11:11:00 -07:00
|
|
|
if (ipcContext.opener().type() == PBrowserOrId::TPBrowserParent) {
|
2015-02-05 13:47:32 -08:00
|
|
|
context = TabParent::GetFrom(ipcContext.opener().get_PBrowserParent());
|
2013-07-30 14:42:34 -07:00
|
|
|
if (context->IsBrowserElement() && !ipcContext.isBrowserElement()) {
|
|
|
|
// If the TabParent corresponds to a browser element, then it can only
|
|
|
|
// open other browser elements, for security reasons. We should have
|
|
|
|
// checked this before calling the TabContext constructor, so this is
|
|
|
|
// a fatal error.
|
|
|
|
mInvalidReason = "Child is-browser process tried to "
|
|
|
|
"open a non-browser tab.";
|
|
|
|
return;
|
|
|
|
}
|
2014-10-29 11:11:00 -07:00
|
|
|
} else if (ipcContext.opener().type() == PBrowserOrId::TPBrowserChild) {
|
|
|
|
context = static_cast<TabChild*>(ipcContext.opener().get_PBrowserChild());
|
|
|
|
} else if (ipcContext.opener().type() == PBrowserOrId::TTabId) {
|
|
|
|
// We should never get here because this PopupIPCTabContext is only
|
|
|
|
// used for allocating a new tab id, not for allocating a PBrowser.
|
|
|
|
mInvalidReason = "Child process tried to open an tab without the opener information.";
|
|
|
|
return;
|
2013-07-30 14:42:34 -07:00
|
|
|
} else {
|
|
|
|
// This should be unreachable because PopupIPCTabContext::opener is not a
|
|
|
|
// nullable field.
|
|
|
|
mInvalidReason = "PopupIPCTabContext::opener was null (?!).";
|
|
|
|
return;
|
|
|
|
}
|
2013-07-30 11:51:44 -07:00
|
|
|
|
2013-07-30 14:42:34 -07:00
|
|
|
// Browser elements can't nest other browser elements. So if
|
|
|
|
// our opener is browser element, we must be a new DOM window
|
|
|
|
// opened by it. In that case we inherit our containing app ID
|
|
|
|
// (if any).
|
|
|
|
//
|
|
|
|
// Otherwise, we're a new app window and we inherit from our
|
|
|
|
// opener app.
|
2015-10-06 20:47:46 -07:00
|
|
|
originAttributes = context->mOriginAttributes;
|
2013-07-30 14:42:34 -07:00
|
|
|
if (ipcContext.isBrowserElement()) {
|
|
|
|
containingAppId = context->OwnOrContainingAppId();
|
|
|
|
} else {
|
|
|
|
containingAppId = context->mContainingAppId;
|
|
|
|
}
|
|
|
|
break;
|
2013-07-30 12:50:46 -07:00
|
|
|
}
|
2015-10-29 16:30:57 -07:00
|
|
|
case IPCTabContext::TFrameIPCTabContext: {
|
2015-10-06 20:47:46 -07:00
|
|
|
const FrameIPCTabContext &ipcContext =
|
2015-10-29 16:30:57 -07:00
|
|
|
aParams.get_FrameIPCTabContext();
|
2013-07-30 14:42:34 -07:00
|
|
|
|
2015-10-06 20:47:46 -07:00
|
|
|
containingAppId = ipcContext.frameOwnerAppId();
|
2015-10-21 20:44:00 -07:00
|
|
|
signedPkgOriginNoSuffix = ipcContext.signedPkgOriginNoSuffix();
|
2015-10-06 20:47:46 -07:00
|
|
|
originSuffix = ipcContext.originSuffix();
|
|
|
|
originAttributes.PopulateFromSuffix(originSuffix);
|
2013-07-30 14:42:34 -07:00
|
|
|
break;
|
|
|
|
}
|
2015-10-29 16:30:57 -07:00
|
|
|
case IPCTabContext::TUnsafeIPCTabContext: {
|
|
|
|
// XXXcatalinb: This used *only* by ServiceWorkerClients::OpenWindow.
|
|
|
|
// It is meant as a temporary solution until service workers can
|
|
|
|
// provide a TabChild equivalent. Don't allow this on b2g since
|
|
|
|
// it might be used to escalate privileges.
|
|
|
|
#ifdef MOZ_B2G
|
|
|
|
mInvalidReason = "ServiceWorkerClients::OpenWindow is not supported.";
|
|
|
|
return;
|
|
|
|
#endif
|
|
|
|
if (!Preferences::GetBool("dom.serviceWorkers.enabled", false)) {
|
|
|
|
mInvalidReason = "ServiceWorkers should be enabled.";
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
containingAppId = NO_APP_ID;
|
|
|
|
break;
|
|
|
|
}
|
2013-07-30 14:42:34 -07:00
|
|
|
default: {
|
|
|
|
MOZ_CRASH();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-10-19 04:57:11 -07:00
|
|
|
nsCOMPtr<mozIApplication> ownApp;
|
|
|
|
if (!originAttributes.mInBrowser) {
|
|
|
|
// mAppId corresponds to OwnOrContainingAppId; if mInBrowser is
|
|
|
|
// false then it's ownApp otherwise it's containingApp
|
|
|
|
ownApp = GetAppForId(originAttributes.mAppId);
|
|
|
|
if ((ownApp == nullptr) != (originAttributes.mAppId == NO_APP_ID)) {
|
|
|
|
mInvalidReason = "Got an ownAppId that didn't correspond to an app.";
|
|
|
|
return;
|
|
|
|
}
|
2013-07-30 14:42:34 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
nsCOMPtr<mozIApplication> containingApp = GetAppForId(containingAppId);
|
|
|
|
if ((containingApp == nullptr) != (containingAppId == NO_APP_ID)) {
|
|
|
|
mInvalidReason = "Got a containingAppId that didn't correspond to an app.";
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool rv;
|
2015-10-06 20:47:46 -07:00
|
|
|
rv = mTabContext.SetTabContext(ownApp,
|
|
|
|
containingApp,
|
2015-10-21 20:44:00 -07:00
|
|
|
originAttributes,
|
|
|
|
signedPkgOriginNoSuffix);
|
2013-07-30 14:42:34 -07:00
|
|
|
if (!rv) {
|
|
|
|
mInvalidReason = "Couldn't initialize TabContext.";
|
2013-04-16 06:34:11 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-07-30 14:42:34 -07:00
|
|
|
bool
|
|
|
|
MaybeInvalidTabContext::IsValid()
|
2013-07-30 11:51:44 -07:00
|
|
|
{
|
2013-07-30 14:42:34 -07:00
|
|
|
return mInvalidReason == nullptr;
|
|
|
|
}
|
Bug 802366 - The main event: Let a browser process inherit its app's id. r=bz,cjones
The main bug fixed here is that in half of our interfaces, we use "is browser frame/element" to mean "browser or app", and in the other half, we use it to mean "is browser not app".
There's a related, functional bug also fixed here, which is that a browser process doesn't inherit its parent's app-id. This causes problems e.g. for IndexedDB: If a browser inside an app uses IndexedDB, the DB should have the app's app-id.
I also modified Tab{Parent,Child} and nsFrameLoader to call "app" "ownOrContainingApp", to emphasize that we might have inherited the app from a parent process. I left nsIDocShell::appId alone, because changing that would have necessitated changing nsILoadGroup and therefore a /lot/ of users in Necko; it's also not clear it would have clarified anything in those cases.
2012-11-10 10:32:37 -08:00
|
|
|
|
2013-07-30 14:42:34 -07:00
|
|
|
const char*
|
|
|
|
MaybeInvalidTabContext::GetInvalidReason()
|
|
|
|
{
|
|
|
|
return mInvalidReason;
|
|
|
|
}
|
2013-07-30 11:51:44 -07:00
|
|
|
|
2013-07-30 14:42:34 -07:00
|
|
|
const TabContext&
|
|
|
|
MaybeInvalidTabContext::GetTabContext()
|
|
|
|
{
|
|
|
|
if (!IsValid()) {
|
|
|
|
MOZ_CRASH("Can't GetTabContext() if !IsValid().");
|
|
|
|
}
|
|
|
|
|
|
|
|
return mTabContext;
|
Bug 802366 - The main event: Let a browser process inherit its app's id. r=bz,cjones
The main bug fixed here is that in half of our interfaces, we use "is browser frame/element" to mean "browser or app", and in the other half, we use it to mean "is browser not app".
There's a related, functional bug also fixed here, which is that a browser process doesn't inherit its parent's app-id. This causes problems e.g. for IndexedDB: If a browser inside an app uses IndexedDB, the DB should have the app's app-id.
I also modified Tab{Parent,Child} and nsFrameLoader to call "app" "ownOrContainingApp", to emphasize that we might have inherited the app from a parent process. I left nsIDocShell::appId alone, because changing that would have necessitated changing nsILoadGroup and therefore a /lot/ of users in Necko; it's also not clear it would have clarified anything in those cases.
2012-11-10 10:32:37 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
} // namespace dom
|
|
|
|
} // namespace mozilla
|