Hi Anders, On Tue, Nov 29, 2016 at 9:10 AM, Anders Rundgren < anders.rundgren....@gmail.com> wrote:
> There are virtually tons of developers out there using Android Intents to > start "Apps" from the Web. > Aye, and Firefox does support this custom URI scheme. > However, this mechanism sucks big-time since: > 1. It leaves the invoking Web page in an "orphaned" state > 2. There's no way to "talk back" to the invoked Web page > 3. There's no Web page security context available to invoked "App" > 4. There's no App/Web life-cycle control > > The Web2Native Bridge does all that: > https://github.com/cyberphone/web2native-bridge#api I took a look at this and don't yet see how this translates to Android. It all seems very Chrome OS specific: "Applications callable by the Web2Native Bridge emulator *must* be written in Java and stored in a for the purpose dedicated directory." Is your intention to define a new specification for how an Android App advertises this capability and how the browser connects to it? (Android Intents, an AIDL and handshake protocol, etc...) This would be interesting; it's similar in spirit to the Chrome Custom Tabs work, which goes in the opposite direction: it makes Apps have better entry into the browser (where-as you want content in the browser to have better entry into a companion App). Unfortunately (or maybe you guys think fortunately) I will most likely > implement this in Chromium since there is more activity in that channel. > I never think it's fortunate when folks passionate enough to implement a thing don't implement under the Mozilla umbrella! I can provide some guidance on doing this in Firefox for Android, if you'd like to try it under our umbrella. I can't speak to things like ship criteria and release schedules, though :( As a bizarre "Mozilla bonus point", I bet you can do this in a bootstrapped extension using the essentially undocumented "Java addons" feature! It's 100% non-obvious how to use it, but you can add a classes.dex to a Firefox addon and load it using a Java class loader. See https://dxr.mozilla.org/mozilla-central/source/mobile/android/javaaddons/java/org/mozilla/javaaddons/JavaAddonInterfaceV1.java and the test at https://dxr.mozilla.org/mozilla-central/source/mobile/android/tests/browser/chrome/test_java_addons.html, which appears to be still running in our automation. Using this, you could have your extension inject the `navigator.nativeConnect` method into the content context (at least I think this is possible, I did it once -- see https://github.com/ncalexan/bootstrapped-webapi-skeleton -- but I think this approach may no longer work) and then use a Java addon to handle proxying out to your test application, either using Intents or binding a Service or whatever. Wild stuff! But honestly, you might find it easier to hack up Fennec, since Fennec + extensions + a new Web API + Java addons probably requires you to be a Fennec hacker in the first place... Mozilla have already focused on a similar concept which I doubt will ever > be supported in Android: https://browserext.github.io/native-messaging/ > In Android Apps does a better job than "in-browser" extensions. > Is this the same as https://mail.mozilla.org/pipermail/firefox-dev/2016-July/004461.html? In general, I think there are really hard security and permission questions that need to be raised and answered around this work. For example, it's a fundamental tenet of "the Web" that sites are isolated. How does one ensure that origin "foo.com" can only access "com.foo.application"? What does this even mean on Android, where the first App with an Android package name is the winner (leading to wild security holes, some of which I have had to fix in Fennec), regardless of who publishes the App? These are hard questions that can't be punted in a shipping product. (Of course, they can be punted in an experiment or tech demo!) Nick _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
