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 15:32:37 -04: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/. */
|
|
|
|
|
|
|
|
#ifndef mozilla_dom_TabContext_h
|
|
|
|
#define mozilla_dom_TabContext_h
|
|
|
|
|
2013-09-23 17:30:40 -04:00
|
|
|
#include "nsCOMPtr.h"
|
2015-10-07 11:47:46 +08:00
|
|
|
#include "mozilla/BasePrincipal.h"
|
2016-08-02 14:54:00 +02:00
|
|
|
#include "nsPIDOMWindow.h"
|
2016-06-09 07:59:31 -04:00
|
|
|
#include "nsPIWindowRoot.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
|
|
|
|
|
|
|
namespace mozilla {
|
|
|
|
namespace dom {
|
|
|
|
|
2014-06-18 17:57:51 -07:00
|
|
|
class IPCTabContext;
|
2013-09-23 17:30:40 -04: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
|
|
|
/**
|
2020-04-20 22:15:21 +00:00
|
|
|
* TabContext encapsulates information about an iframe.
|
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
|
|
|
*
|
2019-04-09 17:39:01 -05:00
|
|
|
* BrowserParent and BrowserChild both inherit from TabContext, and you can also
|
2019-04-09 16:38:15 -05:00
|
|
|
* have standalone TabContext objects.
|
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 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 14:42:34 -07: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 10:32:37 -08:00
|
|
|
|
|
|
|
/**
|
2016-10-14 21:46:26 -04:00
|
|
|
* Generates IPCTabContext of type BrowserFrameIPCTabContext from this
|
|
|
|
* TabContext's information.
|
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
|
|
|
*/
|
|
|
|
IPCTabContext AsIPCTabContext() const;
|
|
|
|
|
2017-05-29 12:38:46 +02:00
|
|
|
bool IsJSPlugin() const;
|
|
|
|
int32_t JSPluginId() const;
|
|
|
|
|
2018-07-10 22:31:55 -04:00
|
|
|
uint64_t ChromeOuterWindowID() const;
|
|
|
|
|
2016-05-17 11:10:59 +08:00
|
|
|
/**
|
|
|
|
* Returns the presentation URL associated with the tab if this tab is
|
|
|
|
* created for presented content
|
|
|
|
*/
|
|
|
|
const nsAString& PresentationURL() const;
|
|
|
|
|
2016-06-09 07:59:31 -04:00
|
|
|
UIStateChangeType ShowFocusRings() const;
|
|
|
|
|
2019-07-19 01:45:16 +03:00
|
|
|
uint32_t MaxTouchPoints() const { return mMaxTouchPoints; }
|
|
|
|
|
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
|
|
|
protected:
|
2013-07-30 14:42:34 -07: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 10:32:37 -08: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);
|
|
|
|
|
2020-04-20 22:15:21 +00:00
|
|
|
bool SetTabContext(uint64_t aChromeOuterWindowID,
|
2016-06-09 07:59:31 -04:00
|
|
|
UIStateChangeType aShowFocusRings,
|
2019-07-19 01:45:16 +03:00
|
|
|
const nsAString& aPresentationURL,
|
|
|
|
uint32_t aMaxTouchPoints);
|
2014-02-24 18:45:14 +13:00
|
|
|
|
2016-04-28 17:04:52 -05:00
|
|
|
/**
|
|
|
|
* Modify this TabContext to match the given TabContext. This is a special
|
|
|
|
* case triggered by nsFrameLoader::SwapWithOtherRemoteLoader which may have
|
|
|
|
* caused the owner content to change.
|
|
|
|
*
|
2020-04-20 22:15:21 +00:00
|
|
|
* This special case only allows the field `mChromeOuterWindowID` to be
|
2016-04-28 17:04:52 -05:00
|
|
|
* changed. If any other fields have changed, the update is ignored and
|
|
|
|
* returns false.
|
|
|
|
*/
|
|
|
|
bool UpdateTabContextAfterSwap(const TabContext& aContext);
|
|
|
|
|
2017-05-29 12:38:46 +02:00
|
|
|
/**
|
|
|
|
* Set this TabContext to be for a JS plugin. aPluginID is the id of the JS
|
|
|
|
* plugin
|
|
|
|
* (@see nsFakePlugin::mId).
|
|
|
|
* As with the other protected mutator methods, this lets you modify a
|
|
|
|
* TabContext once.
|
|
|
|
* (@see TabContext::SetTabContext above for more details).
|
|
|
|
*/
|
|
|
|
bool SetTabContextForJSPluginFrame(int32_t aJSPluginID);
|
|
|
|
|
2019-07-19 01:45:16 +03:00
|
|
|
void SetMaxTouchPoints(uint32_t aMaxTouchPoints) {
|
|
|
|
mMaxTouchPoints = aMaxTouchPoints;
|
|
|
|
}
|
|
|
|
|
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
|
|
|
private:
|
2013-04-16 15:34:11 +02:00
|
|
|
/**
|
2013-07-30 15:50:46 -04:00
|
|
|
* Has this TabContext been initialized? If so, mutator methods will fail.
|
|
|
|
*/
|
|
|
|
bool mInitialized;
|
|
|
|
|
2018-07-10 22:31:55 -04:00
|
|
|
/**
|
|
|
|
* The outerWindowID of the window hosting the remote frameloader.
|
|
|
|
*/
|
|
|
|
uint64_t mChromeOuterWindowID;
|
|
|
|
|
2017-05-29 12:38:46 +02:00
|
|
|
int32_t mJSPluginID;
|
|
|
|
|
2016-05-17 11:10:59 +08:00
|
|
|
/**
|
|
|
|
* The requested presentation URL.
|
|
|
|
*/
|
|
|
|
nsString mPresentationURL;
|
2016-06-09 07:59:31 -04:00
|
|
|
|
|
|
|
/**
|
2019-06-03 15:29:06 +00:00
|
|
|
* Keyboard indicator state (focus rings).
|
2016-06-09 07:59:31 -04:00
|
|
|
*/
|
|
|
|
UIStateChangeType mShowFocusRings;
|
2019-07-19 01:45:16 +03:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Maximum number of touch points.
|
|
|
|
*/
|
|
|
|
uint32_t mMaxTouchPoints;
|
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
|
|
|
* 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 10:32:37 -08:00
|
|
|
*/
|
|
|
|
class MutableTabContext : public TabContext {
|
|
|
|
public:
|
|
|
|
bool SetTabContext(const TabContext& aContext) {
|
|
|
|
return TabContext::SetTabContext(aContext);
|
|
|
|
}
|
|
|
|
|
2020-04-20 22:15:21 +00:00
|
|
|
bool SetTabContext(uint64_t aChromeOuterWindowID,
|
2016-06-09 07:59:31 -04:00
|
|
|
UIStateChangeType aShowFocusRings,
|
2019-07-19 01:45:16 +03:00
|
|
|
const nsAString& aPresentationURL,
|
|
|
|
uint32_t aMaxTouchPoints) {
|
2020-04-20 22:15:21 +00:00
|
|
|
return TabContext::SetTabContext(aChromeOuterWindowID, aShowFocusRings,
|
2020-05-07 22:18:54 +00:00
|
|
|
aPresentationURL, aMaxTouchPoints);
|
2014-02-24 18:45:14 +13:00
|
|
|
}
|
2017-05-29 12:38:46 +02:00
|
|
|
|
|
|
|
bool SetTabContextForJSPluginFrame(uint32_t aJSPluginID) {
|
|
|
|
return TabContext::SetTabContextForJSPluginFrame(aJSPluginID);
|
|
|
|
}
|
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
|
|
|
/**
|
|
|
|
* MaybeInvalidTabContext is a simple class that lets you transform an
|
|
|
|
* IPCTabContext into a TabContext.
|
|
|
|
*
|
2016-10-14 21:46:26 -04:00
|
|
|
* The issue is that an IPCTabContext is not necessarily valid. So to convert
|
|
|
|
* an IPCTabContext into a TabContext, you construct a MaybeInvalidTabContext,
|
|
|
|
* check whether it's valid, and, if so, read out your TabContext.
|
2013-07-30 14:42:34 -07:00
|
|
|
*
|
|
|
|
* 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 09:19:51 -04:00
|
|
|
explicit MaybeInvalidTabContext(const IPCTabContext& aContext);
|
2013-07-30 14:42:34 -07: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 18:35:02 -05:00
|
|
|
MaybeInvalidTabContext(const MaybeInvalidTabContext&) = delete;
|
|
|
|
MaybeInvalidTabContext& operator=(const MaybeInvalidTabContext&) = delete;
|
2013-07-30 14:42:34 -07: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 10:32:37 -08:00
|
|
|
} // namespace dom
|
|
|
|
} // namespace mozilla
|
|
|
|
|
|
|
|
#endif
|