NIcholas DiPiazza Reporter
	Description • 7 years ago

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.

	Henrik Skupin [:whimboo][⌚️UTC+1]
	Comment 1 • 7 years ago

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?

	Andreas Tolfsen ❲:ato❳
	Comment 2 • 7 years ago

(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.

	NIcholas DiPiazza Reporter
	Comment 3 • 7 years ago

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();
}

	NIcholas DiPiazza Reporter
	Comment 4 • 7 years ago

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.

	Henrik Skupin [:whimboo][⌚️UTC+1]
	Comment 5 • 7 years ago

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