Landing multi-process plugins in mozilla-central (Tuesday)
Benjamin Smedberg
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
> * 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
> 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
> 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
> 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
> 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
> They will fail at configure time with `--enable-ipc requires --enable-libxul`
Sounds good.
-Boris
Serge Gautherie
> * 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
Dan
Phil Ringnalda
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/