Jabref: Create addons for Chrome and Opera

[tobiasdiez]

I have just discovered that there are Zotero addons for Chrome, Safari and Opera. Moreover, the implementation looks really similar to the Firefox addon. Thus I think it would be rather easy to create JabRef addons for these browser, paralleling the development of JabFox.

[stefan-kolb]

:+1: for Chrome

[Siedlerchr]

Chrome and Firefox Addons are nowadays roughly the same code.

[tobiasdiez]

It seems like the only way to communicate between the Chrome addon and JabRef is to use the native messaging api. This is way more complicated then the solution for Firefox (process.start(path to JabRef)) and probably requires some changes to the JabRef installer.

[simonharrer]

We should install the plugins automatically during the normal installation. This also advertises them.

[tobiasdiez]

The new Firefox add-on framework WebExtensions (which tries to be compatible with chrome) also uses native messaging, see http://stackoverflow.com/questions/37769533/how-to-execute-a-command-line-program-in-firefox-webextensions or https://wiki.mozilla.org/WebExtensions/Native_Messaging. So if somebody of you implements the listener part in JabRef, I'm willing to try to port JabFox to the new WebExtensions framework and thus also to Chrome.

[stefan-kolb]

I'm definitely interested. Maybe we can discuss this in the next dev call!

[Siedlerchr]

I'll try out with with Native Messging

[Siedlerchr]

Found some snippet, which could he helpful:
http://pastebin.com/seCcZqK4

[tobiasdiez]

And here is an add-on demonstrating the usage of the messaging API (also contains a python script for receiving messages): https://github.com/mdn/webextensions-examples/tree/master/native-messaging

[daviian]

How far have we come with a solution?

[tobiasdiez]

@Siedlerchr do you think you can implement something for the 4.0 release?

[Siedlerchr]

Some more code on native messaing (c#)
https://github.com/ballamuth/Chrome4Net/tree/master/examples
and java https://github.com/ulymarins/chrome-native-messaging-java

[psychelzh]

How about an add-on for Microsoft Edge?

[Codeberg-AsGithubAlternative-buhtz]

I would call it waste of resources.

Edge is not widely used currently. I would hypothise that Edge-users are of a type of users that won't use JabRef. Maybe you are a exception.

There are better task on JabRef to put ressources in.

And from an idoligical point of view: Edige & MS should never be supported!

[tobiasdiez]

According to the documentation it is very very easy to convert a chrome extension to an Edge extension - thus I don't see any reason why we shouldn't provide an add-on for Edge.

@Siedlerchr any progress on the native messaging interface? As add-ons for other browsers is an often requested feature, it would be nice to implement it for 4.0 (of course not for the beta release). What do you think?

[Siedlerchr]

Sorry, there is no progress. The native messaging is a bit complicated.
Maybe I find some time over Easter to deeply look into it

2017-04-10 23:27 GMT+02:00 Tobias Diez [e-mail]:

According to the documentation
https://docs.microsoft.com/en-us/microsoft-edge/extensions/guides/porting-chrome-extensions
it is very very easy to convert a chrome extension to an Edge extension -
thus I don't see any reason why we shouldn't provide an add-on for Edge.

@Siedlerchr https://github.com/Siedlerchr any progress on the native
messaging interface? As add-ons for other browsers is an often requested
feature, it would be nice to implement it for 4.0 (of course not for the
beta release). What do you think?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/JabRef/jabref/issues/1284#issuecomment-293084248, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AATi5C_z88ip2GkJ6UwpDTXT6y9P1wGqks5rup7JgaJpZM4IOZlk
.

[hudcap]

I am contemplating installing Firefox just to use JabFox with Google Scholar, in light of #2046
When I am researching a new topic, I have to change proxies every few searches.
An addon for Chrome would be awesome.

[lpirl]

Would it be an option to fork from the Zotero connectors?

The connectors talk to the Zotero app via a Web API (127.0.0.1:23119, if you want to feed your Wireshark).
Maybe imitating the Zotero standalone app (the server for the API calls) and maintaining an fork of the Zotero browser plugins is less of an effort compared to writing everything from scratch.

Just my $ .02

[LinusDietz]

Well, we are currently quite busy fixing bugs and re-creating stability in the UI, rather than introducing new features. If, however, you are eager to contribute such a feature, we can give you some advice.

[tobiasdiez]

I have two PRs in the pipeline that take exactly the approach @lpirl suggested: https://github.com/JabRef/jabref/pull/3246 and https://github.com/JabRef/JabFox/pull/41. I'm grateful for any help!

[tobiasdiez]

So, JabFox is now converted to Web Extensions and thus we can start thinking about versions for Chrome/Vivaldi/Opera and Edge. A few things we have to decide:

How should these add-ons be named?

• Option A: give each extension its own name, depending on the browser. For example,
  
  
  
  • JabFox for Firefox
  
  
  • JabRome for Chrome
  
  
  • JabValdi for Vivaldi
  
  
  • JabEdge for Edge
  
  

• Option B: call them in a generic way, say "JabRef in the Browser" or "JabRef Connector"

How to structure the development?
Although most browsers now support some version of the "web extensions" framework, some minor adjustments have to be made for each browser. Moreover, the build chain is not the same for each browser.

• Option A: Create separate repositories for each browser-version that fork the current version (JabFox) and make the browser specific adjustments there. In this way, we can use the magic of git to sync changes.
• Option B: The same as A but use branches instead of separate repositories.
• Option C: Different folders in the same repository for each browser-specific version and use a build script to sync them.

I have a slight preference for options 1.A and 2.A or 2.B. @JabRef/developers what do you think?

[stefan-kolb]

If we want to promote the name JabRef we should probably aim for a generic name including JabRef, otherwise some neologisms are also fine.
Regarding the development: I think this is really up to you as you are the main driver in the development right now. I guess it makes sense to not split them up into 3 different repos if the changes are not significant. Maybe branches are the easiest way to sync the code from master.

[tobiasdiez]

Thanks for the feedback. On second thought, I also prefer a generic name. Let's brainstorm a bit:

• JabRef Web Importer
• JabRef Importer
• JabRef in the Browser
• JabRef Connector

More ideas?

[Codeberg-AsGithubAlternative-buhtz]

As name I would prefere a simple and generic one like _JabRef Connector_ (this is known by Citavi users for example).
_Web_ is an outdated term.
_Importer_ is wrong because the AddOn is an exporter exporting data out from the browser. The importing is done by JabRef itself.
_in the Browser_ could awake to much expectations: a full jabref in the browser like Zotero was in the past.

Code repository should definitly be only one because of managment reasons. I would reject the idea of browser specific branches because of the same reasons.

Browser specific things should be separated in browser-specific folders or files and merged together while build process. It the used language is not able to handle this then a simple python script should do the job puttin the right files together.

[hudcap]

Are there any updates on this?

[LyzardKing]

Implementing chrome/opera should be simple enough :tm:
I tried quickly and we'd need to change from a page_action to a browser_action
(meaning that it would show a button not in the url bar but on the right, with the other extensions)
The problem then seems to be that chrome does not give access to browser.*, using instead chrome.*
Mozilla made a polyfill that is a no-op in firefox (it would make no difference, and would basically wrap the chrome.* with browser.* calls.
I cannot get it to work, but that's mainly because I don't really have the time to dive in this..
The "instructions are here, if someone more inclined than me wants to try...

Also, the json file is slightly different, and in a different location, so in the next comment I'll leave the json and the link to a mozilla page with the paths.

https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Build_a_cross_browser_extension

[LyzardKing]

{
  "name": "org.jabref.jabref",
  "description": "JabRef",
  "path": "/opt/jabref/lib/jabrefHost.py",
  "type": "stdio",
  "allowed_origins": [
    "chrome-extension://hbngbnhgegoecdhfmndifldiaonjdgbn/"
  ]
}

This has to be saved as org.jabref.jabref.json in one of the paths set in:
https://developer.chrome.com/apps/nativeMessaging

[LyzardKing]

Most of the polyfill errors seem to come from the Zotero directory when I test via web-ext.
web-ext run -t chromium --chromium-binary /usr/bin/google-chrome-stable
(I set a custom binary only because I want to use chrome and not chromium...but that's another story)

[LyzardKing]

The polyfill is already in Zotero upstream, so it can be inherited by the import I guess..
https://github.com/zotero/zotero-connectors/commit/27123202a46aeae76e9340c6bf95f2989cbad281
I'm not sure how

[tobiasdiez]

Cool that you are working on this. I sadly don't have time right now to really support you here, but if you have any concrete questions feel free to ask.

[LyzardKing]

One question is the integration with zotero..
I don't have too much time either, and in the next couple of weeks I'll have even less..
I noticed that zotero integrate the polyfill, as evidenced in lines like this in the zotero-connectors gulpfile.js

var injectIncludeBrowserExt = ['browser-polyfill.js'].concat(injectInclude, ['api.js'], injectIncludeLast);

Unfortunately I'm not sure how to pull that in jabfox, so when I test in chrome I get an error because it's not loading the polyfill so it can't find the browser element(at least that's what I think).

I tried manually copying the file browser-polyfill.js in Zotero, but I have to then tell the zotero js scripts to load it, so I tried

var browser = require("webextension-polyfill"); from the mozilla examples

but the scripts don't have require (I'll admit freely that javascript is not my strong suit in any way)

[tobiasdiez]

It should be sufficient to put the browser-polyfill in the Zotero folder and add it in the following places:
https://github.com/JabRef/JabFox/blob/afed0dc2c427014a6ee77237de2b983f23830b23/manifest.json#L11
https://github.com/JabRef/JabFox/blob/afed0dc2c427014a6ee77237de2b983f23830b23/manifest.json#L94
https://github.com/JabRef/JabFox/blob/afed0dc2c427014a6ee77237de2b983f23830b23/gulpfile.js#L11

For testing, you can ignore the gulpfile and manually add the polyfill here as well:
https://github.com/JabRef/JabFox/blob/afed0dc2c427014a6ee77237de2b983f23830b23/Zotero/background.js#L29

[LyzardKing]

It still doesn't work.. I had already added it to those places, except for the background.js
Is it normal that gulp creates a zotero (lowercase) folder?

EDIT: also, I added a png icon, since chrome does not accept svg

[tobiasdiez]

😢
I would suggest you open a PR with your current progress and I'll have a look. But since I'm on conference this weak, it might take a week until I find the time.

[LyzardKing]

done. Check if I missed something, and if you have time to look at it..
If not, it's there for now :smile:

[tobiasdiez]

A preliminary test version for Chrome is now available under https://chrome.google.com/webstore/detail/jabref-browser-extension/bifehkofibaamoeaopjglfkddgkijdlh?authuser=2. It should work out of the box with the most recent development build https://builds.jabref.org/master/ (or follow the steps outlined at https://github.com/JabRef/JabRef-Browser-Extension/blob/master/README.md for a manual installation).

Please report any issues directly at https://github.com/JabRef/JabRef-Browser-Extension/issues