Closed Bug 545716 (SM-OOPP) Opened 14 years ago Closed 14 years ago

Use out-of-process-plugins (OOPP) framework in SeaMonkey

Categories

(SeaMonkey :: Build Config, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
seamonkey2.1b1

People

(Reporter: kairo, Assigned: kairo)

References

Details

Attachments

(1 file)

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.
Flags: wanted-seamonkey2.1+
Severity: normal → enhancement
Version: SeaMonkey 2.0 Branch → Trunk
Depends on: 549293
Flags: wanted-seamonkey2.1+
Alias: SM-OOPP
Depends on: 435881
Depends on: 377319
I'm seeing the property "dom.ipc.plugins.enabled" in the nightly should this be here or is this bug fixed?
(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.
(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.
Depends on: 598644
No longer depends on: 435881, 377319
Attached patch get it goingSplinter Review
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.
Assignee: nobody → kairo
Status: NEW → ASSIGNED
Attachment #477638 - Flags: review?(bugspam.Callek)
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.
Attachment #477638 - Flags: review?(bugspam.Callek) → review+
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.
(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. :)
Landed as http://hg.mozilla.org/comm-central/rev/9779b9a7650c
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Target Milestone: --- → seamonkey2.1b1
Depends on: 598915
Depends on: 598914
No longer depends on: 598915
Depends on: 598916
Flags: in-testsuite-
Depends on: 601493
Depends on: 604129
Depends on: 555234
Depends on: 557225
Depends on: 556846
Depends on: 558190
Flags: in-testsuite-
You need to log in before you can comment on or make changes to this bug.