15:44:00 koha_1 | STRACE: /usr/share/perl5/Try/Tiny.pm:123 in Selenium::Remote::Driver::catch {...} 15:44:00 koha_1 | /usr/share/perl5/Selenium/Remote/Driver.pm:361 in Try::Tiny::try 15:44:00 koha_1 | (eval 2020):1 in Selenium::Remote::Driver::__ANON__ 15:44:00 koha_1 | (eval 2022):2 in Selenium::Remote::Driver::__ANON__ 15:44:00 koha_1 | /usr/share/perl5/Selenium/Remote/Driver.pm:712 in Selenium::Remote::Driver::_execute_command 15:44:00 koha_1 | t/db_dependent/selenium/administration_tasks.t:180 in Selenium::Remote::Driver::accept_alert 15:44:00 koha_1 | 15:44:00 selenium_1 | 1729518016380 Marionette INFO Stopped listening on port 46675 15:44:00 selenium_1 | JavaScript error: resource:///modules/Interactions.jsm, line 230: NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIUserIdleService.removeIdleObserver] 15:44:00 selenium_1 | 13:40:17.451 INFO [ActiveSessions$1.onStop] - Removing session 3ec3997e-064a-48e2-9ea2-f77f391fcf82 (org.openqa.selenium.firefox.GeckoDriverService) 15:44:00 koha_1 | Error while executing command: no such alert at /usr/share/perl5/Selenium/Remote/Driver.pm line 411. 15:44:00 koha_1 | at /usr/share/perl5/Selenium/Remote/Driver.pm line 356. 15:44:00 koha_1 | # Looks like your test exited with 255 just after 3. 15:44:00 koha_1 | [13:40:17] t/db_dependent/selenium/administration_tasks.t ..............................
selenium/authentication_2fa.t had a similar failure (bug 32010)
It run 300x successfully locally.
It was Koha_Master/3063
(In reply to Jonathan Druart from comment #1) > selenium/authentication_2fa.t had a similar failure (bug 32010) But because of an AJAX request, what we do not have here.
In case that helps, I'm able to reproduce this ``` t/db_dependent/selenium/administration_tasks.t:179 in Selenium::Remote::Driver::find_element Error while executing command: no such element: Unable to locate element: //input[@name="id"][@value=""]/following-sibling::button at /usr/share/perl5/Selenium/Remote/Driver.pm line 411. ``` It's the line just before the: $s->driver->accept_alert; # Accept the modal "Are you sure you want to delete this authorized value?"
(In reply to Victor Grousset/tuxayo from comment #5) > In case that helps, I'm able to reproduce this How? Can you provide the screenshot of the problematic screen ?
> How? I'm just running the test in a loop. 3 such failures in 48 runs. > Can you provide the screenshot of the problematic screen ? Screenshot capture is broken in some failures. I had a patch to fix it that I added to a selenium ticket 6mo/1y ago. But it was mixed with other changes to testing process t/lib/Selenium.pm and ultimately wasn't retained. I'll try to find it.
Koha_Main/3075
(In reply to Victor Grousset/tuxayo from comment #7) > > How? > > I'm just running the test in a loop. > 3 such failures in 48 runs. I got 300 successes in a row :-/ > > Can you provide the screenshot of the problematic screen ? > > Screenshot capture is broken in some failures. I had a patch to fix it that > I added to a selenium ticket 6mo/1y ago. But it was mixed with other changes > to testing process t/lib/Selenium.pm and ultimately wasn't retained. I'll > try to find it. I don't understand. Could you add a capture_screenshot call before the failure and see how is the screen? $driver->capture_screenshot( 'test.png' );
(In reply to Jonathan Druart from comment #9) > (In reply to Victor Grousset/tuxayo from comment #7) > > Screenshot capture is broken in some failures. I had a patch to fix it that > > I added to a selenium ticket 6mo/1y ago. But it was mixed with other changes > > to testing process t/lib/Selenium.pm and ultimately wasn't retained. I'll > > try to find it. > > I don't understand. Could you add a capture_screenshot call before the > failure and see how is the screen? > > $driver->capture_screenshot( 'test.png' ); Oh right! I though it was about the screenshot taken on failure. So, after 6 failures in 188 runs fail: https://lutim.lagout.org/8oEY7SVs/K9Vz9RK2.png ok: https://lutim.lagout.org/gZ6IQwAu/f9MjqAoL.png And turns out we are in a case where selenium_failure.png is managed to be taken. And it the same image as a success! It seems that the list of AVs hasn't loaded yet when it fails. And when selenium_failure.png is taken, the page has finished loading. Which is weird because Selenium is supposed to wait for the load event to be fired/document.readyState===complete. And find_element() is supposed to wait until a timeout before failing. Given that the runtime of the failed run is 10 sec more than a good run, it seem it waited. But then somehow it didn't find the element, failed and the screenshot just after shows a loaded page. Random Selenium bug? >_< Anyway, does the screenshots give any hint? code change to take screenshot: > @@ -176,6 +176,7 @@ SKIP: { > [...] > #$driver->find_element('//input[@id="'.$av_id.'"]/following-sibling::button[text() = >"Delete"]')->click; >+$driver->capture_screenshot( 'test.png' ); > $driver->find_element('//input[@name="id"][@value="'.$av_id.'"]/following-sibling::button')->click; > $s->driver->accept_alert; # Accept the modal "Are you sure you want to delete this authorized value?"
It will take less time to rewrite those tests using cypress than debug them...
Could you remove this code and see if it still fails? 433 $("#Aform").submit(function() { 434 if ( $('#authorised_value').length ) { 435 if ( ! $('#authorised_value').get(0).checkValidity() ) { 436 alert( _("Authorised value should be numeric.") ); 437 $('#authorised_value').focus(); 438 return false; 439 } 440 } 441 return true; 442 });
(In reply to Jonathan Druart from comment #11) > It will take less time to rewrite those tests using cypress than debug > them... +1, as soon as bug 38503 makes it, I'll try to be able spend labor time rewriting tests. Oh, it's in need signoff! I'll look at it ASAP! *jumping from excitement* > Could you remove this code and see if it still fails? 4 fail in 155 runs 🫠🫠🫠
(In reply to Victor Grousset/tuxayo from comment #13) > (In reply to Jonathan Druart from comment #11) > > It will take less time to rewrite those tests using cypress than debug > > them... > > +1, as soon as bug 38503 makes it, I'll try to be able spend labor time > rewriting tests. Bug 38503 won't help much here.
Yep, looking at the diff there, I just finally realized that mock means mock. And not touching the DB. 😅😅😅😅🤦 Anyway it's still a big win to be able to more easily test the front end. > won't help much here It might be coping and delusion but [to be continued in bug 29285 comment 4]
Koha_Main/3153 on Docker_15