Bug #84350 for Test-WWW-Selenium: Hung WWW::Selenium, waiting for the Selenium server response to a 'getNewBrowserSession' command

Dear Matt and Luke, I have an application which is invoked by a scheduler, i.e., unattended. Attached is a demo version of it, which very reliably reproduces the problem, under the right conditions, detailed below. It uses: * Test::WWW::Selenium ver. 1.35 * WWW::Selenium ver. Ver.1.35 * Test::Builder Ver. 0.98 * Test::More Ver. 0.98 * LWP::UserAgent Ver. 6.02 * HTTP::Request Ver. 6.00 * HTTP::Headers Ver. 6.05 * URI::Escape Ver. 3.31 * Time::HiRes qw(sleep) Ver. 1.9725 * Firefox ver. 19.0.2 (attached its "Troubleshooting Information", as copied from Firefox) * run with perl v5.14.2 built for MSWin32-x64-multi-thread (with 1 registered patch, see perl -V for more detail) Binary build 1402 [295342] provided by ActiveState http://www.ActiveState.com, Built Oct 7 2011 15:19:36 * on a Windows-7 Pro (x64) machine (System info file attached) After a long time (a day or two) of no use, but definitely, with 100% repeatability, after a boot up, it ALWAYS hangs and times out with a 500 status code. I traced the point at which it is hung to the very first HTTP request to the Selenium server with the cmd = 'getNewBrowserSession', line 117, of the 'do_command sub. It results from the call to the 'new' method of 'WWW::Selenium' package, via the methods-chain 'start' -> 'get_string' -> 'do_command'. When in the hanging conditions I listed above (i.e., after boot-up, or after long inactivity), the HTTP request remains un-answered. It then times out after the 3 minutes of LWP's User_Agent + the extra wait you added in the 'ua' sub. Also with 100% repeatability, once I abort both the Selenium server and the Perl client and restart the application, it NEVER hangs(!) What seems as a work-around the problem is to place a 2 seconds 'sleep' between the system() call that fires up the Selenium server and the "$sel = Test::WWW::Selenium->new()" call. My guess (educated I hope...) is that the "system ($selenium_call_string)" returns a bit too soon, before it is really ready to accept commands. That's why It hangs after a boot up. It works the second time around probably because Selenium is still memory resident. And again, it hangs after a long time of Selenium inactivity because it was purged from memory. Can you verify that? Regards, Meir Guttman