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 22:32:37 +04:00
|
|
|
/* -*- Mode: C++; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
|
2015-05-03 22:32:37 +03: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 22:32:37 +04: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-24 01:30:40 +04:00
|
|
|
#include "nsCOMPtr.h"
|
2015-10-07 06:47:46 +03:00
|
|
|
#include "mozilla/BasePrincipal.h"
|
2016-08-02 15:54:00 +03:00
|
|
|
#include "nsPIDOMWindow.h"
|
2016-06-09 14:59:31 +03: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 22:32:37 +04:00
|
|
|
|
|
|
|
namespace mozilla {
|
|
|
|
namespace dom {
|
|
|
|
|
2014-06-19 04:57:51 +04:00
|
|
|
class IPCTabContext;
|
2013-09-24 01: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 22:32:37 +04:00
|
|
|
/**
|
2016-10-15 04:46:26 +03:00
|
|
|
* TabContext encapsulates information about an iframe that may be a mozbrowser.
|
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 22:32:37 +04:00
|
|
|
*
|
|
|
|
* 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-31 01:42:34 +04: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 22:32:37 +04:00
|
|
|
|
|
|
|
/**
|
2016-10-15 04:46:26 +03: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 22:32:37 +04:00
|
|
|
*/
|
|
|
|
IPCTabContext AsIPCTabContext() const;
|
|
|
|
|
|
|
|
/**
|
2016-02-18 07:35:45 +03:00
|
|
|
* Does this TabContext correspond to a mozbrowser?
|
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 22:32:37 +04:00
|
|
|
*
|
2016-10-15 04:46:26 +03:00
|
|
|
* <iframe mozbrowser> is a mozbrowser element, but <xul:browser> is not.
|
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 22:32:37 +04:00
|
|
|
*/
|
2016-02-18 07:35:45 +03:00
|
|
|
bool IsMozBrowserElement() const;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Does this TabContext correspond to an isolated mozbrowser?
|
|
|
|
*
|
2016-10-15 04:46:26 +03:00
|
|
|
* <iframe mozbrowser> is a mozbrowser element, but <xul:browser> is not.
|
|
|
|
* <iframe mozbrowser noisolation> does not count as isolated since isolation
|
|
|
|
* is disabled. Isolation can only be disabled by chrome pages.
|
2016-02-18 07:35:45 +03:00
|
|
|
*/
|
|
|
|
bool IsIsolatedMozBrowserElement() const;
|
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 22:32:37 +04:00
|
|
|
|
|
|
|
/**
|
2016-10-15 04:46:26 +03:00
|
|
|
* Does this TabContext correspond to a mozbrowser? This is equivalent to
|
|
|
|
* IsMozBrowserElement(). Returns false for <xul:browser>, which isn't a
|
|
|
|
* mozbrowser.
|
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 22:32:37 +04:00
|
|
|
*/
|
2016-10-15 04:46:26 +03:00
|
|
|
bool IsMozBrowser() const;
|
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 22:32:37 +04:00
|
|
|
|
2015-10-07 06:47:46 +03:00
|
|
|
/**
|
2017-01-12 19:38:48 +03:00
|
|
|
* OriginAttributesRef() returns the OriginAttributes of this frame to
|
2016-01-05 12:59:30 +03:00
|
|
|
* the caller. This is used to store any attribute associated with the frame's
|
2016-10-15 04:46:26 +03:00
|
|
|
* docshell.
|
2015-10-07 06:47:46 +03:00
|
|
|
*/
|
2017-01-12 19:38:48 +03:00
|
|
|
const OriginAttributes& OriginAttributesRef() const;
|
2015-10-07 06:47:46 +03:00
|
|
|
|
2016-05-17 06:10:59 +03:00
|
|
|
/**
|
|
|
|
* Returns the presentation URL associated with the tab if this tab is
|
|
|
|
* created for presented content
|
|
|
|
*/
|
|
|
|
const nsAString& PresentationURL() const;
|
|
|
|
|
2016-06-09 14:59:31 +03:00
|
|
|
UIStateChangeType ShowAccelerators() const;
|
|
|
|
UIStateChangeType ShowFocusRings() const;
|
|
|
|
|
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 22:32:37 +04:00
|
|
|
protected:
|
2013-07-31 01:42:34 +04: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 22:32:37 +04: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);
|
|
|
|
|
2016-06-03 00:02:29 +03:00
|
|
|
/**
|
|
|
|
* Set the tab context's origin attributes to a private browsing value.
|
|
|
|
*/
|
|
|
|
void SetPrivateBrowsingAttributes(bool aIsPrivateBrowsing);
|
|
|
|
|
2016-02-18 07:35:45 +03:00
|
|
|
bool SetTabContext(bool aIsMozBrowserElement,
|
2016-05-20 06:36:27 +03:00
|
|
|
bool aIsPrerendered,
|
2016-06-09 14:59:31 +03:00
|
|
|
UIStateChangeType aShowAccelerators,
|
|
|
|
UIStateChangeType aShowFocusRings,
|
2017-01-12 19:38:48 +03:00
|
|
|
const OriginAttributes& aOriginAttributes,
|
2016-05-17 06:10:59 +03:00
|
|
|
const nsAString& aPresentationURL);
|
2014-02-24 09:45:14 +04:00
|
|
|
|
2016-04-29 01:04:52 +03: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.
|
|
|
|
*
|
|
|
|
* This special case only allows the field `mIsMozBrowserElement` to be
|
|
|
|
* changed. If any other fields have changed, the update is ignored and
|
|
|
|
* returns false.
|
|
|
|
*/
|
|
|
|
bool UpdateTabContextAfterSwap(const TabContext& aContext);
|
|
|
|
|
2016-05-20 06:36:27 +03:00
|
|
|
/**
|
|
|
|
* Whether this TabContext is in prerender mode.
|
|
|
|
*/
|
|
|
|
bool mIsPrerendered;
|
|
|
|
|
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 22:32:37 +04:00
|
|
|
private:
|
2013-04-16 17:34:11 +04:00
|
|
|
/**
|
2013-07-30 23:50:46 +04:00
|
|
|
* Has this TabContext been initialized? If so, mutator methods will fail.
|
|
|
|
*/
|
|
|
|
bool mInitialized;
|
|
|
|
|
2016-02-18 07:35:45 +03:00
|
|
|
/**
|
|
|
|
* Whether this TabContext corresponds to a mozbrowser.
|
|
|
|
*
|
2016-10-15 04:46:26 +03:00
|
|
|
* <iframe mozbrowser> and <xul:browser> are not considered to be
|
2016-02-18 07:35:45 +03:00
|
|
|
* mozbrowser elements.
|
|
|
|
*/
|
|
|
|
bool mIsMozBrowserElement;
|
|
|
|
|
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 22:32:37 +04:00
|
|
|
/**
|
2017-01-12 19:38:48 +03:00
|
|
|
* OriginAttributes of the top level tab docShell
|
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 22:32:37 +04:00
|
|
|
*/
|
2017-01-12 19:38:48 +03:00
|
|
|
OriginAttributes mOriginAttributes;
|
2015-10-07 06:47:46 +03:00
|
|
|
|
2016-05-17 06:10:59 +03:00
|
|
|
/**
|
|
|
|
* The requested presentation URL.
|
|
|
|
*/
|
|
|
|
nsString mPresentationURL;
|
2016-06-09 14:59:31 +03:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Keyboard indicator state (focus rings, accelerators).
|
|
|
|
*/
|
|
|
|
UIStateChangeType mShowAccelerators;
|
|
|
|
UIStateChangeType mShowFocusRings;
|
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 22:32:37 +04:00
|
|
|
};
|
|
|
|
|
|
|
|
/**
|
2013-07-31 01:42:34 +04: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 22:32:37 +04:00
|
|
|
*/
|
|
|
|
class MutableTabContext : public TabContext
|
|
|
|
{
|
|
|
|
public:
|
|
|
|
bool SetTabContext(const TabContext& aContext)
|
|
|
|
{
|
|
|
|
return TabContext::SetTabContext(aContext);
|
|
|
|
}
|
|
|
|
|
2016-01-05 12:59:30 +03:00
|
|
|
bool
|
2016-02-18 07:35:45 +03:00
|
|
|
SetTabContext(bool aIsMozBrowserElement,
|
2016-05-20 06:36:27 +03:00
|
|
|
bool aIsPrerendered,
|
2016-06-09 14:59:31 +03:00
|
|
|
UIStateChangeType aShowAccelerators,
|
|
|
|
UIStateChangeType aShowFocusRings,
|
2017-01-12 19:38:48 +03:00
|
|
|
const OriginAttributes& aOriginAttributes,
|
2016-05-17 06:10:59 +03:00
|
|
|
const nsAString& aPresentationURL = EmptyString())
|
2014-02-24 09:45:14 +04:00
|
|
|
{
|
2016-02-18 07:35:45 +03:00
|
|
|
return TabContext::SetTabContext(aIsMozBrowserElement,
|
2016-05-20 06:36:27 +03:00
|
|
|
aIsPrerendered,
|
2016-06-09 14:59:31 +03:00
|
|
|
aShowAccelerators,
|
|
|
|
aShowFocusRings,
|
2015-10-22 06:44:00 +03:00
|
|
|
aOriginAttributes,
|
2016-05-17 06:10:59 +03:00
|
|
|
aPresentationURL);
|
2014-02-24 09:45:14 +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 22:32:37 +04:00
|
|
|
};
|
|
|
|
|
2013-07-31 01:42:34 +04:00
|
|
|
/**
|
|
|
|
* MaybeInvalidTabContext is a simple class that lets you transform an
|
|
|
|
* IPCTabContext into a TabContext.
|
|
|
|
*
|
2016-10-15 04:46:26 +03: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-31 01:42:34 +04: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 17:19:51 +04:00
|
|
|
explicit MaybeInvalidTabContext(const IPCTabContext& aContext);
|
2013-07-31 01:42:34 +04: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-07 02:35:02 +03:00
|
|
|
MaybeInvalidTabContext(const MaybeInvalidTabContext&) = delete;
|
|
|
|
MaybeInvalidTabContext& operator=(const MaybeInvalidTabContext&) = delete;
|
2013-07-31 01:42:34 +04: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 22:32:37 +04:00
|
|
|
} // namespace dom
|
|
|
|
} // namespace mozilla
|
|
|
|
|
|
|
|
#endif
|