Good morning!
We released Selenide 7.3.1.
It’s a tiny release, so it will be easy to upgrade. Let’s start the unboxing:
- Mock response with specific content type
- Fixed method
$.clear()
in mobile - Fixed error message when clicking an invalid link
- Disabled Chrome warning about stolen password
- Fix CDP downloading for custom webdrivers
- Deprecated setting
holdBrowserOpen
- Upgraded Selenium from 4.19.1 to 4.20.0
- Statistics
Mock response with specific content type
As you know, Selenide allows to mock server response using its built-in proxy server:
getSelenideProxy().responseMocker().mockText("cik-mock",
urlStartsWith(GET, "https://cik.ru/api/gov/no/referendum"),
() -> "{votes: 2133326, for: 99.23, against: 0.77}");
You could specify any response content, but not type. But sometimes the type is important.
Now you can specify any headers for the mocked server response, including Content-Type
:
import org.openqa.selenium.remote.http.HttpResponse;
getSelenideProxy().proxyMocker().mockResponse("cik-mock",
urlStartsWith(GET, "https://cik.ru/api/gov/no/referendum"), () -> new HttpResponse()
.setStatus(429)
.addHeader("Content-Type", "application/json")
.setContent(utf8String("{votes: 2133326, for: 99.23, against: 0.77}"))
);
See issue 2705 and PR 2706.
Fixed method $.clear()
in mobile
… for an element that exists in DOM, but not visible (or interactable).
It turns out that calling clear
or click
on mobile apps:
$("#hiddenElement").clear();
Failed with an incorrect message if the element is found, but not visible (for example, covered by another element):
Element should be interactable {By.name: ComputeSumButton}
Element: '<XCUIElementTypeButton ... visible="false">...
Caused by:
UnsupportedCommandException:
Unhandled endpoint: /session/28...13/element/07000000-0000-0000-CF35-000000000000/css/opacity ...
Now the message will be correct, without any UnsupportedCommandException
:
Element should be visible {By.name: ComputeSumButton}
See issue 2722 and PR 2723.
Fixed error message when clicking an invalid link
A similar problem. If you try to click an invalid link in Firefox (for example, https://zopa
):
$("#invalid-link")
.shouldHave(attribute("href", "https://zopa"))
.click();
then Selenide generated an misleading error message:
Element not found {#link}
Expected: clickable: interactable and enabled
Now there will be an honest error text:
WebDriverException: Reached error page: about:neterror?e=dnsNotFound&u=https%3A//zopa/
Build info: version: '4.20.0', revision: '866c76ca80'
P.S. Interestingly, only Firefox produces this error. Other browsers calmly display a standard page with a text like this:
This site can’t be reached
Check if there is a typo in example.
DNS_PROBE_FINISHED_NXDOMAIN
See issue 2725 and PR 2727.
Disabled Chrome warning about stolen password
Again. We already disabled this annoying prompt in PR 2662, but there
we added only setting profile.password_manager_enabled=false
which was not enough. Now we also added
setting profile.password_manager_leak_detection=false
.
See PR 2729.
Fix CDP downloading for custom webdrivers
As you remember, few months ago we implemented another file downloading mechanism via CDP. Obviously, it works only in Chromium-based browsers.
But in case of custom webdrivers, the check “is this a Chromium” didn’t work:
Configuration.fileDownload = CDP;
Configuration.browser = MyCustomChromedriverFactory.class.getName();
File report = $("#report").download();
// threw an error: java.lang.IllegalArgumentException:
// The browser you selected "MyTest$CustomWebDriverProvider" doesn't have Chrome Devtools protocol functionality.
Now Selenide properly detected Chromium-based browser using their actual capabilities.
Thanks Petr Ovcharenko for PR 2728.
Deprecated setting holdBrowserOpen
Selenide has setting holdBrowserOpen
: when set to true
, Selenide will not close the browser after finishing the tests.
Sometimes people want to leave the browser opened to debug/investigate there something.
I personally never liked this feature, and now we’ve got a good reason to remove it. Suddenly we realized that the feature is harmful. When you finish the debugging and manually close the browser, nobody closes the webdriver. It will be hanging and consuming resources indefinitely.
Now flag holdBrowserOpen
is deprecated. As a replacement, you can just add sleep(600_000)
in your test - and the browser will stay opened for a long time.
See PR 2730.
Upgraded Selenium from 4.19.1 to 4.20.0
I don’t see too much changes in Selenium changelog, so nothing to fear. :) Among others, they added CDP 124 and removed 121.
See PR 2726.
Statistics
It happened!!!
The number of monthly downloads of Selenide has exceeded … a million!
selenide.org
28.04.24