Landing multi-process plugins in mozilla-central (Tuesday)

10 views
Skip to first unread message

Benjamin Smedberg

unread,
Nov 23, 2009, 2:17:49 PM11/23/09
to
The electrolysis tree is completely green and we think we've resolved all
the remaining code blockers to land out-of-process plugins (OOPP) into
mozilla-central. Unless I will be interfering with Firefox 3.6/1.9.2 work,
I'd like to do this tomorrow morning (Tuesday). This means the tree will
probably be closed/restricted for at least a couple hours. Please let me
know if there are pending landings for 3.6 which would be delayed by closing
mozilla-central tomorrow morning.

* Because the electrolysis branch contains both plugin and tab work, this
will not be a straight up merge from e10s to mozilla-central: I will be
landing a patch containing just the plugin-related changes.

* When this lands, building --enable-ipc will be the default configuration
on platforms which support it. Because of the way the chromium libraries are
linked, this means that --enable-libxul will also become the default
configuration. If you have a slow computer, you can still specify
--disable-ipc --disable-libxul to reduce the libxul link time.

* OOPP will be preffed off by default. We still don't have support for
windowless plugins on Windows, and don't have crash reporting and other
important metrics available for turning OOPP on by default. To enable OOPP,
set the dom.ipc.plugins.enabled pref to true and restart the browser.

* The E10s trees currently show a significant performance regression on
Windows (Ts/Txul) compared with mozilla-central, even though multi-process
plugins are preffed off. We believe this is a testing fluke, because we
can't reproduce it locally nor on try-talos. I'll be landing into a quiet
tree and monitoring Talos numbers closely. (Bug 528928)

--BDS

Boris Zbarsky

unread,
Nov 23, 2009, 2:27:36 PM11/23/09
to
On 11/23/09 2:17 PM, Benjamin Smedberg wrote:
> * When this lands, building --enable-ipc will be the default configuration
> on platforms which support it. Because of the way the chromium libraries are
> linked, this means that --enable-libxul will also become the default
> configuration. If you have a slow computer, you can still specify
> --disable-ipc --disable-libxul to reduce the libxul link time.

So what will happen with current mozconfigs that explicitly list
--disable-libxul? Will they just fail to compile unless --disable-ipc
is added? Will they silently do libxul? Keep not doing libxul?
Something else?

-Boris

Mike Beltzner

unread,
Nov 23, 2009, 2:51:33 PM11/23/09
to Benjamin Smedberg, dev-pl...@lists.mozilla.org
On 2009-11-23, at 2:17 PM, Benjamin Smedberg wrote:

> mozilla-central. Unless I will be interfering with Firefox 3.6/1.9.2 work,
> I'd like to do this tomorrow morning (Tuesday). This means the tree will
> probably be closed/restricted for at least a couple hours. Please let me
> know if there are pending landings for 3.6 which would be delayed by closing
> mozilla-central tomorrow morning.

Hey Benjamin. Sadly, there are a lot of pending landings; as I said in today's meeting, we haven't frozen for Firefox 3.6 yet, and the tree is still restricted until we do. Based on my current estimate, this will have to wait until after the Thanksgiving holiday.

cheers,
mike

Benjamin Smedberg

unread,
Nov 23, 2009, 2:53:50 PM11/23/09
to
On 11/23/09 2:27 PM, Boris Zbarsky wrote:

> So what will happen with current mozconfigs that explicitly list
> --disable-libxul? Will they just fail to compile unless --disable-ipc
> is added? Will they silently do libxul? Keep not doing libxul?

They will fail at configure time with `--enable-ipc requires --enable-libxul`

--BDS

Benjamin Smedberg

unread,
Nov 23, 2009, 4:26:05 PM11/23/09
to
On 11/23/09 2:51 PM, Mike Beltzner wrote:

> Hey Benjamin. Sadly, there are a lot of pending landings; as I said in
> today's meeting, we haven't frozen for Firefox 3.6 yet, and the tree is
> still restricted until we do. Based on my current estimate, this will
> have to wait until after the Thanksgiving holiday.

Will closing the tree tomorrow morning have any affect on the blocker
landing rate? I'm sherriff tomorrow, so I'm willing to land any ready
blockers when the tree opens and watch it, if that will help alleviate
concerns. I think it's pretty important to start getting the plugin work in
the hands of nightly testers ASAP.

--BDS

Mike Beltzner

unread,
Nov 23, 2009, 4:35:57 PM11/23/09
to Benjamin Smedberg, dev-pl...@lists.mozilla.org
----- "Benjamin Smedberg" <benj...@smedbergs.us> wrote:

> Will closing the tree tomorrow morning have any affect on the blocker
> landing rate? I'm sherriff tomorrow, so I'm willing to land any ready
> blockers when the tree opens and watch it, if that will help
> alleviate concerns. I think it's pretty important to start getting the plugin
> work in the hands of nightly testers ASAP.

Yes, it will have a negative effect as there are 30+ blockers currently not on mozilla-central, and they'll need to land there before they go on mozilla-1.9.2. I don't want to risk a time delay that may be introduced by e10s; no ill-judgment intended of what I'm sure is great work and pre-testing on the part of the e10s team, but I've learned to just limit risk in crunch times.

I agree that this needs testing sooner rather than later. I'm not sure that we'll get that testing over the Thanksgiving break, so I'd suggest that we keep mozilla-central restricted (as agreed at the Tuesday meeting last week) until we get to RC code freeze.

cheers,
mike

Boris Zbarsky

unread,
Nov 23, 2009, 5:39:52 PM11/23/09
to
On 11/23/09 2:53 PM, Benjamin Smedberg wrote:
> They will fail at configure time with `--enable-ipc requires --enable-libxul`

Sounds good.

-Boris

Serge Gautherie

unread,
Nov 24, 2009, 9:20:55 AM11/24/09
to
Benjamin Smedberg wrote:

> * When this lands, building --enable-ipc will be the default configuration
> on platforms which support it. Because of the way the chromium libraries are
> linked, this means that --enable-libxul will also become the default
> configuration. If you have a slow computer, you can still specify
> --disable-ipc --disable-libxul to reduce the libxul link time.

Iirc, comm-central apps (at least SeaMonkey) don't support
--enable-libxul yet.
Is it still the case? If yes, is a c-c bug needed to prepare for this
landing?

Dan Mosedale

unread,
Nov 25, 2009, 2:11:33 PM11/25/09
to dev-pl...@lists.mozilla.org
Yes, but happily philor has already filed and patched in bug 530723.

Dan

Phil Ringnalda

unread,
Nov 25, 2009, 2:16:25 PM11/25/09
to

s/patched/patched Thunderbird, because it's a per-app thing, so you can
either try to get a jump on the landing by patching SeaMonkey the same
way in a SeaMonkey bug, or you can wait until it lands and fix it then/

Reply all
Reply to author
Forward
0 new messages