Troubleshooting Assistance

• 1: Understanding Common Errors
• 2: Logging Selenium commands

1 - Understanding Common Errors

Invalid Selector Exception

CSS and XPath Selectors are sometimes difficult to get correct.

Likely Cause

The CSS or XPath selector you are trying to use has invalid characters or an invalid query.

Possible Solutions

Run your selector through a validator service:

• CSS Validator
• xPath Validator

Or use a browser extension to get a known good value:

• SelectorsHub

No Such Element Exception

The element can not be found at the exact moment you attempted to locate it.

Likely Cause

• You are looking for the element in the wrong place (perhaps a previous action was unsuccessful).
• You are looking for the element at the wrong time (the element has not shown up in the DOM, yet)
• The locator has changed since you wrote the code

Possible Solutions

• Make sure you are on the page you expect to be on, and that previous actions in your code completed correctly
• Make sure you are using a proper Waiting Strategy
• Update the locator with the browser’s devtools console or use a browser extension like:
  • SelectorsHub

Stale Element Reference Exception

An element goes stale when it was previously located, but can not be currently accessed. Elements do not get relocated automatically; the driver creates a reference ID for the element and has a particular place it expects to find it in the DOM. If it can not find the element in the current DOM, any action using that element will result in this exception.

Common Causes

This can happen when:

• You have refreshed the page, or the DOM of the page has dynamically changed.
• You have navigated to a different page.
• You have switched to another window or into or out of a frame or iframe.

Common Solutions

The DOM has changed

When the page is refreshed or items on the page have moved around, there is still an element with the desired locator on the page, it is just no longer accessible by the element object being used, and the element must be relocated before it can be used again. This is often done in one of two ways:

• Always relocate the element every time you go to use it. The likelihood of the element going stale in the microseconds between locating and using the element is small, though possible. The downside is that this is not the most efficient approach, especially when running on a remote grid.

• Wrap the Web Element with another object that stores the locator, and caches the located Selenium element. When taking actions with this wrapped object, you can attempt to use the cached object if previously located, and if it is stale, exception can be caught, the element relocated with the stored locator, and the method re-tried. This is more efficient, but it can cause problems if the locator you’re using references a different element (and not the one you want) after the page has changed.

The Context has changed

Element objects are stored for a given context, so if you move to a different context — like a different window or a different frame or iframe — the element reference will still be valid, but will be temporarily inaccessible. In this scenario, it won’t help to relocate the element, because it doesn’t exist in the current context. To fix this, you need to make sure to switch back to the correct context before using the element.

The Page has changed

This scenario is when you haven’t just changed contexts, you have navigated to another page and have destroyed the context in which the element was located. You can’t just relocate it from the current context, and you can’t switch back to an active context where it is valid. If this is the reason for your error, you must both navigate back to the correct location and relocate it.

2 - Logging Selenium commands

Each language adopts a distinctly different approach to logging information about the activity of the program.

Ruby

Ruby uses a custom implementation of the default Logger class with some interesting additional features.

Logger output

By default, logs are sent to the console in stdout. if you want to store the logs in a file, add this to your code:

Selenium::WebDriver.logger.output = '/path/to/selenium.log'

Logger level

The basic levels for the Ruby logger are: :debug, :info, :warn, :error, :fatal

Selenium uses :info and :debug similar to “verbose” and “very verbose”, so the default is :warn.

To change the level of the logger:

Selenium::WebDriver.logger.level = :fatal

WARN

Warnings include everything we want users to be aware of by default. This is mostly used for deprecations. For various reasons, Selenium project does not follow standard Semantic Versioning practices. Our policy is to mark things as deprecated for 3 releases and then remove them. As such, Ruby logs deprecations as warnings, specifying what is changing, what needs to be used instead. It may include additional messages, and always includes an ID.

For example:

2022-12-24 16:07:09 WARN Selenium [DEPRECATION] [:jwp_caps] `Capabilities#version=` is deprecated. Use `Capabilities#browser_version=` instead.

Because these items can get annoying, we’ve provided an easy way to turn them off.

To turn off a specific warning, set the ID to ignore:

Selenium::WebDriver.logger.ignore(:jwp_caps)

It accepts an Array to turn off multiple IDs:

Selenium::WebDriver.logger.ignore(%i[jwp_caps pause pauses])

To turn off all deprecation notices:

Selenium::WebDriver.logger.ignore(:deprecations)

INFO

This is where the most useful information gets logged. Selenium logs the endpoints and payloads sent to and received from the driver or server. This is a great way to see what Selenium is actually doing under the hood, and can be used to determine if it is Selenium code or driver code that is causing a problem. (Unfortunately, we can’t blame the driver if Selenium is sending incorrect syntax).

DEBUG

This is less useful information where we log things about the servers and the sockets, and header information, etc. Debug mode is set if either $DEBUG is true or ENV['DEBUG'] has a value.