New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ability to preload Selenium's browser #295

Closed
wants to merge 2 commits into
base: master
from

Conversation

Projects
None yet
3 participants
@leonid-shevtsov

leonid-shevtsov commented Mar 6, 2011

I made this quick patch to be able to spawn Firefox in the Spork.prefork block.

It's quite simple:

Spork.prefork do
  Capybara::Driver::Selenium.preload_browser
end

then in tests the Selenium driver reuses the preloaded browser instead of creating a new one.

Upside: shave seconds off test startup time.
Downside: Firefox takes up memory all the time.

This goes well with running headless to background the browser; I initially planned to add it to the preloader as an option, but decided that's out of the driver's responsibility.

@joliss

This comment has been minimized.

Collaborator

joliss commented Mar 7, 2011

That's a great idea, though there's actually three serious-ish problems right now:

  • If I hit Ctrl+C twice on the client (I always need to press Ctrl+C twice for some reason -- the first one doesn't do anything), the browser terminates, so now spork needs to be restarted. That's not very helpful behavior. It seems to be the at_exit hook that's being run if the client terminates due to SIGINT. I think we shouldn't be setting up at_exit like that if we're preloading.
  • When I Ctrl+C the spork server, the browser gets killed, but now I have a stale 7MB webdriver-profile20110307-16263-1dnr07s directory lingering in /tmp. These accumulate after a while, so that's a problem -- we should be handling termination (i.e. SIGINT) properly on the server and cleanly quit the browser instance.
  • If I initialize a Driver::Selenium instance (e.g. to use Chrome) but also call preload_browser, the options (like :browser => :chrome) will be silently ignored. Maybe this can be a documented shortcoming, but I wonder if there's a better way to handle this -- perhaps a cache mapping option hashes to browser instances or so.
@leonid-shevtsov

This comment has been minimized.

leonid-shevtsov commented Mar 7, 2011

Thanks for the comments, I'll look into it.

@jnicklas

This comment has been minimized.

Collaborator

jnicklas commented Mar 10, 2011

I actually think that the last issue Jo pointed out is quite serious. We can't preload the browser like this, because it's actually not a very realistic way of opening the browser. Considering that, I'm against this getting merged.

I played with Spork a bit recently, didn't really get it all to work, due to some database transaction issues. But I came up with something like:

Spork.prefork do
  Capybara.current_driver = :selenium
  Capybara.current_session.visit('/')
  Capybara.use_default_driver
end

Obviously this isn't something we can add to Capybara, since it's very specific to a particular application and to using Spork, but it's not a lot of code, and kind of a simple concept.

I'll close this for now, but I'm open for a continued discussion.

@leonid-shevtsov

This comment has been minimized.

leonid-shevtsov commented Mar 10, 2011

Well actually I ended up with about the same solution at first, but it didn't work out so well. Somewhy capybara doesn't reuse the browser after the fork.

I'll create a blank rails app and test the whole setup there.

Regarding the Ctrl+C issue: the problem is not at_exit, it's probably the consequences of interrupting Webdriver. The temp files don't get cleared because the browser isn't terminated properly.

@jnicklas

This comment has been minimized.

Collaborator

jnicklas commented Mar 10, 2011

You need to make sure it's the same session object, which is why something like Capybara::Session.new(:selenium, Capybara.app).visit('/') which seems like the obvious solution isn't going to work.

@joliss

This comment has been minimized.

Collaborator

joliss commented Mar 11, 2011

Ah, thanks for posting this, Jonas -- that's much better and simpler of course.

It still suffers from the problem that interrupting the client kills the browser, like the original patch, which makes it pretty unusable even as a hack.

In case anyone cares about pursuing this further:

It seems that when you interrupt the client, the browser is indeed getting yanked by the at_exit handler. Removing the at_exit handler in Capybara allows the browser to continue to run even after the spork client was interrupted. However, the next time you run the tests, the browser gets reused but the tests still fail because, for some reason, the JavaScript doesn't run in the browser anymore. Manually navigating around in the browser instance reveals that JS only gets executed if I hit the reload button, but not if I navigate to a page by hitting enter in the location bar or by clicking a link. It's totally weird, I've never seen anything like this.

Unrelatedly, I tried trapping SIGINT, and it doesn't work at all if I'm running spork, neither in the client nor in the server. (Without spork, it works fine.) I think Spork overrides the signal handler after I define it.

At this point, I'm not inclined to dig deeper, but I just thought I'd post this anyway in case someone else wants to.

This issue was closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment