I've tried to run my tests with Selenium 2 and Firefox 19. One of this tests causes an error "ERROR: Command execution failure. The error message is: can't access dead object".
I'm reading about it, it seems like a bug in newest Firefox's versions. Lot of people have the same issue, but I've not found anything really clear.
Any heroe can help us? Maybe we just need to change something in "about:config"?
Regards
I was desperate about the same Problem and didn't find any solution although many people seemed to have the same problem.
I solved it by calling
webDriver.switchTo().defaultContent();
before calling any findElement method
(using Java)
This error generally comes when you do no switch back from frame and trying to access web elements directly.
Use driver.switchTo().defaultContent(); and then try to access the elements
I finally made a "cheat" to the browser.
I got the fail when Selenium clicked on a link and try to open the new page. What I've made is just simulate the click, doing a selenium.open("URL") which replace selenium.click("link=ButtonWhichOpenTheURL").
It seems to work by the moment
I am facing the same error on Firefox 23 while reopening a pop up browser window. The only workaround I did is closing the current selenium session and relaunching it again. It worked fine for me.
Related
Hello i've some trouble about windows managing with Watir gem in Ruby.
I've working with watir '6.2.1' until I finished to write my program, and I always got an error that is "Element is not clickable at point (x, y)..." never at the same location, whereas really nothing was on the button that i want to focus.
In this case, i just needed to update watir to don't have this error again.
I think that this error was resolved, but i've the same error, that I already had, when i want to click exactly in the same location as before.
Before i've update watir to the last update, i used
browser.window.resize_to(1366, 786), it's worked and i did not have the error anymore.
Now, it's not working. My window does not resize anymore.. When i put back the old version, it's the same issue.
I'm sorry about my bad english, i hope that you understand what i want to explain.
Most likely you need to update your chromedriver. I get bit by that every so often because the browser will update automatically and without alerting you to that fact.. So it's not uncommon to have the browser get 'ahead' of chromedriver and things stop working or start working in strange weird ways until you realize what is going on and update chromedriver.
It worked until today, no code got changed
So if I do something like
page.find('#edit-user').native.send_keys(:tab, :tab) it's not working (it's highlighting the element #edit-user but not moving forward) specifically for the tab key, it's working correctly for :space or :enter.
It was working previously, it's a small possibility that it's related to some settings change for the Chrome browser but not sure exactly how and why
We are having this problem in Chrome as well, and it all started with Chrome update 44.
I tried using "\t", :tab, :return, :enter, and :escape to remove focus from a text input (symbols found here), but none of them are working in the most recent version of Chrome.
I know you mentioned you are not looking for solutions other than tab, but short of rolling back your browser version and disabling updates, or waiting for the possibility of a fix from Google itself, you will have to change the scripts being executed.
We found that this has worked well so far:
driver.execute_script("document.activeElement.blur()")
If the desired behavior in your case is to shift focus two fields forward, then you might consider another Javascript solution that looks something like what is discussed in this thread:
simulate the tab key function in javascript
Of course, this probably isn't the best long term solution, as even some very quick Googling shows that sending a tab key to switch focus has been recommended tons of times to people using WebDriver. Because of this, I'm keeping my fingers crossed there will be another Chrome update to revert the behavior.
I'm currently (trying) to develop an app with Worklight Studio 5.0.6 and Dojo (Mobile) 1.8.3. I have a really hard time to to find a proper method for debugging. After waiting 5-10 minutes for the build an deploy-process on the server, an error usually looks like this in the Chrome debugger:
How am I supposed to track down this error in MY source? The whole stack trace consists entirely of Dojo code which generates an absolutely useless error message after 20 abstraction layers.
Seriously, how do you guys handle this in real life? What methods do you use for debugging Dojo-driven apps in the browser?
spyro
For dojo.parse errors, I find it useful to pause the Chrome debugger on all exceptions (the purple icon on your screenshot, should be blue). You usally get more details about the cause of the error, the name of the DOM node being parsed, etc. in the first exception being raised.
Rémi.
Debugging dojo based application should be the same as debugging any javascript application.
Usually I will follow these steps:
add console.log() somewhere in code: this is fast and most of time this is enough.
set breakpoint in debugger: if step 1 is not enough, you can base on error information to set breakpoint before error line, then step in or step out.
comment out recently changes: for some error which is hard to find the error line, for example, parse error in your case, the good way is comment out your recently changes one by one till back to your last working version. Or, return to your last working version, then add code back one by one.
Create a simple application to reproduce the error : if your application is very complicate and it is hard for you to follow above methods, you can try to create a new application which mimics your current application but with simple logics and try to reproduce the error.
Based on experience : Some errors, for example, extra ',' in the end of array which works at chrome and firefox, will report a nonsense error information at IE. Debug these kinds of errors is very difficult, you can base on your experience or do a google search.
Did you provide isDebug: true in your dojoConfig? Also, try to see if the same occurs in other browsers.
Update: I recently discovered that there are issues with Google Chrome and Dojo debugging and I think it has to do with the asynchronous loading of files. As you can see in the provided screenshot of #spyro, the ReferenceError object is blank (which you can notice because of the empty brackets {}). If you want to solve that, reopen the console of Google Chrome, (for example by tapping F12 twice). After reopening the ReferenceError should not be empty anymore and now you can expand that object by using the arrow next to it and get a more detailed message about what failed.
Usually what I do in situations like that is to place a breakpoint inside the error callback (line 3398 in your case) and then look into the error variable ("e").
I am not sure how familiar you are with the Web Inspector, but once you hit the breakpoint open the Web Inspector 'console' and check for the error properties "e.message" and "e.stack" (just type in "e.message " in the console).
Also, during development it is better to avoid Dojo optimization / minification, which greatly improve your debug-ability.
Bottom line is to try to place the breakpoint before the error is thrown.
n00b here. After searching the forums I have not yet come across this problem as I am experiencing it.
I have a CI site that was working correctly until about three days ago. My problem is as follows:
On button click - Page Loads correctly.
On Enter press - CI Blank Page of Death loads.
For example: When I login, after the login process has run it must reroute me to the Dashboard, unless I still have a temporary password where I get rerouted to the "Change Password" screen first and then to the Dashboard.
AS LONG AS I USE THE BUTTONS AND CLICK THEM EVERYTHING WORKS.
On ENTER PRESS, I get the Blank Screen of Death.
However, on TAB to BUTTON and then ENTER it works.
The problem is not consistent however. I have some processes that do not have views attached and NONE of them will run - hit ENTER and get blank. They are all failing on ENTER PRESS.
I am slowly going off my trolley. Logging is ON, Directories for cache and logs are 775. NOTHING is showing in my logs...
First Try to active error handlers for displaying of errors for addittional info to post here what error is occuring..
// change settings for error handler to show errors
// $this setup is used for checking errors for development to be shown....
ini_set('display_errors', 1);
error_reporting(E_ALL);
by the way if your using CI version 2 higher
you can see it in its index.php file an configuration for displaying error also.
define('ENVIRONMENT', 'development'); //just set up environtment to development
Even though there are accepted answers I wanted to add a way that worked for me to figure out this problem.
Usually the "Blank Page" indicates a PHP parsing error somewhere in the code. Strange thing for me was that on my local MAMP based test server the code ran fine. I FTP it to my hosted server and all of a sudden, blank page of death.
Even though I had errors on, log errors on, display errors on, nothing appears in any log file.
I was able to find the error by a funny little trick. I added an echo line in CodeIgniter.php in the system/core. Obviously hacking the core was not a great idea but all I wanted to do was to see how far it was getting in the load process.
When my echo appeared after trying to load a page on the remote hosted server it also displayed the parsing problem in a derived controller! Not sure why the error did not come out without the "echo" added. But adding it seemed to trigger some output to be generated, IE my echo line and the PHP parse error was appended.
Not sure if this will help anyone but it turned out to be a nice easy way to find the error which only showed on the remote server.
Obviously, don't forget to put your core file back to its original state without the echo.
This was fixed by copying the application into a fresh CI 2.3 install.
I have no idea what actually caused this "erratic" behaviour.
The application worked correctly as designed whenever a BUTTON was CLICKED but gave the blank death screen when ENTER was PRESSED.
This inconsistent behaviour is what threw me. The fact that my logs (CI and APACHE) also showed nothing was also very strange. Had this been a parse error, surely the behaviour on "Click" and on "Enter Press" should have been the same.
My non-view controllers for various ad-hoc admin jobs are now also working correctly, which they were not before, as they use "Enter Press" (having no buttons to "Click").
I am still going to invite best guesses as to why this behaviour occurred the way it did.
Surely someone out there (Phil Sturgeon et al) with extensive CI experience has encountered this non-consistent blank screen behaviour and knows what caused it.
Thank you to all the people who took the time and effort to assist me!!!
Big UP!!! StackOverflow!!!
probably error in INCLUDE login.php
My problem was Apache stop working because of ...Skype! Skype actually work on the same 443 and Apache didn't start! I hate this Skype! Bring me nuts for a while.
Installing php5-pgsql worked for me
I am using a dedicated test SL web application that hosts SL object I am debugging.
I am debugging using basic F5 and use browser Google Chrome. Sometimes a bug happens, how I reproduce it.
I was running build->debug like 100 times already, but then I made a mistake that caused StackOverflowException and happened in main page constructor and afterwards when I rebuild and hit F5 it says no symbols have been loaded. Note that NOTHING has changed , I use the same 2 buttons combinations rebuild solution-> start debugging.
In order for debug to continue to attach I need to close XAML main page , open it again (in visual stuido) and hit rebuild ->f5 again, afterwards it works fine. (found this solution after SOME time)
I am not sure whats bugged but it appears to be a bug somewhere in SL to me.
Question is - whats going on maybe someone can explain.
This sounds more like Chrome's isolation mode for plug-ins. Generally speaking it's best to manually attach to the Chrome process that is running Silverlight (which isn't always one VS attaches to when pressing F5).
Actually error was super simple, I wasn't understanding how "exactly" xap works, it was a little more magical to me than it is. I just needed to rebuild & clear cache in browser ( chrome in this case) to attach successfully. For some reason I thought that local version doesn't require clear cache call.
Actually chrome is pretty bad to debug silverlight so I recommend IE for this sole purpose, sometimes debugger simply fails to attach to chrome, in that case you usually need to do this by attach to process - choose chrome with silverlight name there.