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
For the Selenium test, the chosen approach is to have a Docker container with a running Chrome browser. The browser is then remote controlled by the tests in scripts/test/Selenium running e.g. on the otobo_web_1 container. The Chrome image is taken from Docker Hub, https://hub.docker.com/r/selenium/standalone-chrome. The tag '3' is used for selecting which version of the image is used.
However the Selenium tests started to break today, 2021-06-10. The cause was an update of the tag '3' on 2021-06-08. The tag 3 is now equivalent to 3.141.59-20210607. I could not find a good log of what has changed in 3.141.59-20210607. My assumption is that it is related to recent changes for chromedriver 91. See https://janmolak.com/chrome-91-might-break-your-tests-507309b9b2cd.
The obvious solution is to go back to the working solution, this would be 3.141.59-20210422. This quick fix is handled in a separate issue.
The real issue is that there is a cause for the breakage. One error was in scripts/test/Selenium/Agent/Admin/AdminACL.t
my $StoredDescription = 'a' x 200;
$Self->Is(
$Selenium->find_element( '#Description', 'css' )->get_value(),
$StoredDescription,
"#Description stored value",
);
find_element() works just fine, it returns the wanted Node. The method Selenium::Remote::WebElement->get_value()is implemented as "Query for the value of an element, as determined by its value attribute.". If I understand the code correctly, then the implementation sends a request for getElementAttribute to chromedriver. This looks sane indeed, but the HTML actually looks like: <textarea id="Description">aaaa...aaa</textarea>
There is no attriibute called value only the text of the textarea. What is then actually returned:
3.141.59-20210422: aaaa...aaa and the test succeeds
3.141.59-20210607: empty string and the test fails
According to the documentation of Selenium::Remote::Driverthe latter behavior is correct. meaning the two errors have been cancelling each other previously.
So, adapting to the fixed behavior seems to be the right thing, but let's wait what the fallout of this mess will be.
scripts/test/Selenium/Agent/Admin/AdminACL.t
The text was updated successfully, but these errors were encountered:
bschmalhofer
changed the title
Make Selenium tests work with latest version of selenium/standalone-chrome:3
Make Selenium tests work with latest version of selenium/standalone-chrome
Oct 5, 2023
I looked into this and found that development for Selenium 3 has stopped in 2021. 3.141.59-20210929 is the last released version. Development for Selenium has continued with Selenium 4, which uses a better protocol that was standardized by W3C.
https://github.com/teodesian/Selenium-Remote-Driver#warning recommends moving to Playwright.
Moving to Playwright is beyond the scope of this issue. Putting work into Selenium 3 is IMHO not worth the effort. So let's mark this issue as wontfix and close it.
For the Selenium test, the chosen approach is to have a Docker container with a running Chrome browser. The browser is then remote controlled by the tests in scripts/test/Selenium running e.g. on the otobo_web_1 container. The Chrome image is taken from Docker Hub, https://hub.docker.com/r/selenium/standalone-chrome. The tag '3' is used for selecting which version of the image is used.
However the Selenium tests started to break today, 2021-06-10. The cause was an update of the tag '3' on 2021-06-08. The tag 3 is now equivalent to 3.141.59-20210607. I could not find a good log of what has changed in 3.141.59-20210607. My assumption is that it is related to recent changes for chromedriver 91. See https://janmolak.com/chrome-91-might-break-your-tests-507309b9b2cd.
The obvious solution is to go back to the working solution, this would be 3.141.59-20210422. This quick fix is handled in a separate issue.
The real issue is that there is a cause for the breakage. One error was in scripts/test/Selenium/Agent/Admin/AdminACL.t
find_element() works just fine, it returns the wanted Node. The method
Selenium::Remote::WebElement->get_value()
is implemented as "Query for the value of an element, as determined by its value attribute.". If I understand the code correctly, then the implementation sends a request for getElementAttribute to chromedriver. This looks sane indeed, but the HTML actually looks like:<textarea id="Description">aaaa...aaa</textarea>
There is no attriibute called
value
only the text of the textarea. What is then actually returned:According to the documentation of
Selenium::Remote::Driver
the latter behavior is correct. meaning the two errors have been cancelling each other previously.So, adapting to the fixed behavior seems to be the right thing, but let's wait what the fallout of this mess will be.
scripts/test/Selenium/Agent/Admin/AdminACL.t
The text was updated successfully, but these errors were encountered: