Support for `chrome`/`chrome_extensions` externs

[sgammon]

Hey there,

We have some interest in building a Chrome extension with the elemental2/J2CL stack. However, we can't yet use elemental2 to great effect because there isn't a chrome and/or chrome_extension package that brings those extern files into Java.

I know this project is quite early, but we wanted to file this to track progress against this goal. We are also happy to propose PRs to introduce this functionality.

Thank you for this awesome project and we're excited to help make it better how we can

[jDramaix]

This is a good idea but I think this should not be part of Elemental2 as Elemental aims to provide standardized javascript apis.

[realityforge]

I wonder about that. The "chrome" extension API is supported by Chrome, Opera and Firefox and presumably the new chromium based edge (although I have not checked this). While it is true that the "cross-platform" standardized API is meant to have a symbol named "browser" rather than chrome (and a few other changes IIRC), I don't believe there is any browser except Firefox that supports it? Presumably other browsers will in the future although I don't know when that will be.

I say this as I have the need to write a browser extension in closeish the future and would love to see it somewhere easy to collaborate. Anyhoo I would love to see mapping worked out and a simple example of an app if/when you get it going ;)

[sgammon]

@realityforge great point. in fact, the Chrome APIs have support outside of the traditional web platform. there are also Chromebooks, and so on.

it would be really cool to architect and distribute apps in Java for those platforms. i feel like elemental2 is basically a perfect container for it, especially since it is authored in a modular way that would require a user to opt-in to the Chrome APIs.

i may investigate forking elemental2, but I want to be careful to keep things easy to maintain. if anybody here has ideas about a good way to approach this, i'm all ears

[realityforge]

I had a poke around the API docs and it seems that the set of browser specific APIs is not as simple as those in one particular namespace or not.

I believe it would be possible that rather than forking elemental2 you could use the targets from the elemental2 project and then reference them from within a new elemental2-chrome project (or whatever) so you could reference the original types in elemental2 and the new project. It may require a little more bazel-fu than I have at the moment but it looks doable.

[jDramaix]

You don't need to fork elemental2. Elemental2 is built on top of JsInterop-generator that is public.
You just need to move your pr #120 in your own repository and it should work. If something is missing (like the patch process maybe), ping me.

[gkdn]

Maybe we can have elemental2-contrib-xxx. As Julien pointed, it is not technically necessary but it might be worthwhile since it simplifies discoverability and avoid any duplications.

[sgammon]

@gkdn i would love that, if i can help make it a reality let me know how

[sgammon]

@realityforge, do you happen to know the RFC that defines the browser symbol? it is very hard to find that on google

[realityforge]

Hmm ... poking about it looked like the standardization process kinda stalled from the post [1]. I tried to google around but ran into the same sorts of issues ;) The best I found was Mozilla's [2] and Microsoft's [3] browser extension docs.

HTH

[1] https://lists.w3.org/Archives/Public/public-browserext/2017Jul/0001.html
[2] https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions
[3] https://docs.microsoft.com/en-us/microsoft-edge/extensions

[tbroyer]

https://browserext.github.io/browserext/ ? (linked from the Mozilla doc linked above)

[jDramaix]

We may consider to create a contrib directory that will contain project like this one that is created by the open source community but not officially maintained by the Google J2CL team. I created #124 for that purpose.

Now I recommend you first to create you own repo containing your code and get ride of the extern diff file (fix directly the extern file in closure compiler repo).
Then if we get more request like this one, I'll create the contrib directory

[sgammon]

@jDramaix this had the effect of stopping our use of elemental2, which is sad, because chrome extensions are perhaps a perfect place to deliver Java-authored JavaScript

i understand you are wanting to wait until there are other requests, but that doesn't really help us. yes, we could avoid forking the project and just make our own project, but that's a little ridiculous when Bazel, Chrome, Chrome Extensions, Closure Compiler, and indeed all the glue between them are authored and kept up to date by Google

we wish elemental2 the best of luck and we'll try to use it if we can find a case for it in the future

[sgammon]

i am not entirely sure the internal need or direction behind elemental2. if the idea is to help add bricks to the open source community, which we can use, then why say no when we want to use them?

yes, browser/chrome isn't yet a standard. that never stopped google from shipping code before when it served google3

look, with all due respect, why even release this open source, if you aren't going to accept contributions? so you don't want people writing high-quality, high-performance Chrome extensions? it just strikes me as confusing.

[niloc132]

Sam, I started on this a while ago because I agree it seems like the perfect use case for j2cl/gwt. If memory serves, you're mostly interested in it working bazel (rather than maven, where I do most of my work), if so I think we could collaborate on that?