Investigate unhealthy tests

[Poundex]

• ParallelExecutionSpec - Flaky in CI

  
  ParallelExecutionSpec > GebReportingSpec supports parallel execution at feature level FAILED
  Condition not satisfied:
  
  reportFileTestCounterPrefixes("SpecRunningIterationsInParallel1") == (["000"] * 2) + (1..4)*.toString()*.padLeft(3, "0")
  |                                                                 |           |    |         |           |
  [000, 000, 001, 002, 003, 004, 004]                               false       |    |         |           [001, 002, 003, 004]
                                                                                |    |         [1, 2, 3, 4]
                                                                                |    [000, 000, 001, 002, 003, 004]
                                                                                [000, 000]
      at geb.spock.ParallelExecutionSpec.GebReportingSpec supports parallel execution at feature level(ParallelExecutionSpec.groovy:186)

- **PageOrientedSpec** - _Flaky in CI_

PageOrientedSpec > verify the Page API works for '#contentName' content > verify the Page API works for 'linkUsingPageInstance' content FAILED org.openqa.selenium.StaleElementReferenceException: The element seems to be disconnected from the DOM. This means that a user cannot interact with it. For documentation on this error, please visit: https://selenium.dev/exceptions/#stale_element_reference Build info: version: '4.2.2', revision: '683ccb65d6' System info: host: '075353d81e19', ip: '192.168.176.3', os.name: 'Linux', os.arch: 'amd64', os.version: '5.15.0-1057-aws', java.version: '11.0.24' Driver info: driver.version: IDataDriver at app//org.openqa.selenium.htmlunit.HtmlUnitDriver.assertElementNotStale(HtmlUnitDriver.java:899) at app//org.openqa.selenium.htmlunit.HtmlUnitWebElement.assertElementNotStale(HtmlUnitWebElement.java:591) at app//org.openqa.selenium.htmlunit.HtmlUnitWebElement.verifyCanInteractWithElement(HtmlUnitWebElement.java:249) at app//org.openqa.selenium.htmlunit.HtmlUnitWebElement.click(HtmlUnitWebElement.java:131) at app//geb.navigator.DefaultNavigator.click(DefaultNavigator.groovy:672) at app//geb.navigator.DefaultNavigator.click(DefaultNavigator.groovy:687) at app//geb.content.TemplateDerivedPageContent.click(TemplateDerivedPageContent.groovy:83) at geb.PageOrientedSpec.verify the Page API works for '#contentName' content(PageOrientedSpec.groovy:73)

- **DateInputSpec** - _Functionality broken in recent ChromeDriver_
It seems this test is failing due to broken functionality in recent versions of ChromeDriver, where setting a value of an `<input type="datetime-local" />` does not work as expected. There is some discussion of the issue on [this php-webdriver thread](https://github.com/php-webdriver/php-webdriver/issues/709). There is an [existing ChromeDriver ticket](https://issues.chromium.org/issues/42322342) but it doesn't look like it's getting fixed. A common workaround seems to be using JavaScript to set the value, rather than manipulating directly, [like in this example](https://github.com/teamcapybara/capybara/blob/e8874a1cbc3e967b74621fb243c0ae514625900f/lib/capybara/selenium/node.rb#L255).

[Poundex]

After a bit more investigation into DateInputSpec it looks like that any ChromeDriver changes there might have been were a red herring, and this issue is caused by updating Java from 8 to 11. The default precision for new Temporals changed:

Java 8:

LocalDateTime.now().toString() // 2024-10-23T11:34:27.420

Java 9+:

LocalDateTime.now().toString() // 2024-10-23T11:35:29.955881121

with the former being accepted by Chrome and the latter being rejected as malformed. This test only tests strings that are the result of a LocalDateTime's toString. If the test had been testing a string with the nanosecond precision on current master with either the Chrome v78 that's in gebish/ci:v7 or modern Chrome it still would have failed.

[jonnybot0]

So, for the DateTimeLocalInput, we could address this by adding a default formatter.

    void setDateTime(LocalDateTime dateTime) {
        value(dateTime.format(DateTimeFormatter.BASIC_ISO_DATE))
    }

We could add method signatures to allow folks to specify their own formatter with relative ease, though I'm less confident that's needed.

    void setDateTime(LocalDateTime dateTime, DateTimeFormatter formatter) {
        value(dateTime.format(formatter))
    }

And, of course, they can always use the setDateTime(String iso8601FormattedDateTime) signature. That's part of what makes me think we probably don't need the formatter signature, though maybe it's a "nice to have".

[Poundex]

Sorry I missed this comment and wrote a summary of the issue here in #194 . The date time format mentioned there is the only one that will be accepted, so I don't think the custom format is useful. We could use the formatter to truncate the fractional seconds part and this looks like it's working. The JavaScript stuff turned out to be completely unnecessary (don't know if I misunderstood something or something that used to be an issue has now been fixed) so has been removed and we're back to just calling value(). Opened an MR here https://github.com/geb/geb/pull/196