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

> On 2013-09-01, at 18:13 , Mark Finkle < [email protected] > 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. 
_______________________________________________
mobile-firefox-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/mobile-firefox-dev

Reply via email to