Bug 545716 (SM-OOPP)

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

RESOLVED FIXED in seamonkey2.1b1

Status

SeaMonkey
Build Config
--
enhancement
RESOLVED FIXED
8 years ago
2 years ago

People

(Reporter: Robert Kaiser, Assigned: Robert Kaiser)

Tracking

Trunk
seamonkey2.1b1
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

8 years ago
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
(Assignee)

Updated

7 years ago
Depends on: 549293
(Assignee)

Updated

7 years ago
status-seamonkey2.1: --- → wanted
Flags: wanted-seamonkey2.1+
(Assignee)

Updated

7 years ago
Alias: SM-OOPP
(Assignee)

Updated

7 years ago
Depends on: 435881
(Assignee)

Updated

7 years ago
Depends on: 377319

Comment 1

7 years ago
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.

Comment 3

7 years ago
(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.
(Assignee)

Updated

7 years ago
Depends on: 598644
No longer depends on: 435881, 377319
(Assignee)

Comment 4

7 years ago
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.
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.
(Assignee)

Comment 7

7 years ago
(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. :)
(Assignee)

Comment 8

7 years ago
Landed as http://hg.mozilla.org/comm-central/rev/9779b9a7650c
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → seamonkey2.1b1
Depends on: 598915
Depends on: 598914
No longer depends on: 598915
Depends on: 598916
Blocks: 585438
Flags: in-testsuite-
Depends on: 601493
Depends on: 604129
Depends on: 555234
Depends on: 557225
Depends on: 556846
Depends on: 558190

Updated

2 years ago
status-seamonkey2.1: wanted → ---
Flags: in-testsuite-
You need to log in before you can comment on or make changes to this bug.