User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0 Build ID: 20170816210634 Steps to reproduce: Run this program: RemoteToGeckoServerFirefoxSeleniumExample.java https://gist.github.com/nddipiazza/9c1eb6ca91b667f53d6998fd475b67f3 Against this HTML page that has a hard loop in the <script> in the body: javascript_timeout.html https://gist.github.com/nddipiazza/249eaacaec3e4068b61a87fc8c711ae4 Actual results: It will never timeout and the web driver will hang indefinitely. Expected results: Should have hit the pageLoad timeout then timed out.

So the problem here is that the test page is blocking the event loop. Usually we show the slow script warning dialog users can stop such a script. But with Marionette we disable it. As such we lock us out ourselves, which is unfortunate. But we can't enable that preference because of the modal dialog which would block the code execution in Marionette. Andreas, not sure how we want to handle that at the moment. If we would have the working alert/dialog handling code (bug 1279211) we should be able to enable the pref, and close the dialog before executing the next command. Maybe we simply have to wait for that?

(In reply to Henrik Skupin (:whimboo) from comment #1) > So the problem here is that the test page is blocking the event > loop. Usually we show the slow script warning dialog users can > stop such a script. But with Marionette we disable it. As such we > lock us out ourselves, which is unfortunate. But we can't enable > that preference because of the modal dialog which would block the > code execution in Marionette. > > Andreas, not sure how we want to handle that at the moment. If we > would have the working alert/dialog handling code (bug 1279211) > we should be able to enable the pref, and close the dialog before > executing the next command. Maybe we simply have to wait for > that? I don’t think user prompt handling is in any way useful for addressing this. The slow script dialogue is not a user prompt recognised by WebDriver. You are right that we want to handle this more elegantly, but I’m not sure what the right primitive is for aborting an unresponsive web content script implicitly.

I was able to work around this issue by surrounding the webDriver get() method in an Executor with its own timeout. And when the timeout does happen, make sure to 1) Stop the GeckoDriverService instance using the "stop()" method. and 2)Quit the RemoteWebDriver instance using the "quit()" method. private static final ExecutorService THREAD_POOL = Executors.newCachedThreadPool(); private static <T> T timedCall(Callable<T> c, long timeout, TimeUnit timeUnit) throws InterruptedException, ExecutionException, TimeoutException { FutureTask<T> task = new FutureTask<T>(c); THREAD_POOL.execute(task); return task.get(timeout, timeUnit); } try { int returnCode = timedCall(new Callable<String>() { public Integer call() throws Exception { webDriver.get("the url"); } }, timeout, TimeUnit.SECONDS); } catch (TimeoutException e) { driverService.stop(); webDriver.quit(); }

The work-around I posted above was very bad because it leaves a geckodriver + firefox open using 100% CPU, even though you asked for them to be killed.

Please also see bug 1391594 which can cause a similar behavior even during shutdown.