Turn on IPC/OOPP in Thunderbird builds

RESOLVED FIXED in Thunderbird 5.0b1

Status

RESOLVED FIXED
8 years ago
8 years ago

People

(Reporter: standard8, Assigned: standard8)

Tracking

unspecified
Thunderbird 5.0b1
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

We should turn on inter-process-communication and out-of-process-plugins for nightly builds. The main advantages at this stage are that it brings us closer to the Firefox core so that we're not diverging too far. This should help to reduce random bustages in our code.

The side-effect is that RSS feeds and content-tabs will be able to make use of OOPP if desired.

We'll also have the chance for separating out other processes later on, if I correctly understand the direction that IPC is going in
Created attachment 517428 [details] [diff] [review]
[checked in] Part 1 - basic build config

Ok, this just ports to Thunderbird the various build config related parts to enable IPC.

I'm currently looking at doing the UI hooks. However, I think if m-c wants to land the restriction to stop disable IPC builds, then this would be enough (with a confvars tweak) to enable IPC.
Attachment #517428 - Flags: review?(bugspam.Callek)
Comment on attachment 517428 [details] [diff] [review]
[checked in] Part 1 - basic build config

I wouldn't have expected those additions to package-manifest getting turned on by this bug, (except the obvious @MOZ_CHILD_PROCESS_NAME@) but I trust you to have added necessary files there, so rs+ for that part. (even if its just stuff you are having ride-along in this bug)

For a strictly, "do it, UI Later" this looks good.
Attachment #517428 - Flags: review?(bugspam.Callek) → review+
(In reply to comment #2)
> I wouldn't have expected those additions to package-manifest getting turned on
> by this bug, (except the obvious @MOZ_CHILD_PROCESS_NAME@) but I trust you to
> have added necessary files there, so rs+ for that part. (even if its just stuff
> you are having ride-along in this bug)

Ok, so they should probably have ifdef MOZ_IPC around them, which I guess I'll add but remove again in a few days.
Comment on attachment 517428 [details] [diff] [review]
[checked in] Part 1 - basic build config

Checked in: http://hg.mozilla.org/comm-central/rev/519649224203
Attachment #517428 - Attachment description: Part 1 - basic build config → [checked in] Part 1 - basic build config
Created attachment 521130 [details] [diff] [review]
[checked in] Part 2 - enable IPC

This works locally and I've currently got this running on try server. Although we've not got any of the UI strings for it (to say the plugin has crashed, or whatever), we can still run plugins with it.

Given that trunk is currently failing to build because of this, I think we can turn it on for both 3.3 and trunk and finish the UI later (shouldn't take long, but today isn't the day for me to try and get that working).
Attachment #521130 - Flags: superreview?(bienvenu)

Comment 6

8 years ago
Comment on attachment 521130 [details] [diff] [review]
[checked in] Part 2 - enable IPC

rs=me
Attachment #521130 - Flags: superreview?(bienvenu) → superreview+
Attachment #521130 - Attachment description: Part 2 - enable IPC → [checked in] Part 2 - enable IPC
Blocks: 661410
This is effectively fixed, I've raised bug 661410 to implement the UI for IPC/OOPP.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 3.3a4
You need to log in before you can comment on or make changes to this bug.