Scripted Browser: Attempts to interact with elements fail
When validating a monitor created in an older runtime against the Chrome 100 (or newer) runtime, findElement and other methods to find and interact with elements on the page may fail due to promise handling differences. If the monitor passes in a legacy runtime, fails in the new runtime, and the element is present in the screenshot, you may need to improve your promise handling logic.
Selenium WebDriver promise manager / control flow allowed some functions to execute in order in legacy runtimes, without managing promises. This capability was removed in Selenium WebDriver 4.0 and is no longer available in the runtime. All async functions and promises need to be managed with await
or with .then
promise chains. This will ensure script functions execute in the expected order.
For example, promise manager / control flow could allow this partial script to complete successfully, even though $browser.get returns a promise and the promise is not being handled correctly:
$browser.get('http://example.com');
$browser.findElement($driver.By.css('h1'));
In the the Chrome 100 (or newer) runtime, any methods that return a promise need to use await or .then syntax to properly sequence steps. Using await is recommended due to cleaner syntax and easier usage, but .then promise chains are still supported too.
await $browser.get('http://example.com');
let el = await $browser.findElement($driver.By.css('h1'));
Scripted API: Differences between request
and got
The Node.js 10 and older scripted API runtimes used the request
Node.js module to provide a $http
object that could be used to test APIs.
The Node.js 16 and newer scripted API runtimes use got
instead of request
. The request
module was deprecated in 2020 and will no longer be included in new API or browser based runtimes. The $http
object provides a custom request
-like experience while being powered by got
to provide backward compatibility for basic use cases while still avoiding the use of a deprecated module. Not all advanced use cases of request
are or will be supported. Script examples and a conversion guide are available.
Tip
The request
-like experience provided by the $http
object will also be returned for any customers attempting to use request
directly in Node.js 16 and newer scripted API runtimes.
Scripted API: Unexpected token JSON.parse errors
Attempting to use the JSON.parse
function while interacting with the response body may produce unexpected token errors in scripted API monitors using the Node.js 16 and newer runtime. If the content-type response header is application/json
, the response body being returned by the $http
object will be parsed JSON. Additional calls attempting to use JSON.parse
to parse the response body will fail with this error because the response body has already been parsed.
Scripted Browser: Deprecation warnings ($browser / $driver)
Deprecation warnings for $browser
and $driver
were removed starting with the 2.0.29 or newer version of the browser runtime. You should no longer receive these warnings when using public locations. Please update your node browser runtime image if you are receiving these warnings when using private locations.
Scripted Browser: waitForAndFindElement and waitForPendingRequests
The waitForAndFindElement
and waitForPendingRequests
methods are New Relic custom methods that are provided in the Chrome 72 and older scripted browser runtimes. They can still be used with $driver
and $browser
in the Chrome 100 and newer runtimes, but they will not be available when using the Selenium WebDriver 4.1 APIs directly with $selenium
and $webDriver
. This change will better align New Relic's Selenium WebDriver implementation with the base Selenium WebDriver implementation.
Customers who choose to continue using waitForAndFindElement
or waitForPendingRequests
in the new runtime can paste code examples into their monitors.