Last Comment Bug 545716 - (SM-OOPP) Use out-of-process-plugins (OOPP) framework in SeaMonkey
(SM-OOPP)
: Use out-of-process-plugins (OOPP) framework in SeaMonkey
Status: RESOLVED FIXED
:
Product: SeaMonkey
Classification: Client Software
Component: Build Config (show other bugs)
: Trunk
: All All
: -- enhancement with 3 votes (vote)
: seamonkey2.1b1
Assigned To: Robert Kaiser
:
Mentors:
Depends on: 394502 OOPP 549293 555234 556846 557225 558190 598644 598914 598916 601493 604129
Blocks: 585438
  Show dependency treegraph
 
Reported: 2010-02-11 11:28 PST by Robert Kaiser
Modified: 2015-04-07 13:28 PDT (History)
17 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
get it going (3.01 KB, patch)
2010-09-22 13:49 PDT, Robert Kaiser
bugspam.Callek: review+
Details | Diff | Splinter Review

Description Robert Kaiser 2010-02-11 11:28:12 PST
Bug 478976 introduces the out-of-process-plugins framework (or OOPP) in the platform and current Firefox nightlies turn it on by default, even though it needs some stabilizing.
We also want that to be enabled in SeaMonkey 2.1, so I'm fining this bug for anything needed on our side.
As things stand now, we need libxul to use OOPP, so marking bug 394502 dependency, but bsmedberg said we might be able to make OOPP work with fully static builds in some way, but only once OOPP is usefully stable by itself.
Comment 1 Wyatt Childers 2010-06-23 11:15:55 PDT
I'm seeing the property "dom.ipc.plugins.enabled" in the nightly should this be here or is this bug fixed?
Comment 2 Justin Wood (:Callek) 2010-06-23 11:19:33 PDT
(In reply to comment #1)
> I'm seeing the property "dom.ipc.plugins.enabled" in the nightly should this be
> here or is this bug fixed?

Comes from the Core, and has no affect on any current SeaMonkey builds. We want to have it working though, and are actively working toward making it an option on our end.
Comment 3 Wyatt Childers 2010-06-23 11:32:37 PDT
(In reply to comment #2)
> (In reply to comment #1)
> > I'm seeing the property "dom.ipc.plugins.enabled" in the nightly should this be
> > here or is this bug fixed?
> 
> Comes from the Core, and has no affect on any current SeaMonkey builds. We want
> to have it working though, and are actively working toward making it an option
> on our end.

K hope you guys get it working seems like it could stop a ton of problems judging from what I've heard of Firefox crash decreases.
Comment 4 Robert Kaiser 2010-09-22 13:49:15 PDT
Created attachment 477638 [details] [diff] [review]
get it going

From all I'm seeing, this is all we need for now. With the confvars.sh switch, I get a plugin-container process on a Flash page, so it seems to be working. The packaging fixes correct the changes I'm seeing in package-compare.

My plan is to get bug 598644 landed first, issue a round of nightlies, then land this once those started, so we have a set of nightlies in between.
Comment 5 Justin Wood (:Callek) 2010-09-22 15:37:45 PDT
Comment on attachment 477638 [details] [diff] [review]
get it going

>diff --git a/suite/confvars.sh b/suite/confvars.sh
>+# Don't ifdef MOZ_IPC this because mac ppc needs it too.
>+include $(MOZILLA_SRCDIR)/ipc/app/defs.mk
>+DEFINES += -DMOZ_CHILD_PROCESS_NAME=$(MOZ_CHILD_PROCESS_NAME)
>+

Nit: doesn't look like thats the case anymore, all builds only use that (from this directory) inside ifdef MOZ_IPC. Yes Firefox still does it your way, and it doesn't really hurt anyway.

>+@BINPATH@/components/jetpack.xpt

Huh, is jetpack really useful as it stands? does it need an APP switch rather than libxul/ipc switch? and does it really need to be added when IPC is defined, or is it part of the libxul enabled new xpt's?

I'm not blocking on this answer though.
Comment 6 Justin Wood (:Callek) 2010-09-22 15:46:05 PDT
KaiRo, please write a patch, and land-with this:

a prefs sync:

http://mxr.mozilla.org/comm-central/search?string=dom.ipc.plugins.enabled&find=%2Fbrowser&findi=&filter=^[^\0]*%24&hitlimit=&tree=comm-central

I would rather not land the above without this bit.
Comment 7 Robert Kaiser 2010-09-22 16:10:15 PDT
(In reply to comment #5)
> Comment on attachment 477638 [details] [diff] [review]
> get it going
> 
> >diff --git a/suite/confvars.sh b/suite/confvars.sh
> >+# Don't ifdef MOZ_IPC this because mac ppc needs it too.
> >+include $(MOZILLA_SRCDIR)/ipc/app/defs.mk
> >+DEFINES += -DMOZ_CHILD_PROCESS_NAME=$(MOZ_CHILD_PROCESS_NAME)
> >+
> 
> Nit: doesn't look like thats the case anymore, all builds only use that (from
> this directory) inside ifdef MOZ_IPC. Yes Firefox still does it your way, and
> it doesn't really hurt anyway.

I'd rather leave this that way, as we still build PPC but PPC doesn't have IPC.

> >+@BINPATH@/components/jetpack.xpt
> 
> Huh, is jetpack really useful as it stands?

This is js/jetpack, I think that's just a JS API library, and it's activated by http://mxr.mozilla.org/comm-central/source/mozilla/toolkit/toolkit-tiers.mk#107 so it basically comes to libxul with enabling IPC.

(In reply to comment #6)
> a prefs sync:

Got rs=Callek for including a straight copy from FF in the patch.
I'll wait for all nightlies to start with libxul-non-IPC builds before I check this in. Regular nightlies of tomorrow should be libxul+OOPP then. :)
Comment 8 Robert Kaiser 2010-09-22 18:05:38 PDT
Landed as http://hg.mozilla.org/comm-central/rev/9779b9a7650c

Note You need to log in before you can comment on or make changes to this bug.