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)
