Commit Graph

10 Commits

Author SHA1 Message Date
Jon Hylands
03f093b739 Bug 853632 - Cache own and containing apps in TabContext. r=jlebar 2013-04-16 15:34:11 +02:00
Chris Jones
c8d7986f0f Backed out d2aa085d7ebd (bug 836605) 2013-02-06 15:49:27 -08:00
Chris Jones
005dbdc107 Bug 836605: Cache mozIApplication wherever possible on critical startup path. r=jlebar 2013-02-06 14:32:20 -08:00
Chris Jones
462d7c3ac7 Backed out changeset fed128eb92f3 (bug 836605) for making the IDL gods angry. CLOSED TREE 2013-02-06 14:57:14 -08:00
Chris Jones
d6ba6c755b Bug 836605: Cache mozIApplication wherever possible on critical startup path. r=jlebar 2013-02-06 14:32:20 -08:00
Chris Jones
ab6daae23f Bug 824177: Opened windows of browsers inherit their containing app. r=jlebar 2012-12-27 15:43:22 -08:00
Chris Jones
a22bfed41d Bug 811315: Use process-per-mozbrowser by default and make scrolling behavior selectable by content. r=jlebar sr=roc
This is a rollup of the following patches

Bug 811315, part 0.9: Fix pre-existing race condition that allows dying ContentParents to accidentally try to load new TabParents. r=jlebar

Bug 811315, part 0.91: Fix another pre-existing race condition where FirstIdle might run after ContentChild::ActorDestroy(). r=jlebar

Bug 811315, part 1: Make "browser" process limit infinite and unload the processes when all tabs are closed.  Firefox with process-per-tab!  r=jlebar

Bug 811315, part 2: Pass scrolling-behavior hint down into TabParent instead of inferring it from app/browser. r=jlebar

Bug 811315, part 3: Add a mozasyncpanzoom attribute for iframes and honor it when constructing a remote frame. r=jlebar sr=roc
2012-11-27 12:43:52 -08:00
Justin Lebar
8c64b0474c 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
Ryan VanderMeulen
f774dcd8ba Backed out 12 changesets (bug 806127, bug 802366, bug 806168) for Windows build bustage.
--HG--
rename : dom/indexedDB/test/webapp_clearBrowserData.js => dom/indexedDB/test/test_webapp_clearBrowserData.html
2012-11-09 20:14:40 -05:00
Justin Lebar
19b287d268 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-09 16:37:39 -08:00