saveToFile no longer required about jasmine-reporters

[putermancer]

Thanks. I took a look this evening at what it would take to support the newer version. It looks like the page is now run in a sandbox that does not have access to the "phantom" object. The current approach enables the loaded webpage (ie the HTML test runner) to directly write to files via phantom.writeToFile. It looks like in 1.3.0 I would have to move the fs functions outside of the loaded webpage and into the JS file that is actually run by Phantom.

Does that sound correct, or am I missing something? As nice as sandboxing can be, in this case it will certainly make the reporter less straightforward as it will not be able to perform all actions directly.

Is there a better way?

Does that sound correct, or am I missing something?

That sounds correct.

Is there a better way?

AFAIK there isn't any easier way. The only solution I'm aware of is doing as much processing in the webpage as possible (page.evaluate), then, passing messages (simple object responses) back and forth between phantom and the page, and communicating that way. That's about as easy as it can be, until we find a better method to do this without compromising security.

P.S. Argument passing to page.evaluate is very difficult at the moment. casperjs currently has a pretty good way of doing it, if you ever need to do this. Take a look at line 266 and line 1327.

[putermancer]

With argument passing to page.evaluate being difficult, what is the appropriate way to pass messages back and forth? I can see how the phantom script can force the loaded page to do work and return simple data objects to the phantom script using page.evaluate, but I do not see how the loaded page could initiate communication to the host script.

Is there some postMessage support that I am missing, or is what I describe above what you meant by passing simple object responses back and forth -- in that it must always be initiated by the phantom-loaded script?

This example might help better explain it... Hopefully it answers your questions! Basically, evaluate will return when all the code inside evaluate is done, so you just use return on anything you need. I know it can get really messy and complicated however; we're looking for ways to improve this, but it could take awhile.

A postMessage solution would be pretty nice, but could also be a vulnerability (sadly), since any script inside the page could use it and could post false messages back. We would have to get into patching QtWebKit itself to possibly fix that stuff, which could take awhile; and this would only really work with PhantomJS, and I don't know what we would do for PyPhantomJS regarding that. :/

var page = require('webpage').create();

page.onConsoleMessage = function(msg) {
    console.log(msg);
}

function replaceFunctionPlaceholders(fn, replacements) {
    if (replacements && typeof replacements === "object") {
        fn = fn.toString();
        for (var p in replacements) {
            var match = '%' + p + '%';
            do {
                fn = fn.replace(match, replacements[p]);
            } while(fn.indexOf(match) !== -1);
        }
    }
    return fn;
}

page._evaluate = page.evaluate;
page.evaluate = function(fn, replacements) {
    return page._evaluate(replaceFunctionPlaceholders(fn, replacements));
}

page.open('http://foobar.baz', function(status) {
    // do some stuff

    var passThis = 'somedata...';
    var res = page.evaluate(function() {
        // do some in page processing

        var somedata = '%myData%';

        if (somedata === 'somedata...') {
            // success in processing something
            return True;
        } else if (somedata === 'fail...') {
            // failed to process something...
            return False;
        }

        // returning some string or message
        return 'some message containing a result';
    }, {
        myData: passThis
    });

    if (res === True) {
        console.log('we succeeded!');
    }

});

[putermancer]

Wow, yes, I see what you mean by difficult. Ultimately it's just rewriting the function and passing that in as text...

But thanks for the example, it got me thinking / playing. I can kludge this by using page.evaluate to inject a writeFile function into the global scope (or wherever) which stores filename=>data in a randomly-named hash; the host script can then check for the presence of data in that hash and, if found, do the work itself to write them out to disk. Definitely a kludgy solution but prototyping looks like it will work just fine, while still preventing the Jasmine runner script from knowing what is going on behind the scenes.

It restricts the jasmine reporter to writing files out via Phantom only if it is executed by a host script that injects / takes care of proxying the writeFile requests to fs.write but there are worse things.

Of course, this begs the question "is it worth it to upgrade from 1.1.0 to 1.3.0 in light of the required workaround." But I suppose since jasmine-reporters is intended as a helper library, I should probably bite the bullet and do the legwork to support the new version / bugfixes / features.

Not very often I feel like telling someone... thanks for the example and ideas for a horrendous, yet functional, hack.

[putermancer]

Resolved in 058612c