This patch removes support for mozapp iframes, leaving support for
mozbrowser iframes intact. Some of the code has been rewritten in order
to phrase things in terms of mozbrowser only, as opposed to mozbrowser
or app. In some places, code that was only useful with apps has been
completely removed, so that the APIs consumed can also be removed. In
some places where the notion of appId was bleeding out of this API, now
we use NO_APP_ID. Other notions of appId which were restricted to this
API have been removed.
This patch removes support for mozapp iframes, leaving support for
mozbrowser iframes intact. Some of the code has been rewritten in order
to phrase things in terms of mozbrowser only, as opposed to mozbrowser
or app. In some places, code that was only useful with apps has been
completely removed, so that the APIs consumed can also be removed. In
some places where the notion of appId was bleeding out of this API, now
we use NO_APP_ID. Other notions of appId which were restricted to this
API have been removed.
When swapping content from <iframe mozbrowser> to <xul:browser>, we now stop the
frame scripts that implement the content side of the browser API since they are
no longer needed and can cause issues if they remain active.
MozReview-Commit-ID: JrecxA4MI93
Renames existing nsFrameLoader::OwnerIsBrowser* methods to add "Moz" prefix for
clarity.
Adds nsFrameLoader::OwnerIsIsolatedMozBrowserFrame which checks the noisolation
attribute of mozbrowser frames, if present.
This is used to set isolation in nsFrameLoader::GetNewTabContext only when true.
MozReview-Commit-ID: Dz02xBoKh1P
1. Add |ownerIsWidget| in nsIFrameLoader.idl
2. Add |GetReallyIsWidget| in nsIMozBrowserFrame.idl
3. Hide the methods of browser API of a widget
4. Hide security-sensitive mozbrowser events of a widget
1. Add permission |embed-widgets| and Element attribute |mozwidget|
2. Add |hasWidgetPage| in /mozIApplication.idl
3. Check permission |embed-widgets| and the |src| is in the |widgetPages| when |GetAppManifest|
4. Add test case
5. Should enable preference |dom.enable_widgets|
1. Add |ownerIsWidget| in nsIFrameLoader.idl
2. Add |GetReallyIsWidget| in nsIMozBrowserFrame.idl
3. Hide the methods of browser API of a widget
4. Hide security-sensitive mozbrowser events of a widget
1. Add permission |embed-widgets| and Element attribute |mozwidget|
2. Add |hasWidgetPage| in /mozIApplication.idl
3. Check permission |embed-widgets| and the |src| is in the |widgetPages| when |GetAppManifest|
4. Add test case
5. Should enable preference |dom.enable_widgets|
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.
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.
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.
(Re-landing changeset a6a847452dbf, backed out in 5091aa6083c4, because it was originally landed with the incorrect bug number.)
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.
