cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <>
Subject Re: MozillaView update, bridge questions
Date Wed, 29 Oct 2014 18:18:15 GMT
PROMPT isn't the default bridge, addJavaScriptInterface is. We fall back to
PROMPT on Androids where AJI exposes security concerns. For Native->JS, we
still use ONLINE events, which is actually crazy.

Reason for non-JSON is two-fold:
1. JSON doesn't support binary (e.g. ArrayBuffer)
2. JSON doesn't compose super easily (e.g. if you want to bundle two
PluginResults together, with JSON you need to decode them both before being
able to use the first one.

On Wed, Oct 29, 2014 at 1:56 PM, Michal Mocny <> wrote:

> On Wed, Oct 29, 2014 at 1:45 PM, Joe Bowser <> wrote:
> > Hey
> >
> > Unfortunately, I don't have anything working yet for the new MozillaView,
> > but because MozillaView is so radically different than any other view,
> I've
> > been forced to re-think some things with our current exec script in
> > cordova.js, namely why we're still using a prompt-based solution for
> > NativeToJS API in 2014.
> >
> > I know that the reason we currently do this is because Android 2.3 sucks
> > and addJavascriptInterface doesn't work in the Emulator, and since people
> > only seem to test Android 2.3 in the emulator, we have to support this
> for
> > some reason.
> >
> > I'm thinking that since the performance, as well as rendering on Android
> > 2.3.x is so sub-par, maybe we want to strongly recommend that people use
> > MozillaView on 4.x and switch our bridge to do something else like poll
> >
> Do you mean MozillaView on 2.3?  My concern here is that those devices may
> only be on 512Mb ram and its hard to imagine an alternative webview running
> well on that (since it loses opportunity to share system resources, it has
> larger overheads than system webview).  That said, if FF browser app is
> having success on 2.3 devices, perhaps this is no different.  Perhaps
> mozilla folk have insights into FF browser app stats on 2.3 devices?
> > addJavascriptInterface and have the messages be sent back that way
> > instead.  I don't know if there's additional drawbacks to this approach,
> > which is why I'm asking here.
> >
> > Also, maybe it's time to re-think the encoding of the messages?  If we
> can
> > support moving JSON over the bridge we should do so instead of depending
> on
> > string encodings.  It's what's being done with Mozilla and I'm going to
> > have to write the MozillaView as almost a separate platform and I'll have
> > to override exec with it's stuff, since it's not a WebKit/Blink WebView,
> > and instead has a sane way to pass stuff across. :P
> >
> Last time I took a look at the bridge I asked the same question.  Currently
> encoding looks crazy at first glance.  Upon further inspection, it may be
> difficult to compete on throughput with a more cleanly implementation, and
> thats the reason for the ugly.  I'm all for an investigation into
> improvements here, but we should start with benchmarks and an understanding
> of what would be an acceptable regression (if any).
> >
> > Thoughts?
> >
> > Joe
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message