mozilla / node-firefox

node.js modules for interacting with Firefox via the DevTools remote protocol
https://www.npmjs.org/package/firefox
Mozilla Public License 2.0
301 stars 18 forks source link

firefox-client is [UNMAINTAINED], should we replace / maintain? #29

Open lmorchard opened 9 years ago

lmorchard commented 9 years ago

Looking at the firefox-client repo, there's a big [UNMAINTAINED] in the description.

The last commit was back in Nov 2014. That seems not too long ago, though I'm not very clueful about the (in)stability of the Firefox dev APIs. Could be practically fine for a very long time.

But, assuming the worst, should we consider picking up maintenance of firefox-client? Or, maybe splitting off the bits used by the node-firefox suite?

fwenzel commented 9 years ago

This appears relevant for @canuckistani

sole commented 9 years ago

I asked @canuckistani about this too. Heather left Mozilla a while ago but she has transferred ownership of a couple of repositories to Jeff. I don't think she would mind transferring this one-it would keep the code alive :-)

jeffgca commented 9 years ago

It's a little complicated - Firefox Client works right now ( I've been using it for some browser automatio and it's awesome! ). There is another client project with a smaller api called volcan that is a bit more flexible.

  1. fork firefox-client somewhere, possibly into the /mozilla/ github org.
  2. look at firefox-client as well as volcan and figure out what api we want. I thik the firefox-client api is pretty good, but could use some baked-in promises support ease the pain of making many many tab.DOM.* calls.
  3. look at all of the various bits of code lying around for starting up and configuring firefox processes in projects like firefox-client and jpm and deliver a key part of this: starting up a firefox process on a remote server with the right x11 environment that is listening for remote debugging connections on the specified port, so that libraries like firefox-client can connect to them and do things.
jeffgca commented 9 years ago

Also, tagging @Gozala in this thread as he is the authour of volcan.

sole commented 9 years ago
  1. I would suggest transferring the repo to mozilla. Don't fork it because then the issues end up in heather's repo, which is not maintained ;-)
  2. maybe firefox-client could return both (promises+callbacks), or maybe a new version of firefox-client is not backwards compatible and only uses promises
  3. this looks like a completely different project!
jeffgca commented 9 years ago
  1. this looks like a completely different project!

I think a complimentary and necessary one though. If I'm going to fully automate Firefox on a server for automation.

ochameau commented 9 years ago

We kept hearing about Vulcan but it is released ? Does that work with webapps actor, or at least regular tab actors (console, style, debugger ??) ? firefox-client works, is released for quite a while, bug-fixed, supports old version of Firefox OS and almost all actors if not all... And node-firefox is already entangled with firefox-client. So we would need serious arguments to move to it! Moving firefox-client into another github account and tweaking it to promises sounds way more pragmatic choice.

tofumatt commented 9 years ago

Sorry, this issue was brought up again in IRC by @digitarald and I realised we didn't really come to a conclusion here.

I think what makes sense is to build on Heather's work. It works for us and if we need to update it or add to it we can. Once that happens we push it to a Mozilla repo.

When we do this, we should update its codebase to simplify it a bit and bring it in-line with node-firefox (Promises-only API, etc.)

I'll leave this open for now but I think the plan is to maintain our own version, though I'm gonna talk with @canuckistani more about this tomorrow morning and will update here then as well.

ochameau commented 9 years ago

What would be great is to integrate firefox-client tests in our CI tools (treeherder). That would make it fully supported by everyone and prevent regressing it. I imagine that's something somewhat easy to do via taskcluster.