Understanding how the event loop works with browser.wait

[Alistair Dutton]

I'm new to zombie and I've been trying out some tentative tests with it. Something I noticed was the tests were significantly slower than I expected. The "test" looked something like this:

        this.browser.visit('http://localhost:9000/test-index.html', function () { // assert on stuff });

The "boot" sequence for the SUT spits out progress to console along with timings and, combined with timestamping when the zombie browser "done" event was called I could see around a 500ms delay between the end of the boot sequence and zombie "done" event being fired.

Looking at the zombie code I can see that such a browser.visit has an implicit "wait until the event loop is clear". So, I tried using a completion function instead:

        this.browser.visit('http://localhost:9000/test-index.html');

        this.browser.wait(function (window) {

            window.browser.dump();

            return window.browser.query("li");

        }, callback);

This immediately eliminated the ~500ms overhead.

So what was the browser doing for the next 500ms until the "done" event was called? To that end I added the browser dump in the "wait" completion function above. But the event loop in the resulting dump was empty.

So, are there any thoughts on what might account for that ~500ms overhead? (I suspect that it might be my nascent understanding of zombie that's the problem here.) 

(Great idea for getting the browser to wait until the event loop is clear by the way!)

Thanks,

Alistair 

[Assaf Arkin]

Try using the DEBUG environment variable, it will show you what the browser is doing (timers, AJAX requests, etc).

--
You received this message because you are subscribed to the Google Groups "zombie.js" group.
To unsubscribe from this group and stop receiving emails from it, send an email to zombie-js+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alistair Dutton]

Thanks for the tip Assaf. Unfortunately it doesn't make any difference that I can see.

I did try setting the debug option when creating the browser and when executing the visit but, again, it made no difference. So, just to see if I was doing something stupid I created this stupidly simple harness for running in node based on the example in the 2.0 docs:

var Browser = require('zombie');

var assert  = require('assert');

Browser.localhost('example.com', 80);

var browser = Browser.create({ debug: true });

browser.visit('/', function (error) {

  assert.ifError(error);

  console.log("DONE");

});

And I still don't get any debug output - all I get is the console "DONE" output. Setting the DEBUG environment var, again, makes no difference.

I suspect that I'm just being thick and missing something obvious. Am I looking for the debug output in the wrong place (i.e. stdout) perhaps?

Thanks,

Alistair

[Alistair Dutton]

Ah, after digging around the zombie code a bit I've found a way of switching on debug mode that *does* work for me:

var Browser = require('zombie');

Browser.debug();

I'll dig further to find out why it wasn't working from the option or env var.

[Alistair Dutton]

Ah I see now; the debug browser option was removed in September in favour of the visionmedia "debug" library.

Looking at the visionmedia/debug project I can see that I was using the DEBUG env var incorrectly too - it should be set:

export DEBUG=zombie  

[Alistair Dutton]

And of course, I didn't spot the env var setting because I was looking at the wrong version of the documentation...

[Alistair Dutton]

Anyway, back to the plot (and my original question).

The zombie debug output between the last thing executed by the SUT and the browser.visit callback being executed is:

  zombie Fired timeout after 500ms delay +478ms

  zombie Event loop is empty +1ms

So, where is that 500ms delay coming from? Is that some sort of polling interval internal to Zombie?

[Alistair Dutton]

Ok, I've tracked it down and it has nothing to do with zombie. Its caused by flatiron's director. It has this Chrome workaround in it: https://github.com/flatiron/director/blob/5f98a7c0bf8a86eea2eb176dc70c81fa70360044/build/director.js#L72

So, this means that the event loop won't be completely clear for 500ms longer than it should be. I've removed director (it was only in experimental use anyway) and the delay is gone.

However, that doesn't explain why the event loop looks empty when I do a browser.dump. (I'm doing this in my completion function - i.e. *before* the event loop is cleared.)

Having dug into the zombie code itself I can see that EventLoop.dump is hard-wired to return an empty array - that doesn't sound right but it would explain why I'm seeing no event loop. Has the event loop dump been deprecated?

[Assaf Arkin]

It’s not deprecated, just not implemented yet.

--

[Alistair Dutton]

Great, thanks for the clarification.