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 18:32:37 +00:00
|
|
|
/* -*- Mode: C++; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
|
|
|
|
/* vim: set sw=2 ts=8 et tw=80 : */
|
|
|
|
/* 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/. */
|
|
|
|
|
|
|
|
#ifndef mozilla_dom_TabContext_h
|
|
|
|
#define mozilla_dom_TabContext_h
|
|
|
|
|
|
|
|
#include "mozIApplication.h"
|
2013-09-23 21:30:40 +00:00
|
|
|
#include "nsCOMPtr.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 18:32:37 +00:00
|
|
|
|
|
|
|
namespace mozilla {
|
|
|
|
namespace dom {
|
|
|
|
|
2014-06-19 00:57:51 +00:00
|
|
|
class IPCTabContext;
|
2013-09-23 21:30:40 +00: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 18:32:37 +00:00
|
|
|
/**
|
|
|
|
* TabContext encapsulates information about an iframe that may be a mozbrowser
|
2013-04-09 17:12:15 +00:00
|
|
|
* or mozapp. You can ask whether a TabContext corresponds to a mozbrowser or
|
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 18:32:37 +00:00
|
|
|
* mozapp, get the app that contains the browser, and so on.
|
|
|
|
*
|
|
|
|
* TabParent and TabChild both inherit from TabContext, and you can also have
|
|
|
|
* standalone TabContext objects.
|
|
|
|
*
|
|
|
|
* This class is immutable except by calling one of the protected
|
|
|
|
* SetTabContext*() methods (and those methods can only be called once). See
|
|
|
|
* also MutableTabContext.
|
|
|
|
*/
|
|
|
|
class TabContext
|
|
|
|
{
|
|
|
|
public:
|
|
|
|
TabContext();
|
|
|
|
|
2013-07-30 21:42:34 +00:00
|
|
|
/* (The implicit copy-constructor and operator= are fine.) */
|
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 18:32:37 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Generates IPCTabContext of type BrowserFrameIPCTabContext or
|
|
|
|
* AppFrameIPCTabContext from this TabContext's information.
|
|
|
|
*/
|
|
|
|
IPCTabContext AsIPCTabContext() const;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Does this TabContext correspond to a mozbrowser? (<iframe mozbrowser
|
|
|
|
* mozapp> is not a browser.)
|
|
|
|
*
|
|
|
|
* If IsBrowserElement() is true, HasOwnApp() and HasAppOwnerApp() are
|
|
|
|
* guaranteed to be false.
|
|
|
|
*
|
|
|
|
* If IsBrowserElement() is false, HasBrowserOwnerApp() is guaranteed to be
|
|
|
|
* false.
|
|
|
|
*/
|
|
|
|
bool IsBrowserElement() const;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Does this TabContext correspond to a mozbrowser or mozapp? This is
|
|
|
|
* equivalent to IsBrowserElement() || HasOwnApp().
|
|
|
|
*/
|
|
|
|
bool IsBrowserOrApp() const;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* OwnAppId() returns the id of the app which directly corresponds to this
|
|
|
|
* context's frame. GetOwnApp() returns the corresponding app object, and
|
|
|
|
* HasOwnApp() returns true iff GetOwnApp() would return a non-null value.
|
|
|
|
*
|
|
|
|
* If HasOwnApp() is true, IsBrowserElement() is guaranteed to be false.
|
|
|
|
*/
|
|
|
|
uint32_t OwnAppId() const;
|
|
|
|
already_AddRefed<mozIApplication> GetOwnApp() const;
|
|
|
|
bool HasOwnApp() const;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* BrowserOwnerAppId() gets the ID of the app which contains this browser
|
|
|
|
* frame. If this is not a browser frame (i.e., if !IsBrowserElement()), then
|
|
|
|
* BrowserOwnerAppId() is guaranteed to return NO_APP_ID.
|
|
|
|
*
|
|
|
|
* Even if we are a browser frame, BrowserOwnerAppId() may still return
|
|
|
|
* NO_APP_ID, if this browser frame is not contained inside an app.
|
|
|
|
*/
|
|
|
|
uint32_t BrowserOwnerAppId() const;
|
|
|
|
already_AddRefed<mozIApplication> GetBrowserOwnerApp() const;
|
|
|
|
bool HasBrowserOwnerApp() const;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* AppOwnerAppId() gets the ID of the app which contains this app frame. If
|
|
|
|
* this is not an app frame (i.e., if !HasOwnApp()), then AppOwnerAppId() is
|
|
|
|
* guaranteed to return NO_APP_ID.
|
|
|
|
*
|
|
|
|
* Even if we are an app frame, AppOwnerAppId() may still return NO_APP_ID, if
|
|
|
|
* this app frame is not contained inside an app.
|
|
|
|
*/
|
|
|
|
uint32_t AppOwnerAppId() const;
|
|
|
|
already_AddRefed<mozIApplication> GetAppOwnerApp() const;
|
|
|
|
bool HasAppOwnerApp() const;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* OwnOrContainingAppId() gets the ID of this frame, if HasOwnApp(). If this
|
|
|
|
* frame does not have its own app, it gets the ID of the app which contains
|
|
|
|
* this frame (i.e., the result of {Browser,App}OwnerAppId(), as applicable).
|
|
|
|
*/
|
|
|
|
uint32_t OwnOrContainingAppId() const;
|
|
|
|
already_AddRefed<mozIApplication> GetOwnOrContainingApp() const;
|
|
|
|
bool HasOwnOrContainingApp() const;
|
|
|
|
|
|
|
|
protected:
|
2013-07-30 21:42:34 +00:00
|
|
|
friend class MaybeInvalidTabContext;
|
|
|
|
|
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 18:32:37 +00:00
|
|
|
/**
|
|
|
|
* These protected mutator methods let you modify a TabContext once. Further
|
|
|
|
* attempts to modify a given TabContext will fail (the method will return
|
|
|
|
* false).
|
|
|
|
*
|
|
|
|
* These mutators will also fail if the TabContext was created with anything
|
|
|
|
* other than the no-args constructor.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Set this TabContext to match the given TabContext.
|
|
|
|
*/
|
|
|
|
bool SetTabContext(const TabContext& aContext);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Set this TabContext to be an app frame (with the given own app) inside the
|
|
|
|
* given app. Either or both apps may be null.
|
|
|
|
*/
|
|
|
|
bool SetTabContextForAppFrame(mozIApplication* aOwnApp,
|
2015-02-26 13:47:01 +00:00
|
|
|
mozIApplication* aAppFrameOwnerApp);
|
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 18:32:37 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Set this TabContext to be a browser frame inside the given app (which may
|
|
|
|
* be null).
|
|
|
|
*/
|
2015-02-26 13:47:01 +00:00
|
|
|
bool SetTabContextForBrowserFrame(mozIApplication* aBrowserFrameOwnerApp);
|
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 18:32:37 +00:00
|
|
|
|
2014-02-24 05:45:14 +00:00
|
|
|
/**
|
|
|
|
* Set this TabContext to be a normal non-browser non-app frame.
|
|
|
|
*/
|
2015-02-26 13:47:01 +00:00
|
|
|
bool SetTabContextForNormalFrame();
|
2014-02-24 05:45:14 +00: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 18:32:37 +00:00
|
|
|
private:
|
2013-04-16 13:34:11 +00:00
|
|
|
/**
|
2013-07-30 19:50:46 +00:00
|
|
|
* Has this TabContext been initialized? If so, mutator methods will fail.
|
|
|
|
*/
|
|
|
|
bool mInitialized;
|
|
|
|
|
|
|
|
/**
|
2013-07-30 21:42:34 +00:00
|
|
|
* This TabContext's own app. If this is non-null, then this
|
|
|
|
* TabContext corresponds to an app, and mIsBrowser must be false.
|
2013-04-16 13:34:11 +00:00
|
|
|
*/
|
2013-07-30 21:42:34 +00:00
|
|
|
nsCOMPtr<mozIApplication> mOwnApp;
|
2013-04-16 13:34:11 +00: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 18:32:37 +00:00
|
|
|
/**
|
2013-07-30 21:42:34 +00:00
|
|
|
* A cache of mOwnApp->GetLocalId(). Speed really does matter here, since we
|
|
|
|
* read this ID often during process startup.
|
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 18:32:37 +00:00
|
|
|
*/
|
2013-07-30 21:42:34 +00:00
|
|
|
uint32_t mOwnAppId;
|
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 18:32:37 +00:00
|
|
|
|
2013-07-30 19:50:46 +00:00
|
|
|
/**
|
2013-07-30 21:42:34 +00:00
|
|
|
* This TabContext's containing app. If mIsBrowser, this corresponds to the
|
|
|
|
* app which contains the browser frame; otherwise, this corresponds to the
|
|
|
|
* app which contains the app frame.
|
2013-04-16 13:34:11 +00:00
|
|
|
*/
|
2013-07-30 21:42:34 +00:00
|
|
|
nsCOMPtr<mozIApplication> mContainingApp;
|
2013-04-16 13:34:11 +00:00
|
|
|
|
2013-07-30 21:42:34 +00:00
|
|
|
/*
|
|
|
|
* Cache of mContainingApp->GetLocalId().
|
2013-07-30 19:50:46 +00:00
|
|
|
*/
|
2013-07-30 21:42:34 +00:00
|
|
|
uint32_t mContainingAppId;
|
2013-07-30 19:50:46 +00: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 18:32:37 +00:00
|
|
|
/**
|
|
|
|
* Does this TabContext correspond to a browser element?
|
|
|
|
*
|
2013-07-30 21:42:34 +00:00
|
|
|
* If this is true, mOwnApp must be null.
|
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 18:32:37 +00:00
|
|
|
*/
|
|
|
|
bool mIsBrowser;
|
|
|
|
};
|
|
|
|
|
|
|
|
/**
|
2013-07-30 21:42:34 +00:00
|
|
|
* MutableTabContext is the same as MaybeInvalidTabContext, except the mutation
|
|
|
|
* methods are public instead of protected. You can still only call these
|
|
|
|
* mutation methods once on a given object.
|
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 18:32:37 +00:00
|
|
|
*/
|
|
|
|
class MutableTabContext : public TabContext
|
|
|
|
{
|
|
|
|
public:
|
|
|
|
bool SetTabContext(const TabContext& aContext)
|
|
|
|
{
|
|
|
|
return TabContext::SetTabContext(aContext);
|
|
|
|
}
|
|
|
|
|
2015-02-26 13:47:01 +00:00
|
|
|
bool SetTabContextForAppFrame(mozIApplication* aOwnApp,
|
|
|
|
mozIApplication* aAppFrameOwnerApp)
|
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 18:32:37 +00:00
|
|
|
{
|
2015-02-26 13:47:01 +00:00
|
|
|
return TabContext::SetTabContextForAppFrame(aOwnApp, aAppFrameOwnerApp);
|
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 18:32:37 +00:00
|
|
|
}
|
|
|
|
|
2015-02-26 13:47:01 +00:00
|
|
|
bool SetTabContextForBrowserFrame(mozIApplication* aBrowserFrameOwnerApp)
|
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 18:32:37 +00:00
|
|
|
{
|
2015-02-26 13:47:01 +00:00
|
|
|
return TabContext::SetTabContextForBrowserFrame(aBrowserFrameOwnerApp);
|
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 18:32:37 +00:00
|
|
|
}
|
2014-02-24 05:45:14 +00:00
|
|
|
|
2015-02-26 13:47:01 +00:00
|
|
|
bool SetTabContextForNormalFrame()
|
2014-02-24 05:45:14 +00:00
|
|
|
{
|
2015-02-26 13:47:01 +00:00
|
|
|
return TabContext::SetTabContextForNormalFrame();
|
2014-02-24 05:45:14 +00: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 18:32:37 +00:00
|
|
|
};
|
|
|
|
|
2013-07-30 21:42:34 +00:00
|
|
|
/**
|
|
|
|
* MaybeInvalidTabContext is a simple class that lets you transform an
|
|
|
|
* IPCTabContext into a TabContext.
|
|
|
|
*
|
|
|
|
* The issue is that an IPCTabContext is not necessarily valid; for example, it
|
|
|
|
* might specify an app-id which doesn't exist. So to convert an IPCTabContext
|
|
|
|
* into a TabContext, you construct a MaybeInvalidTabContext, check whether it's
|
|
|
|
* valid, and, if so, read out your TabContext.
|
|
|
|
*
|
|
|
|
* Example usage:
|
|
|
|
*
|
|
|
|
* void UseTabContext(const TabContext& aTabContext);
|
|
|
|
*
|
|
|
|
* void CreateTab(const IPCTabContext& aContext) {
|
|
|
|
* MaybeInvalidTabContext tc(aContext);
|
|
|
|
* if (!tc.IsValid()) {
|
|
|
|
* NS_ERROR(nsPrintfCString("Got an invalid IPCTabContext: %s",
|
|
|
|
* tc.GetInvalidReason()));
|
|
|
|
* return;
|
|
|
|
* }
|
|
|
|
* UseTabContext(tc.GetTabContext());
|
|
|
|
* }
|
|
|
|
*/
|
|
|
|
class MaybeInvalidTabContext
|
|
|
|
{
|
|
|
|
public:
|
|
|
|
/**
|
|
|
|
* This constructor copies the information in aContext and sets IsValid() as
|
|
|
|
* appropriate.
|
|
|
|
*/
|
2014-08-05 13:19:51 +00:00
|
|
|
explicit MaybeInvalidTabContext(const IPCTabContext& aContext);
|
2013-07-30 21:42:34 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Was the IPCTabContext we received in our constructor valid?
|
|
|
|
*/
|
|
|
|
bool IsValid();
|
|
|
|
|
|
|
|
/**
|
|
|
|
* If IsValid(), this function returns null. Otherwise, it returns a
|
|
|
|
* human-readable string indicating why the IPCTabContext passed to our
|
|
|
|
* constructor was not valid.
|
|
|
|
*/
|
|
|
|
const char* GetInvalidReason();
|
|
|
|
|
|
|
|
/**
|
|
|
|
* If IsValid(), this function returns a reference to a TabContext
|
|
|
|
* corresponding to the IPCTabContext passed to our constructor. If
|
|
|
|
* !IsValid(), this function crashes.
|
|
|
|
*/
|
|
|
|
const TabContext& GetTabContext();
|
|
|
|
|
|
|
|
private:
|
2015-01-06 23:35:02 +00:00
|
|
|
MaybeInvalidTabContext(const MaybeInvalidTabContext&) = delete;
|
|
|
|
MaybeInvalidTabContext& operator=(const MaybeInvalidTabContext&) = delete;
|
2013-07-30 21:42:34 +00:00
|
|
|
|
|
|
|
const char* mInvalidReason;
|
|
|
|
MutableTabContext 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 18:32:37 +00:00
|
|
|
} // namespace dom
|
|
|
|
} // namespace mozilla
|
|
|
|
|
|
|
|
#endif
|