This was autogenerated by basically replacing all occurrences of the word "nsIView" with nsView.
--HG--
rename : view/public/nsIView.h => view/public/nsView.h
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.
--HG--
extra : rebase_source : f3ef9475e21204da10bf39c6cca506bc08096949
This change means we no longer have to keep around a set of XPConnect compartments.
We keep the compartment private around for non-xpconnecty stuff like about:memory
instrumentation that needs to happen on non-xpconnect compartments.
An alternative implementation strategy is to add "default-only"
versions of ResolveStyleFor and ResolvePseudoElementStyle and then
modify FileRules to support those, or use a cut-down custom version of
FileRules for them. That would be faster, but more complicated on the
style set side. We can always make that switch if we need to, I guess.
Another, more risky, option would be to always return a declaration
from getComputedStyle, even if we have no presshell, then just throw
(after flushing, as needed) if people try to get style info for it
just like we already do for declarations whose document loses a
presshell. This might cause compat issues on sites that can deal with
null but not exceptions, though. :(
The assertion encountered is:
Assertion failure: !gAppContentParents || !gAppContentParents->Get(mAppManifestURL), at ../../../dom/ipc/ContentParent.cpp:774
TEST-UNEXPECTED-FAIL | /tests/dom/browser-element/mochitest/test_browserElement_oop_CloseFromOpener.html | Exited with code 11 during test run
PROCESS-CRASH | /tests/dom/browser-element/mochitest/test_browserElement_oop_CloseFromOpener.html | application crashed (minidump found)
Thread 0 (crashed)
We currently set this for system globals and anything whose parent
chain leads to a system global. Maybe this was relevant before, but
with CPG this is just equivalent to asking whether the object is in
a system compartment. And the only place where we _check_ this bit
is immediately after checking for a system compartment, in
WrapperFactory. So AFAICT this can go away entirely.
WouldReuseInnerWindow also returns true if the new window is same-origin with
the old one about:blank document.
This condition exists in order to handle some sloppiness with respect to the
principals on initial about:blank documents. Chrome callers sometimes parent
chrome windows (with XUL document) to content windows. But this parenting causes
us to push the cx of the content window during window creation, meaning that
the subsequent load of chrome://foo.xul blows away the old inner window and any
expandos on it. We can handle this case more precisely by skipping the cx push
for type="chrome" windows.
Furthermore, this was also necessary to prevent the inner window from being
blown away in the call to SetOpenerScriptPrincipal once nsWindowWatcher gets
the window back from the window creator (and after it's already told consumers
about the window via "domwindowcreated"). But we fixed this nastiness in the
previous patches.
So we can remove this case. By doing so, we can prevent inner windows from ever
changing origins, which is very important for compartment security invariants.
There's no reason it has to fail if there's no mDoc, since any document is promptly
blown away with the new about:blank document.
The indempotence is important because we want to be able to call this method
unconditionally in OpenJSWindowInternal (since we may not have gone through
RegisterTopLevelWindow) without worrying about whether we've called it already.
We can remove the fallback to the principal of aParent because we already push the
cx for aParent (callerContextGuard) whenever we're concerned about using its principal.
This doesn't change any functionality in the code. Note that the name is currently
a bit of a misnomer, but we change that in the next patch when we rip out the
arguments.
This patch actually converts over most of the existing native CC classes
to use the participant. This is done by converting them to use
the newly generalized nsCycleCollectingAutoRefCnt instead of their usual
ref count.
This is mostly a matter of defining new macros defining AddRef() and Release()
for native CC classes with the CC ref count.
nsTimeout is left as a legacy native CC class because it is a weird class,
but hopefully eventually it too can be converted over. See bug 774874.
We currently set this for system globals and anything whose parent
chain leads to a system global. Maybe this was relevant before, but
with CPG this is just equivalent to asking whether the object is in
a system compartment. And the only place where we _check_ this bit
is immediately after checking for a system compartment, in
WrapperFactory. So AFAICT this can go away entirely.
WouldReuseInnerWindow also returns true if the new window is same-origin with
the old one about:blank document.
This condition exists in order to handle some sloppiness with respect to the
principals on initial about:blank documents. Chrome callers sometimes parent
chrome windows (with XUL document) to content windows. But this parenting causes
us to push the cx of the content window during window creation, meaning that
the subsequent load of chrome://foo.xul blows away the old inner window and any
expandos on it. We can handle this case more precisely by skipping the cx push
for type="chrome" windows.
Furthermore, this was also necessary to prevent the inner window from being
blown away in the call to SetOpenerScriptPrincipal once nsWindowWatcher gets
the window back from the window creator (and after it's already told consumers
about the window via "domwindowcreated"). But we fixed this nastiness in the
previous patches.
So we can remove this case. By doing so, we can prevent inner windows from ever
changing origins, which is very important for compartment security invariants.
There's no reason it has to fail if there's no mDoc, since any document is promptly
blown away with the new about:blank document.
The indempotence is important because we want to be able to call this method
unconditionally in OpenJSWindowInternal (since we may not have gone through
RegisterTopLevelWindow) without worrying about whether we've called it already.
We can remove the fallback to the principal of aParent because we already push the
cx for aParent (callerContextGuard) whenever we're concerned about using its principal.
This doesn't change any functionality in the code. Note that the name is currently
a bit of a misnomer, but we change that in the next patch when we rip out the
arguments.
