You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Although there is a specific Selenium::Remote::ErrorHandler package, which provides structured error data, the current Selenium::Remote::Driver returns a multiline, which lacks some information and forces the user to interpret text.
For example:
Error while executing command: getElementTagName: An element command failed because the referenced element is no longer attached to the DOM.: stale element reference: element is not attached to the page document
(Session info: chrome=58.0.3029.110)
(Driver info: chromedriver=2.29.461571 (8a88bbe0775e2a23afda0ceaf2ef7ee74e822cc5),platform=Linux 4.11.0-rc7 x86_64) (WARNING: The server did not provide any stacktrace information)
Command duration or timeout: 94 milliseconds
For documentation on this error, please visit: http://seleniumhq.org/exceptions/stale_element_reference.html
Build info: version: '3.3.1', revision: '5234b32', time: '2017-03-10 09:04:52 -0800'
System info: host: 'zalenium', ip: '172.18.0.2', os.name: 'Linux', os.arch: 'amd64', os.version: '4.11.0-rc7', java.version: '1.8.0_131'
Driver info: org.openqa.selenium.chrome.ChromeDriver
Capabilities [{applicationCacheEnabled=false, rotatable=false, mobileEmulationEnabled=false, networkConnectionEnabled=false, chrome={chromedriverVersion=2.29.461571 (8a88bbe0775e2a23afda0ceaf2ef7ee74e822cc5), userDataDir=/tmp/.org.chromium.Chromium.aCHkWZ}, takesHeapSnapshot=true, pageLoadStrategy=normal, databaseEnabled=false, handlesAlerts=true, hasTouchScreen=false, version=58.0.3029.110, platform=LINUX, browserConnectionEnabled=false, nativeEvents=true, acceptSslCerts=true, locationContextEnabled=true, webStorageEnabled=true, browserName=chrome, takesScreenshot=true, javascriptEnabled=true, cssSelectorsEnabled=true, unexpectedAlertBehaviour=}]
Handling this is difficult for it lacks the only really meaningfull value, the tagname.
Providing structured and complete, whenever possible, errors would really help.
The text was updated successfully, but these errors were encountered:
I seem to recall this message is simply what is passed to us by the selenium server itself. I can double check, but having encountered this error several times myself, that seems to be the recollection.
In any case, the workaround here is to add an error handler to simply re-try getting the target lock on the element -- I have a function I've used as an error handler callback that does precisely that. Such might be valuable to include in the distribution as an optional parameter.
We could also provide more context to the error_handler by providing the arguments and maybe letting it assign the return_value if it handled the error. Something like:
around '_execute_command' => sub {
my $orig = shift;
my $self = shift;
# copy @_ because it gets lost in the way
my @args = @_;
my $return_value;
try {
$return_value = $orig->($self,@args);
}
catch {
if ($self->has_error_handler) {
$return_value = $self->error_handler->($self,$_,@args);
}
else {
croak $_;
}
};
return $return_value;
};
Although there is a specific Selenium::Remote::ErrorHandler package, which provides structured error data, the current Selenium::Remote::Driver returns a multiline, which lacks some information and forces the user to interpret text.
For example:
Handling this is difficult for it lacks the only really meaningfull value, the tagname.
Providing structured and complete, whenever possible, errors would really help.
The text was updated successfully, but these errors were encountered: