@snorp: This is the current state. In theory this could land. It's behind a build flag and disabled by default.
It works as long as the custom tab activity is the only one. As soon as you open multiple custom tabs or switch between the browser and a custom tab we just render white pages everywhere. In addition to that I saw some JS errors (Messaging.jsm complains that there's already a listener for some messages and there was also some SessionStore stuff going on.). From the frontend side there's all the customization missing so far; this is only a full screen browser view right now.

We should *not* land this behind the Nightly flag: This will just break Nightly when opening the Browser and a custom tab. So most of the time you will have annoying white screens. That's even for Nightly too broken.
(In reply to :Margaret Leibovic from comment #7)
> I think we should try to land this behind a build flag, or even a run-time
> flag on Nightly only if possible. That would allow Google to start working
> to add support for Firefox to the support library.
What support does Google need to add? The patches work as-is with for example Google search and Google+. I didn't test a variety of apps though.

(In reply to Sebastian Kaspari (:sebastian) from comment #9)
> We should *not* land this behind the Nightly flag: This will just break
> Nightly when opening the Browser and a custom tab. So most of the time you
> will have annoying white screens. That's even for Nightly too broken.
>
> (In reply to :Margaret Leibovic from comment #7)
> > I think we should try to land this behind a build flag, or even a run-time
> > flag on Nightly only if possible. That would allow Google to start working
> > to add support for Firefox to the support library.
>
> What support does Google need to add? The patches work as-is with for
> example Google search and Google+. I didn't test a variety of apps though.
They mostly wanted to be able to test Firefox's custom tabs capability. If we land this disabled behind a build flag, we could still give them a custom APK to test.

https://reviewboard.mozilla.org/r/56366/#review55550> @null may be slightly more performant, depending on context, but I haven't looked at the code.
This is copied straight from gecko_app.xml. I'll file a new bug for this. If there's a performance gain possible then our main layout should benefit from that too. :)

https://reviewboard.mozilla.org/r/56364/#review55548
Mhmh. Currently the build flag disables the feature but it's still getting compiled and therefore we need the library. I expect Proguard to strip most of the code after building if the feature is disabled.
Now that platform is looking into getting this feature ready for prime time it seems to be helpful to always build (and verify) this - but have it disabled until it's ready.
Let's see what the build metrics report after this lands: Does it affect APK size? If so then let's see if we need to take action.