Selenium & Firefox: How can i turn off “Unresponsive script” warnings?

后端 未结 7 1188
慢半拍i
慢半拍i 2021-02-05 17:42

I\'m using Selenium Client 2.4.0 on Mac 10.6.6 with Firefox 5. Using the WebBackedSeleniumDriver, I\'m running a \"selenium.getEval\" command that causes a Firefox warning,

相关标签:
7条回答
  • 2021-02-05 17:56

    dom.max_script_run_time is the right preference but it only applies to web pages. Browser UI (and extensions like fxdriver are part of it) are restricted by the preference dom.max_chrome_script_run_time however (default value is 20 seconds). You should set it to 0 as well.

    Documentation: https://developer.mozilla.org/en/Preferences/Mozilla_preferences_for_uber-geeks#DOM_preferences

    0 讨论(0)
  • 2021-02-05 18:01

    Regardless of what you have setup in your profile, during startup, Selenium sets both values to 2417483647 to try and get around the browser warning. However, because the value is so large, FF ends up ignoring it and using the default value of 10/20 instead. This is true even if you're pointing Selenium to use your profile as the template.

    The best way I've found to get around this is to specify -timeout nnnn

    to the Selenium Server startup args. This sets both the server and client (browser) timeout values.

    0 讨论(0)
  • 2021-02-05 18:01

    Although this thread is quite old, the problem still exists with current selenium and firefox builds. I've got these really annoying messages quite a long time now, without a good fix. Asking the devolopers / mailing list / google usually results in the following answer:

    The javascript used in your application is too fat or buggy, improving your scripts will help.

    As this is no option in a larger company, when you depend on a framework you have no access to, i decided to search for the root cause for myself.

    The core of the problem is the fact, that selenium overrides profile settings if you specify the -timeout nnnn parameter. So creating a custom firefox profile template and setting the dom.max_script_run_time and dom.max_chrome_script_run_time will not work here.

    As soon as you specify the -timeout parameter, these two settings are overriden with the value you provide to the parameter. After hours of debugging and testing i noticed some facts:

    • If you don't specify -timeout, firefox runs for exact 30 minutes, without one script timeout. After that, firefox gets killed by selenium with a SeleniumCommandTimedOutException
    • As soon as you specify -timeout (no matter which value), the script timeout appears after several seconds or minutes. These messages are independent to the timeout-value.
    • The -browserTimeout parameter isn't usefull as i haven't found where this parameter is used in the source.

    As we have some testsuites that run longer than 30 minutes we have 2 options to fix this behaviour:

    • Rewriting our testsuites and splitting them to run within the 30 minutes window
    • Patching selenium to run longer than 30 minutes

    Do not use the -timeout parameter.

    So choose for yourself which option is better. I created a small and simple patch for the HTMLLauncher.java to allow 90 minutes instead of the default 30.

    diff --git a/java/server/src/org/openqa/selenium/server/htmlrunner/HTMLLauncher.java b/java/server/src/org/openqa/selenium/server/htmlrunner/HTMLLauncher.java
    index c2296a5..310b39f 100644
    --- a/java/server/src/org/openqa/selenium/server/htmlrunner/HTMLLauncher.java
    +++ b/java/server/src/org/openqa/selenium/server/htmlrunner/HTMLLauncher.java
    @@ -146,6 +146,16 @@
         launcher.launchHTMLSuite(suiteURL, browserURL);
    
         sleepTight(timeoutInMs);
    +    // SFR, Patch 2013-10-17: To get rid of the damn SeleniumCommandTimedOutException
    +    // we allow the Suite to run 3 times as long as per default (30 min -> 90 min).
    +    if(results == null) {
    +      log.warning("SFR, Patch 2013-10-17");
    +      sleepTight(timeoutInMs);
    +    }
    +    if(results == null) {
    +      log.warning("SFR, Patch 2013-10-17");
    +      sleepTight(timeoutInMs);
    +    }
    
         launcher.close();
    

    I'll upload a pre-compiled jar with the above patch if necessary.

    0 讨论(0)
  • 2021-02-05 18:04

    Go the hidden configuration page in Firefox by typing about:config in the address bar . (make sure that you are doing this for the profile you are using for selenium) In the 'Filter' box, type script_run_time. This will narrow the options to dom.max_script_run_time and dom.max_chrome_script_run_time. Right-click it and choose Modify. A box pops up. Change the number to something bigger like 40. This is the maximum time a script can run before Firefox considers it 'unresponsive'. If you can’t find the string in the about:config page, create it by right-clicking anywhere and then choose New—> Integer and enter there name and values (when asked)

    0 讨论(0)
  • 2021-02-05 18:08

    The dom.max_script_run_time setting is in seconds. Changing it from 10 to 20 just doubles the amount of time to wait. A value of 0 will disable it, but this could result in a run-away script locking up your browser. You might just use a really large value.

    More details here:

    http://kb.mozillazine.org/Dom.max_script_run_time

    0 讨论(0)
  • 2021-02-05 18:12

    This issue appears for me when I do Selenium calls while web application is running some own crappy slow JS. Even if I catch the popup and retry after few seconds, FF is not responsive to Selenium anymore. The solution is to just put sleep 10 before otherwise any Selenium call would result in popup.

    0 讨论(0)
提交回复
热议问题