Skip to content
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

Hanging Culerity driver #99

Closed
wincent opened this issue Jul 7, 2010 · 7 comments
Closed

Hanging Culerity driver #99

wincent opened this issue Jul 7, 2010 · 7 comments
Labels

Comments

@wincent
Copy link
Contributor

wincent commented Jul 7, 2010

Just noticed this hanging issue with the new Celerity prerelease (the 0.8.0 beta):

http://github.com/jarib/celerity/issues/#issue/23

The workaround is apparently to add @_browser.close in the at_exit handler for the Culerity driver.

Do you think we should apply this to Capybara now? Or wait for an upstream fix? (No comments on the HtmlUnit ticket, so not even sure if they consider it a bug or not.)

Cheers,
Wincent

@jnicklas
Copy link
Collaborator

I'm very confused as to what's going on here and where exactly the problem lies :S

@wincent
Copy link
Contributor Author

wincent commented Jul 11, 2010

Apparently, the root problem is this bug in HtmlUnit. As you know, Celerity is a wrapper for HtmlUnit and it comes with a bundled snapshot of the HtmlUnit jars, which means that in a recent update to Celerity, when the latest HtmlUnit was pulled in from upstream, the bug started to manifest itself.

I see it in my RSpec/Steak/Capybara/Culerity/Celerity workflow as spec runs which complete successfully (0 failures) but never actually fully exit because the JVM just sits hanging, waiting for something...

The workaround is to call @_browser.close explicitly in the at_exit handler. The Celerity author thinks that the right place to put the workaround is not actually in Celerity, but possibly in either Capybara or Culerity. I myself am not sure.

All I know is that if I change this in Capybara's Culerity driver from:

@_browser = ::Culerity::RemoteBrowserProxy.new self.class.server, {:browser => :firefox, :log_level => :off}
at_exit do
  @_browser.exit
end

To:

@_browser = ::Culerity::RemoteBrowserProxy.new self.class.server, {:browser => :firefox, :log_level => :off}
at_exit do
  @_browser.close
  @_browser.exit
end

Then the hanging goes away.

It seems a workaround of some kind needs to go in somewhere, because the HtmlUnit team seems pretty slow to respond on this issue (look at the date on that issue tracker ticket linked above, and the lack of response).

I don't know. Do you think this extra @_browser.close call should go in Capybara's Culerity driver? Or should it be happening somewhere inside Culerity itself?

@jnicklas
Copy link
Collaborator

Does this break when used with the current stable version of celerity? If it doesn't, then there's no harm in adding that extra call, imho.

@wincent
Copy link
Contributor Author

wincent commented Jul 11, 2010

Let me just check now...

@wincent
Copy link
Contributor Author

wincent commented Jul 11, 2010

Ok, just rolled back from Celerity 0.8.0.beta.1 to Celerity 0.7.9 and it seems that the extra @_browser.close doesn't do any harm. Let me know if you want me to push a patch for it; already got one here in my local fork. It's just that one line addition.

@wincent
Copy link
Contributor Author

wincent commented Jul 11, 2010

Pushed it here in case you want it:

http://github.com/wincent/capybara/commits/hanging-culerity-fix

@jnicklas
Copy link
Collaborator

This was pushed a long time ago, but I seem to have forgot to close this issue.

@lock lock bot locked and limited conversation to collaborators Aug 18, 2019
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

2 participants