Reconsidering embedding

351 views
Skip to first unread message

Cameron Kaiser

unread,
Feb 14, 2013, 1:09:01 PM2/14/13
to
The concerning proliferation of WebKit is not only being strengthened
by mobile, which Mobile Firefox addresses, but by three things on the
desktop: 1) the recent end of Presto development 2) the strong
advertising and publicity resources thrown behind Chrome 3) the ease
of integration into projects and browser shells (which indirectly
contributed to reason 1).

Firefox's desktop improvements help to address point 2, but the loss
of Gecko embedding with Firefox 4 means realistically only XUL-based
projects will make it, and for all its power XUL has significant
disadvantages, particularly with respect to speed and native widget
support. It was never super-easy to drop Gecko into a browser project,
but during their time of existence Camino and K-Meleon proved it was
possible and maintainable. Trident permits embedding as well. Of the
three left, only Gecko does not, meaning it will never be a realistic
option for a future browser that wants to jump ship; it's going to be
either Trident or WebKit.

Has there been internal discussion about making Gecko embeddable again?

Benjamin Smedberg

unread,
Feb 14, 2013, 4:09:57 PM2/14/13
to Cameron Kaiser, dev-pl...@lists.mozilla.org
On 2/14/2013 1:09 PM, Cameron Kaiser wrote:
>
> Firefox's desktop improvements help to address point 2, but the loss
> of Gecko embedding with Firefox 4
What does this mean exactly? We did end support for gtkmozembed and the
activex control, but "gecko embedding" did not end, and we continue to
have people and companies bundling gecko using the low-level
nsIBaseWindow and nsIWebBrowser interfaces.
> Has there been internal discussion about making Gecko embeddable again?
It is embeddable, so perhaps you mean something more specific like "have
a stable embedding API", or "focus resources on making embedding easy"?
The question is of course who would maintain such an embedding API. If
you're asking existing core gecko contributors (volunteer or employee)
to do this, what things should we *stop* doing in order to have time for
embedding? Or if you're suggesting that we build a new community around
embedding, how should we do that? Who are the relevant stakeholders, and
how do we join them together around a common cause?

--BDS


Cameron Kaiser

unread,
Feb 14, 2013, 4:51:09 PM2/14/13
to
On Feb 14, 1:09 pm, Benjamin Smedberg <benja...@smedbergs.us> wrote:
> On 2/14/2013 1:09 PM, Cameron Kaiser wrote:
>
> > Firefox's desktop improvements help to address point 2, but the loss
> > of Gecko embedding with Firefox 4
>
> What does this mean exactly? We did end support for gtkmozembed and the
> activex control, but "gecko embedding" did not end, and we continue to
> have people and companies bundling gecko using the low-level
> nsIBaseWindow and nsIWebBrowser interfaces.

If that's the case, then a lot of people (including, apparently, me)
got the wrong idea:

http://lwn.net/Articles/436412/
http://www.h-online.com/open/news/item/Mozilla-kills-embedding-support-for-Gecko-layout-engine-Update-1218990.html
http://arstechnica.com/apple/2011/04/webkit-best-option-for-camino-as-mozilla-drops-gecko-embedding/

This situation is not at all clear from MDN, btw, which even still
makes reference to PPEmbed. I don't see anything about using
nsIBaseWindow or nsIWebBrowser for this purpose, so I can't evaluate
that.

https://developer.mozilla.org/en-US/docs/Gecko/Embedding_Mozilla/FAQ/Embedding_Gecko

But when I think of embedding Gecko, I think of embedding it in a
wrapper the way Camino and K-Meleon did, and near as I can determine
that is no longer possible. Am I mistaken?

> It is embeddable, so perhaps you mean something more specific like "have
> a stable embedding API", or "focus resources on making embedding easy"?
> The question is of course who would maintain such an embedding API. If
> you're asking existing core gecko contributors (volunteer or employee)
> to do this, what things should we *stop* doing in order to have time for
> embedding? Or if you're suggesting that we build a new community around
> embedding, how should we do that? Who are the relevant stakeholders, and
> how do we join them together around a common cause?

I'm merely saying that the discussion should be reopened. However, let
me be somewhat explicit. It looks like multi-process desktop Firefox
is not imminent and possibly even not on the horizon given Servo. If
someone(tm) were to step up and present a cogent plan for restoring
binary embedding a la gtkmozembed and likeminded methods, would this
be accepted? Is that a firm offer?

Cameron Kaiser

Matt Basta

unread,
Feb 14, 2013, 5:23:12 PM2/14/13
to Benjamin Smedberg, dev-pl...@lists.mozilla.org, Cameron Kaiser
Perhaps this is more of a call to build better tools to enable the community to use Gecko in the same way that one could use Webkit. For instance:

- Webkit has PhantomJS, letting devs run headless webkit environments virtually effortlessly. There is no equivalent (let alone mature) Gecko project.
- qt-webkit is actively being updated. qt-gecko hasn't been touched since 2008.
- There are numerous .Net wrappers for webkit. There are none that I've found that work post 2008/2009 for gecko.

Perhaps it would be best to identify places where having the ability to integrate Gecko would be a win for developers and focus on those opportunities.



----- Original Message -----
From: "Benjamin Smedberg" <benj...@smedbergs.us>
To: "Cameron Kaiser" <cka...@floodgap.com>
Cc: dev-pl...@lists.mozilla.org
Sent: Thursday, February 14, 2013 1:09:57 PM
Subject: Re: Reconsidering embedding

On 2/14/2013 1:09 PM, Cameron Kaiser wrote:
>
> Firefox's desktop improvements help to address point 2, but the loss
> of Gecko embedding with Firefox 4
What does this mean exactly? We did end support for gtkmozembed and the
activex control, but "gecko embedding" did not end, and we continue to
have people and companies bundling gecko using the low-level
nsIBaseWindow and nsIWebBrowser interfaces.
> Has there been internal discussion about making Gecko embeddable again?
It is embeddable, so perhaps you mean something more specific like "have
a stable embedding API", or "focus resources on making embedding easy"?
The question is of course who would maintain such an embedding API. If
you're asking existing core gecko contributors (volunteer or employee)
to do this, what things should we *stop* doing in order to have time for
embedding? Or if you're suggesting that we build a new community around
embedding, how should we do that? Who are the relevant stakeholders, and
how do we join them together around a common cause?

--BDS


_______________________________________________
dev-planning mailing list
dev-pl...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-planning

wjohns...@gmail.com

unread,
Feb 14, 2013, 5:39:34 PM2/14/13
to Benjamin Smedberg, dev-pl...@lists.mozilla.org, Cameron Kaiser
On Thursday, February 14, 2013 2:23:12 PM UTC-8, Matt Basta wrote:
> Perhaps this is more of a call to build better tools to enable the community to use Gecko in the same way that one could use Webkit. For instance:
>
> - Webkit has PhantomJS, letting devs run headless webkit environments virtually effortlessly. There is no equivalent (let alone mature) Gecko project.
>
> - qt-webkit is actively being updated. qt-gecko hasn't been touched since 2008.
>
> - There are numerous .Net wrappers for webkit. There are none that I've found that work post 2008/2009 for gecko.
>
> Perhaps it would be best to identify places where having the ability to integrate Gecko would be a win for developers and focus on those opportunities.

There is at least one very active volunteer driven effort to improve embedding here: https://wiki.mozilla.org/Embedding/IPCLiteAPI where some really awesome IPC stuff is happening (with a heavy emphasis on embedding in qt, but the ipc code should actually make embedding on any platform easier).

Cameron Kaiser

unread,
Feb 15, 2013, 12:45:47 AM2/15/13
to
On Feb 14, 2:39 pm, wjohnston2...@gmail.com wrote:
> On Thursday, February 14, 2013 2:23:12 PM UTC-8, Matt Basta wrote:
> > Perhaps this is more of a call to build better tools to enable the community to use Gecko in the same way that one could use Webkit. For instance:
>
> > - Webkit has PhantomJS, letting devs run headless webkit environments virtually effortlessly. There is no equivalent (let alone mature) Gecko project.
>
> > - qt-webkit is actively being updated. qt-gecko hasn't been touched since 2008.
>
> > - There are numerous .Net wrappers for webkit. There are none that I've found that work post 2008/2009 for gecko.
>
> > Perhaps it would be best to identify places where having the ability to integrate Gecko would be a win for developers and focus on those opportunities.
>
> There is at least one very active volunteer driven effort to improve embedding here:https://wiki.mozilla.org/Embedding/IPCLiteAPIwhere some really awesome IPC stuff is happening (with a heavy emphasis on embedding in qt, but the ipc code should actually make embedding on any platform easier).

That is indeed very promising, though it looks like the patches Oleg
wrote have bitrotted somewhat. It should be possible to abstract the
IPC to really any sort of host widget, if I understand the wiki page
correctly. Hopefully this is able to land in the near future?

Cameron Kaiser

Benjamin Smedberg

unread,
Feb 15, 2013, 10:05:40 AM2/15/13
to Cameron Kaiser, dev-pl...@lists.mozilla.org
On 2/14/13 4:51 PM, Cameron Kaiser wrote:
>
> This situation is not at all clear from MDN, btw, which even still
> makes reference to PPEmbed. I don't see anything about using
> nsIBaseWindow or nsIWebBrowser for this purpose, so I can't evaluate
> that.
>
> https://developer.mozilla.org/en-US/docs/Gecko/Embedding_Mozilla/FAQ/Embedding_Gecko
I will try to fix up this page, probably by mostly removing the existing
content.
>
> But when I think of embedding Gecko, I think of embedding it in a
> wrapper the way Camino and K-Meleon did, and near as I can determine
> that is no longer possible. Am I mistaken?
This question could have two meanings:

* is there currently a wrapper API? Not really. There are several
unmaintained projects that might work as a base for somebody.
* Could there be a wrapper API? Yes. We'd need somebody to maintain it.

> I'm merely saying that the discussion should be reopened. However, let
> me be somewhat explicit. It looks like multi-process desktop Firefox
> is not imminent and possibly even not on the horizon given Servo. If
> someone(tm) were to step up and present a cogent plan for restoring
> binary embedding a la gtkmozembed and likeminded methods, would this
> be accepted?
As mentioned in the original thread two years ago, I am certainly open
to some person or group of volunteers writing and maintaining an
embedding layer. I'm happy to talk privately with a potential "someone"
about building a *successful* effort, which will involve much more than
just a one-time plan.

--BDS

wjohns...@gmail.com

unread,
Feb 14, 2013, 5:39:34 PM2/14/13
to mozilla.de...@googlegroups.com, dev-pl...@lists.mozilla.org, Benjamin Smedberg, Cameron Kaiser
On Thursday, February 14, 2013 2:23:12 PM UTC-8, Matt Basta wrote:
> Perhaps this is more of a call to build better tools to enable the community to use Gecko in the same way that one could use Webkit. For instance:
>
> - Webkit has PhantomJS, letting devs run headless webkit environments virtually effortlessly. There is no equivalent (let alone mature) Gecko project.
>
> - qt-webkit is actively being updated. qt-gecko hasn't been touched since 2008.
>
> - There are numerous .Net wrappers for webkit. There are none that I've found that work post 2008/2009 for gecko.
>
> Perhaps it would be best to identify places where having the ability to integrate Gecko would be a win for developers and focus on those opportunities.

There is at least one very active volunteer driven effort to improve embedding here: https://wiki.mozilla.org/Embedding/IPCLiteAPI where some really awesome IPC stuff is happening (with a heavy emphasis on embedding in qt, but the ipc code should actually make embedding on any platform easier).
Reply all
Reply to author
Forward
0 new messages