FxOS recently gained support for DevTools over Wi-Fi.

If node-firefox was able to detect Wi-Fi devices and connect to them, that would be quite cool!

The code to do so in Gecko is a bit complex, though. Ideally, some code could be shared with Gecko to reduce duplication.

Multiple modules would be impacted, such as: find-devices and firefox-client.

Not sure which actor implements this (or if said actor is in simulators/phones!)-will add more info as I ask around.

Les jokingly raised an interesting issue without even wanting to: how many apps can the phone accept until it collapses in appularity?

It might be interesting to find out by repeatedly installing an app until it breaks. Maybe there's no limit. Maybe the limit is whatever the storage accepts. This may be a lot when running on a simulator!

Currently to enable remote debugging you have to open the developer console and type listen {port_number}

This makes it impossible to run functional tests as we cannot launch Firefox and have it run on an specific port.

The solution would be to be able to:

firefox --remote-debugging-port=6000

there was some work going on this already: https://bugzilla.mozilla.org/show_bug.cgi?id=942756

I've written a script that instantiates @louisstow 's splashpack and then launches it using node-firefox. This works for 2.2 simulator but not 2.0 simulator.

Script is at https://github.com/wfwalker/owascan/blob/master/owasimulate.js

I'm thinking of adding these guidelines to the README as a new section so we are all on the same page. It's a way of formalising/dumping the knowledge we've acquired while tidying up the first two modules. Did I forget anything? @tofumatt @brittanystoroz

1. remove as many dependencies as possible and make the code super simple. Right now it is using underscore and Q and the code looks too cryptic unless you're familiar with those. So far using es6-promise and Promise.all has got me covered.

2. Try to be as obvious as possible. This means, for example, not using "B2G" if we can say "simulator" instead. Another example from this module: startB2G can be renamed to startSimulator and it is so much evident what it is doing for someone who is not familiar with the moz-jargon.

3. Only expose the API via promises. Granted you internally might need to use callbacks for other modules which are not promisified, but we want to make the whole API follow the same style, so once you learn to use one module, using another node-firefox- module is easy because the interface is the same: makeACall().then(doSomethingElse).

4. No CLI binary. None of the existing examples/use cases we came up with were using the CLI, so there's either no need for that or we hate the CLI. Either way there was a lot of duplicated code between modules for doing CLI and it wasn't too consistent, and we do not have too much time for this first iteration, so no CLI for now.

5. For naming, try to be as generic as possible but also as semantic as possible. For example, if a module can be used to discover firefox and firefox OS runtimes, try to avoid adding 'os' to its name, so that it is more generic. Also consider if something sounds weird, maybe it's because we're using the wrong name. E.g. fx-simulators sounded weird until it was renamed to find-simulators. When in doubt, discuss it with more people! Don't be afraid :D (specially if English is not your first language!)

6. Use the build-tools module and gulpfile.js to lint the code.

node_modules/node-firefox-find-app/index.js:var Promise = require('es6-Promise').Promise;
node_modules/node-firefox-stop-app/index.js:var Promise = require('es6-Promise').Promise;
node_modules/node-firefox-install-app/index.js:var Promise = require('es6-Promise').Promise;
node_modules/node-firefox-launch-app/index.js:var Promise = require('es6-Promise').Promise;

es6-promise is all lowercase in npm. Figured I'd file here than 4 times on the other projects.

FireFox: when we navigate using tab, for some control left dotted border persists even if the focus is moved to next elements.

Steps to reproduce:

• write code that uses a block like this:

startSimulator({ version: '2.0' }).then(function(simulator) {
    connect(simulator.port).then(function(client) {
        // do stuff

• replace the above with something like this:

findDevices().then(forwardPorts).then(function(results) {
    connect(results[0].ports).then(function(client) {
        // do stuff

• expected result: connection to device
• actual results: Error: connect EADDRNOTAVAIL followed by inability to connect to simulator after reverting the script

Building on the existing console-logs module

FxOS has support for "bulk data" which allows apps to be installed roughly ~10x faster than the basic method.

Support for this is limited in external tools so far, but node-firefox could certainly use it! Outside of Gecko directly, I am only aware of ffdb.py offering this support.

I believe it would require changes to how connections are managed, so most of the work may happen in firefox-client, but perhaps other modules are impacted as well.

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?

This would be syntactic sugar on top of a bunch of existing modules. Not sure if you want this as a separate module but I'm using it a lot myself, so maybe there is a need.

I actually have a version already here, push-app so we would just need to transfer repo and make it node-firefox quality :P with tests and all

Right now we can just use the simulator if we want to use node-firefox modules, but gaia build system could get better if we can actually perform all this nice actions on real devices :)

Building on the existing fxos-console module

Related to @sole's question in mozilla/node-firefox-find-simulators#19, which versions of Firefox OS do we consider our "minimum supported version"?

I would think it's 1.2, as a lot of things on 1.0/1.1 devices and simulators are not easy to control remotely. We should note that in a README, but it might be best to declare it for the whole project rather than in individual module's READMEs.

I see some grammar and spelling mistakes in the md files, it would be beneficial to have some grammar/spell checking done on these documents for each pull request with travis.

While Promises are cool etc they also capture errors in a sneaky way and sometimes it's impossible to find where your error is unless you delve into the code and start console.logging like silly.

For example I was passing a wrong parameter to connect and the promise was capturing the error in getWebAppsActor call, which overall remained silent. We should review the flow of each function and make sure errors can bubble up (perhaps intentionally building errors!)

This is probably due to my own lack of experience with promises so I accept all fault already :-)

Promises can be chained, rather than nested like callbacks. That makes code much cleaner. Here's a quick sample of dirty code I'm using to exercise modules:

var path = require('path');
var fs = require('fs');

var Promise = require('es6-Promise').Promise;

var startSimulator = require('./node-firefox-start-simulator');
var connect = require('./node-firefox-connect');
var installApp = require('./node-firefox-install-app');
var findApp = require('./node-firefox-find-app');
var launchApp = require('./node-firefox-launch-app');
var uninstallApp = require('./node-firefox-uninstall-app');

var appPath = path.join(__dirname, 'node-firefox-install-app/examples/sampleApp');
var manifest = JSON.parse(fs.readFileSync(appPath + '/manifest.webapp'));

var client, simulator, appId, installedApp;

startSimulator().then(function(result) {
  simulator = result;
  return connect(simulator.port);
}).then(function(result) {
  client = result;
  return installApp({ client: client, appPath: appPath });
}).then(function(result) {
  appId = result;
  return findApp({ client: client, manifest: manifest });
}).then(function(apps) {
  installedApp = apps.filter(function (app) { return app.id == appId; })[0];
  if (!installedApp) { throw new Error('Installed app not found!'); }
  return launchApp({ client: client, manifestURL: installedApp.manifestURL });
}).then(function(result) {
  return delay(3000);
}).then(function() {
  return uninstallApp({ client: client, manifestURL: installedApp.manifestURL });
}).then(function() {
  client.disconnect();
  process.kill(simulator.pid);
  process.exit();
}).catch(function(err) {
  console.error('Error', err);
  process.exit();
});

function delay(ms) {
  return new Promise(function (resolve, reject) {
    setTimeout(resolve, ms);
  });
}

I'll probably work through the various libraries and submit PRs myself. But, here's an issue filed just in case I don't get around to it.

Building on the existing reload-css module

Is this code supposed to be MPL or Apache-licensed? A lot of the modules are Apache and that seems to be a better fit for node (also it's way more straightforward, copyleft is confusing).

Should we change the node-firefox license to Apache 2.0?

Sorry if this is obvious, but it wasn't quite clear to me after reading http://hacks.mozilla.org/2015/02/introducing-node-firefox/ how to connect a debugger (i.e. devtools) to a simulator started by node-firefox. Do I still need the webIDE to do this?

The dependency diagram in the README uses the old "fxos" module names, which make the project seem like it's not meant for desktop Firefox too.

We should update the diagram to match the new modules.

When having a properly defined table like in example shown below the Screen Reader (NVDA) fails to pick up the correct number of rows and cells when using the table browsing mode by pressing the "T" key on the keyboard.

NVDA Version
2018.1.1

Firefox Version:
16.0.1 (For Windows)

Expected behavior:
The current number of rows and cells should be read.

Actual behavior:
The table reads "0" rows and "0" columns.

Remarks
The code works on Chrome.

Sample code
Please see the following sample code with instructions on how to reproduce.
https://codepen.io/joseangel_yanez/pen/GBLVNo

I know it sounds "so simple" but it might hide complexity and prevent platform differences and that IS GOOD.

Right now for stopping a simulator in Mac OS (and Linux I hope) you need to know the process id (PID), then you just use process.kill(pid) to kill the process. If you have enough privileges (i.e. you started it, which is often the case, or have superprivileges) you kill it. Example.

But it is maybe exposing too much of the "internals", and they might also be different in Windows. It might be neat to be able to have this module so you can do things like this:

var startSimulator = require('node-firefox-start-simulator');
var stopSimulator = require('node-firefox-stop-simulator');

startSimulator().then(function(instance) {
  setTimeout(function() {
    stopSimulator(instance).then(function() {
      console.log('ok, stopped');
    });
  }, 1000); 
});

We're not exposing 'pid' at any point! And we get more promises!

I have had reports of a few people saying this project doesn't work and they cannot install apps, but none of them filed a bug report (AHEM AHEM).

Later I updated a computer and decided to go all brave and install io.js and try node-firefox. And it didn't work. I tried with the latest node which happened to be 0.12 and it didn't work either. I had to roll back to 0.10 and it did work.

Because I did all this in a hurry I didn't keep any logs and I do not know what it was exactly other than a obscure trace coming from somewhere.

If someone could take a look at this it would be really appreciated. Even if it's just to find the root of the issue.

I always forget to git tag modules when I publish them-I do remember to update package.json because otherwise npm tells me no way I'm publishing it again. There are tools for doing this automatically, perhaps even publishing to npm afterwards.

Let's use this issue to explore these tools!

Almost all of the node-firefox modules have lines like this:

var Promise = require('es6-Promise').Promise;

This fails on case-sensitive filesystems (Linux). The correct case is es6-promise.

After I made all the replacements, things seem to work surprisingly well on Linux! You might be able to update your support matrix after this change. ;)

(Example: https://github.com/mozilla/node-firefox-find-app/blob/master/index.js#L5)

FYI: The following changes were made to this repository's wiki:

• defacing spam has been removed

• Restricting write access to contributors is strongly encouraged. Please make that change (documentation).

These were made as the result of a recent automated defacement of publically writeable wikis.

We often handle the same type of "objects" when using modules in this project. They're sometimes not actual classes but just simple Objects with the same set of consistent attributes all over. A thought that often passes my mind is whether we should elevate them to their own class so we can say in the API "This call returns an object of class XYZ".

Or whether we should maybe use those objects instead of some of their properties, and hide them in the most generic case.

For example, if start-simulator would return an instance of Simulator option instead of returning a simple object, then we could also pass said instance to connect, instead of passing a port number, which requires you to know the name of the field (.port).

I have to write other modules now but I wanted to leave this here before I forget or move to another thing. I might come back with more thoughts/examples. Feel free to discuss/tell me why/if I'm wrong here :-)

What if node-firefox had an index.js like this?

// node-firefox/index.js
module.exports = {
  findPorts: require('node-firefox-find-ports'),
  findDevices: require('node-firefox-find-devices'),
  forwardPorts: require('node-firefox-forward-ports'),
  findSimulators: require('node-firefox-find-simulators'),
  startSimulator: require('node-firefox-start-simulator'),
  connect: require('node-firefox-connect'),
  findApp: require('node-firefox-find-app'),
  installApp: require('node-firefox-install-app'),
  uninstallApp: require('node-firefox-uninstall-app'),
  launchApp: require('node-firefox-launch-app'),
  reloadCss: require('node-firefox-reload-css')
};

Then, a developer could just include node-firefox in dependencies and use var firefox = require('node-firefox'); to make calls like firefox.findPorts(). Or, even make shorter aliases like var findPorts = firefox.findPorts to cut down on redundant firefoxes everywhere.

Just as we'll have find-app and install-app (formerly fxos-deploy). It feels like a natural feature to have!