GeckoView Status

Mark Finkle mfinkle at
Sun Sep 1 18:21:21 PDT 2013

----- Original Message -----

> On 2013-09-01, at 18:13 , Mark Finkle < mfinkle at > wrote:

> > Work has been continuing on GeckoView, the Gecko rendering engine wrapped
> > in
> > an Android widget [1].

> So, let me start off by saying how excited I am about this work! I think it
> will likely be the basis of most of the Mobile Prototype add-ons I make, and
> will make those parts of my job quite a bit easier. :)

> > Some other ongoing work includes creating proper bindings/interfaces for
> > GeckoView so it's easy to use from a host application.

> I'm pretty happy with the interface you've described here. It seems
> consistent and makes sense to me. The only thing that I think would be
> useful that you're missing is something along the lines of
> addJavascriptInterface from WebView. I needed to use it in a previous
> prototype ( terrible diff here ) to notify the chrome of various in-content
> things happening. I think you could probably satisfy my use-cases with a
> generic extension to GeckoViewContent (something like "onReceivedEvent"?),
> if that seemed more like something you would want to implement.

Some form of extensibility would be nice. I don't know how well we'd be able to mimic addJavascriptInterface, but we know that it's possible to add Javascript-implemented components to window and window.navigator using XPCOM. The trick is finding a way to do this so it doesn't feel completely hacky to Android developers. 

Your onReceivedEvent (or onReceivedMessage) idea might be a nice, but how do we get some Javascript code to fire the event (or send the message)? In Fennec we use Gecko chrome Javascript (think browser.js) to send messages to Java. Those messages would be easy to catch in onReceivedMessage. Thinking like the Add-on SDK and page-mod, we might be able to send some Javascript over to the Gecko chrome side and run it in a sandbox. I'd be interested in other ideas too. I might be too biased on what we do in Fennec right now to see some new way. 

> > The spirit of this structure is to not create a "Full Web Browser in a
> > Widget", but to push a lot of the management and 100% of the UI to the host
> > app. GeckoView should do the minimum amount of encapsulation.

> I don't know if the Addon-SDK people are reading this list, but I would be
> interested in hearing their comments on this interface, and whether it could
> help them implement parts of their API…

I'm hoping the chrome Javascript APIs we are building (like NativeWindow, Prompt.jsm and others) will help the Add-on SDK team. If they have ideas for this widget though, I'd be happy to hear them. It might be interesting to see if it would be possible to somehow "install" and restartless add-on via the Java API. That could open up a lot of customization possibilities and might even allow Android apps built using the widget to support add-ons. 

Thanks for the input Blake. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the mobile-firefox-dev mailing list