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,
"Warning: Unresponsive script.
A script on this page may be busy, or it may have stopped responding. You can stop the script now, or you can continue to see if the script will complete.
Script: resource://fxdriver/modules/utils.js:9161"
The value of "dom.max_script_run_time" about:config was "0", which should disable the above dialog altogether. Yet, I still get the dialog. Is there any way to prevent the warning dialog from appearing?
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
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.
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.
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)
Set it to a very large number instead of "20"?
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
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.
Related
Here's the problem. I get a message that pops up that says, "one or more extensions cannot be verified and have been disabled". I know a temporary fix to get these apps working again but the apps always break after so much time. What I do is go in my extensions for my Firefox profile (which is a JSON file) and I use Wordpad to change all the instances of appDisabled": true to appDisabled": false. I also change all the instances of signedState":-1 to signedState":2. The problem is that it keeps changing the false back to true and the 2's back to -1's. I am using Firefox version 56.0.2. Is there any permanent fix that can keep these changes under the current version that I am using? I am getting sick and tired of having to make these changes every day. Also, a couple of key add-ons that I use which are Classic Theme Restorer and unblock Origin keep getting disabling from this issue. I value these add-ons and I would love it if you knew any command prompt that I could put into Wordpad that would make Firefox stop trying to verify add-ons or whatever it does that causes Firefox to disable the add-ons. I welcome any other fix as well. I do want to keep my current version of Firefox and I know the Greasemonkey I use wouldn't work on later versions.
I already tried using Wordpad to change all instances of appDisabled": true to false and signedState":-1 to 2. It would work for a while and then everything reverted back to how it was.
...
appDisabled":true
...
signedState":-1
When appDisabled is true and signedState switches to -1, I get the message saying, "one or more extensions cannot be verified." It also disables the incompatible apps.
I'm automating some reports using visual basic. I've recorded some scripts that worked fine by seem to have stopped working for reasons unknown. I record the following (comments added) and the script fails at a file dialog box.
session.findById("wnd[0]").resizeWorkingPane 95,22,false
session.findById("wnd[0]/tbar[0]/okcd").text = "se16"
session.findById("wnd[0]").sendVKey 0
' Run AGR_TCODES
session.findById("wnd[0]/usr/ctxtDATABROWSE-TABLENAME").caretPosition = 10
session.findById("wnd[0]").sendVKey 0
'Select Extended Name, Multiple selection
session.findById("wnd[0]/usr/btn%_I3_%_APP_%-VALU_PUSH").press
session.findById("wnd[1]").sendVKey 23
' select file
session.findById("wnd[2]/usr/ctxtDY_PATH").text = "c:\my_directory\"
session.findById("wnd[2]/usr/ctxtDY_FILENAME").text = "myfile"
session.findById("wnd[2]").sendVKey 0
Its at this point in script playback that the script just stops with the file select text inputs blank. I can type the information in, but that kinda defeats the purpose. I can't find the reasons or a cause, but lots of various upgrades have occurred, including my laptop and a reinstall of the os to WIN10. I don't really care why - but I do need to find a way around it.
There are 2 scenarios I've identified:
It appears that SAP occasionally loses the focus of dialog boxed. Use gratuitous .setfocus commands on the window to compensate
It appears that uploads via scripts may be blocked by security settings. You can do it manually, but not via script. A telltale sign is that when you record the script, your inputs are not recorded. So the DY_FILENAME.text line will be completely missing from the recording. I'm not sure how to fix this, but at least you know where to look!
Good luck with your scripts.
I am running program which open "chromium-browser" with following command-line parameters in Linux.
--incognito = Causes the browser to launch directly in incognito mode. ↪
--no-first-run = Skip First Run tasks, whether or not it's actually the First Run. Overridden by kForceFirstRun.
This does not drop the First Run sentinel and thus doesn't prevent first run from occuring the
next time chrome is launched without this flag.
--disable-save-password-bubble
--password-store = Specifies which password store to use (detect, default, gnome, kwallet).
--password-store=basic
--no-default-browser-check = Disables the default browser check. Useful for UI/browser tests where we want to avoid having
the default browser info-bar displayed.
--window-size = Specify the initial window size: --window-size=w,h
--window-size=1024,1024
--app = Specifies that the associated value should be launched in "application" mode.
Now I want to do the same thing with "firefox" browser. I need help to find firefox command-line parameter for firefox which is similar to chromium-browser.
I searched firefox website but not able to find alternatives for same.
Try to look them up here Mozilla - Command Line Options remember: Mozilla is the umbrella organisation of firefox, thunderbird, ... so this looks like the normative documentation place - the reality check then will be the installed binary, but then you can file issues in the tracker (if an option similar to these needed by you is documented but does not work).
Update 2021-08-30: Note that the options page is in archive status and there may be non-listed options available or listed options missing with newer versions. Until the Mozilla / Firefox project comes up with a maintained manual page on these options a good way to ensure what options are supported is to call firefox on the command line with the --help parameter.
You can try to check this one
this works as of 21/10/21
You would also want to look at the '-kiosk' argument
(similar to the chromium '--app' arg) which isn't really documented in the pages referenced in other comments here.
https://support.mozilla.org/en-US/kb/firefox-enterprise-kiosk-mode
I have some cucumber tests made using the gem 'cucumber-rails'.
This tests use another gem called 'page-objects' (from cheezy) and in my tests I use Selenium and Chrome-driver.
To make the tests run in the Jenkins server (that has no X) I use the gem 'headless' and I've configured the server to use Xfvb (my local machine runs Elementary OS Freya 0.3.2 and the server runs Ubuntu 15.10).
When I run these tests in my local machine (also using headless), they all pass flawlessly every time. The same happens when I run the tests in Jenkins' server from the Terminal.
But when I run them on Jenkins CI, some fail (the error is "didn't find an element" - when the element is there).
Both tests fail because it cannot find an element (the element exists and when it fails I print the screen just to check what's happening. The page print show that it is on the right page and displays the element).
The strange thing is that they both fail at the second step (the first one is going to the login page and authenticate, which it does correctly). Also, there's another test that runs first that always passes (the tests have pretty much the same structure).
Both tests run over the same server (the webpage they access is the same and the data is the same).
I have looked at this over and over and I can't find any explanation. I know the problem is not very detailed, so if there's anything missing that might be important, just tell me and I'll update the post.
If you happen to know any reason why the tests might fail on a 'Xless' server, I would greatly appreciate it!
Thanks a lot for the help!
Edit:
The failures are both "element not found" and the element is present.
I've also made the Jenkins user part of the sudoers.
Any ideas?
Thanks a lot
The only way to solve these issues is to debug the error received. To debug, we can add screenshots at different places in the scenario to identify the cause of the failure. If this is failing as page not completely loaded, then to solve this issue, is to increase the default wait time to open the particular page or to locate an element. Once the page loads or element is located, set the default time to its original value.
Example:
1. You can add screen shot in you scenario:
Scenario: Click on Sign In Link
Given Joe opens "www.yahoo.com" page
When Joe takes screenshot with file name "ScreenShot1"
When Joe clicks "Sign In" link
The second line "When Joe takes screenshot with file name "ScreenShot1" can be used to take the screen shot
And(/^(\S*) takes screenshot with file name "([^"]*)"$/) do |user, file_name|
takes_screenshot_with_file_name(file_name, "ScreenShot")
end
def takes_screenshot_with_file_name(file_name, message)
page.save_screenshot("../../target/#{file_name}.png", :full => true)
end
Default wait time can be increased in below mentioned way:
The second line "And Joe waits for "Sign In" link" can be used to increase the default wait time
Scenario: Click on Sign In Link
Given Joe opens "www.yahoo.com" page
And Joe waits for "Sign In" link
When Joe clicks "Sign In" link
And(/^Joe waits for "([^"]*)" link$/) do |linkName|
Capybara.default_wait_time = 120
page.should have_content(linkName)
Capybara.default_wait_time = DEFAULT_WAIT_TIME
end
Things you can try:
Reduce the test to the very basics: Instead of running it all, just that concrete page and try to find that element. Check if that works. It probably won't...but you can pinpoint better the problem.
Add some waits in the code (sleep <number of seconds>), to see if your code is trying to find something "too fast". This happens time to time.
Instead of using headless, try to use something else and run it in a browser (with some gems like capybara you can switch between headless, firefox or chrome).
Can you find some sort of JS logs, to see if there are any errors?
Do Jenkins and your environment have exactly the same gem versions?
Another thing you can do to debug it is use something like byebug and set a breakpoint just before it fails. You can then use the interactive console to inspect the page, and run different commands to try to find the element. You would have to do this while in jenkins, but as a last resort...
Ok, so I found out the problem and the solution.
The problem was that the elements were still not loaded when performing their lookup. The solution was to use PageObject.wait_until to wait for them.
I realized that this was the problem after noticing the errors were sometimes these ones: Stale Element Reference
But there's a question that remains, still: why does this only happen in Jenkins CI? (whoever finds the solution will earn the bounty :) )
Our continuous integration process uses Selenium, and twice in the last few months it has been knocked out of action thanks to firefox updating itself (either on developer machines or the CI server).
We have therefore installed the previous firefox version alongside the later one (this time in a directory called firefox-16), until Selenium catches up.
The problem is, the app.update.auto setting (in about:config) is set to true by default - meaning that sooner or later it will update itself to 17 and selenium will break. We therefore installed an all-no-update.js file in the /usr/lib/firefox-16/defaults/pref folder containing
user_pref("app.update.auto", false);
which (according to MDN) should override any other values. Unfortunately it doesn't work - the about:config page still shows auto-update as app.update.auto as true. This MDN page says:
All Mozilla-based applications read (application directory)/defaults/preferences/*.js
but unfortunately that doesn't work either - the value stays unchanged.
I've trawled the Bugzilla database but can't find anything relevant (other than the fact that an all.js file gets deleted by an upgrade so be sure to use all-*.js file).
Does anyone know enough about the workings of Mozilla Firefox to tell me how to set this preference value? (please don't say "click on the about:config page" - it needs to be automatically to ensure the build is repeatable and stable).
Thanks, James
Edit:
Sorry if the above isn't clear: I can create default preferences, for newly created profiles, just fine. But as users already have a profile this won't have any effect. I could possibly create a new profile on every machine, for every user, that has this setting disabled - but it is a lot of overhead. Sysadmins all over the world must be using this functionality somehow, surely: a way to override a given preference with a centrally-set one?
The most likely reason is using user_pref() function - as the name already says, this one is reserved for user's preferences (in user's profile), default preferences should use pref() instead.
You also have to consider that whatever you put into this directory are default preferences, they can be overridden in the browser profile (in the file prefs.js there). If you aren't using a clean profile the preference can already be set there and the default won't have any effect then.
For reference: A brief guide to Mozilla preferences
From MDN: Enterprise Deployment (Configuration)
Some config items require lockPref to be set, such as app.update.enabled. It will not work if it set with just pref.
Suspect this may apply to app.update.auto as well. Although I can find no obvious (i.e. named update) configuration option in about:config that is specific to any given add-on. So I don't even know if the per-add-on setting is a pref?