Commit Graph

21 Commits

Author SHA1 Message Date
Kershaw Chang
f4a1dbc4c1 Bug 1020172 - Patch 2: Manage TabParent in chrome process - v14. r=khuey 2014-10-29 19:11:00 +01:00
Wes Kocher
a7b71b864a Backed out 4 changesets (bug 1020172) for causing bug 1089542 a=backout
Backed out changeset 176ca4363517 (bug 1020172)
Backed out changeset 90714be8e689 (bug 1020172)
Backed out changeset 9d8c09e711f5 (bug 1020172)
Backed out changeset f895938013ff (bug 1020172)
2014-10-27 16:56:45 -07:00
Kershaw Chang
922d41136b Bug 1020172 - Part 2: Manage TabParent in chrome process. r=khuey 2014-10-24 02:29:00 -04:00
Robert O'Callahan
184af723d6 Bug 975931. Part 5: Propagate scrolling behavior for non-app non-browser remote <iframe>s. r=khuey
--HG--
extra : rebase_source : 22af85668d4e1f286c0887dd31842cd67f29f3f2
2014-02-24 18:45:14 +13:00
Botond Ballo
f403c5b4c5 Bug 964517 - Set TabContext's containing app ID correctly for app frames. r=roc 2014-02-19 12:10:07 -05:00
Fabrice Desré
3749574c01 Bug 918658 - Don't pretend that mozIApplication inherits from mozIDOMApplication r=bent 2013-10-08 15:52:26 -07:00
Nathan Froyd
98723f4c48 Bug 914826 - part 4 - fix source files that were bootlegging XPCOM do_* functions via generated ipdl headers; r=ehsan 2013-09-10 16:56:05 -04:00
Ehsan Akhgari
9890a8c148 Bug 919505 - Minimize the #includes in dom/ipc; r=jst 2013-09-23 17:30:40 -04:00
Justin Lebar
9befee6c8d Bug 896890 - TabContent::HasOwnApp() should be true iff TabContext::GetOwnApp() is non-null.
This change reworks how TabContext stores its data.  Before, it stored
an app-id and translated that into an app; now we do the reverse.  This
lets us guarantee that HasOwnApp() is true iff GetOwnApp() is non-null.

We added a new class, MaybeInvalidTabContext to assist with converting
from an IPCTabContext to a TabContext.  This allows us to ensure that a
TabContext object is never invalid.
2013-07-30 14:42:34 -07:00
Ryan VanderMeulen
77cb688076 Backed out changeset 4aeb00521c9d (bug 896890) for build bustage.
CLOSED TREE
2013-07-30 15:50:46 -04:00
Justin Lebar
c092dd4810 Bug 896890 - TabContent::HasOwnApp() should be true iff TabContext::GetOwnApp() is non-null. r=khuey
This change reworks how TabContext stores its data.  Before, it stored
an app-id and translated that into an app; now we do the reverse.  This
lets us guarantee that HasOwnApp() is true iff GetOwnApp() is non-null.

We added a new class, MaybeInvalidTabContext to assist with converting
from an IPCTabContext to a TabContext.  This allows us to ensure that a
TabContext object is never invalid.

--HG--
extra : rebase_source : d43e858739a342ab420122a90336bfd585be268a
2013-07-30 11:51:44 -07:00
Jon Hylands
18136e92bd Bug 853632 - Cache own and containing apps in TabContext. r=jlebar 2013-04-16 15:34:11 +02:00
Chris Jones
749061cf62 Backed out d2aa085d7ebd (bug 836605) 2013-02-06 15:49:27 -08:00
Chris Jones
ef36dc0d37 Bug 836605: Cache mozIApplication wherever possible on critical startup path. r=jlebar 2013-02-06 14:32:20 -08:00
Chris Jones
776beb535e Backed out changeset fed128eb92f3 (bug 836605) for making the IDL gods angry. CLOSED TREE 2013-02-06 14:57:14 -08:00
Chris Jones
30063d452f Bug 836605: Cache mozIApplication wherever possible on critical startup path. r=jlebar 2013-02-06 14:32:20 -08:00
Chris Jones
f3aa6d1f5e Bug 824177: Opened windows of browsers inherit their containing app. r=jlebar 2012-12-27 15:43:22 -08:00
Chris Jones
2114064656 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
e80ccc6058 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
a9dc8e795f 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
37f4a955e5 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