Reliably load freedom modules

[agallant]

@trevj filing this as an issue as unfortunately it's dragging beyond the scope that is ideal for email.

Right now this test runner works for its basic self-tests, and also works with https://github.com/freedomjs/freedom-pgp-e2e (which loads a freedom module that loads another freedom module).

However, for some not-entirely-certain reason, it's not playing nicely with uproxy-lib testing (which also loads freedom modules), nor does it pass with this simple test: https://github.com/trevj/grunt-jasmine-firefoxaddon-test

The error tends to be uninformative, along the lines of "error loading resource" (referring usually to the .js part of the freedom module). Things that I've investigated and mostly ruled out:

• The addon build process (i.e. the copying of files, the inserting of require statements into them, etc.)
• browserify pulling in things beyond jasmine and the specfiles (es6-promise, freedom-for-node, etc.): freedom-pgp-e2e does get freedom-for-node and its dependencies pulled in but that's just browserify being zealous, removing it cuts down the generated spec.jsm but still runs/passes
• Requiring/importing the same things in different places (e.g. freedom-for-firefox.jsm in the index, promises in the spec, etc.)

My best theory at the moment is some sort of browserify-related black magic that changes what is visible where - either that or some particularly hidden policy setting to allow the addon to see what it needs (since the files are indeed in the right place).

[agallant]

@trevj, while I still can't say why it doesn't work in your branch/repo, I got it running in uproxy-lib with this branch: https://github.com/uProxy/uproxy-lib/tree/soycode-grunt-jasmine-firefoxaddon

I'm starting to suspect that maybe trying to make these super-minimal demos of it end up trying to run things as freedom modules that aren't really functional freedom modules. In any case, let me know your thoughts on that branch, and if that approach seems to work we can extend it to the other tests.

[trevj]

We're getting warm! It's not browserify. It's something to do with terminating the test before the freedomjs module has had a chance to load and do something. Here's a branch that fixes my minimal test: https://github.com/trevj/grunt-jasmine-firefoxaddon-test/compare/trevj-fix?expand=1

Does this make any sense to you? It's fun to hack around with: if you change the spec to call done() immediately, without waiting for the ping from the module, you will get a policy error. Totally bizarre.

[agallant]

Interesting - so I guess the question is if there's any sensible change within grunt-jasmine-firefoxaddon to mitigate this, or if we just say that these are module-side problems. It'd be hacky but the runner could just have some sort of pause to wait for things to load - for now though no "good" solution springs to mind.

[trevj]

I can't think of a way to mitigate it either (that said, I don't fully understand the problem) so I think documenting it is fine. Adding a sample might help, too, to illustrate (feel free to steal mine).

[agallant]

SGTM, I'll add a section to the README and link to your repo. Thanks!