Fix optional element stale reference handling

In this release, I decided to add unit tests for optional element behavior, especially as this relates to nodes that appear and vanish after the creation of the corresponding RobustWebElement. In the process, I discovered a few bugs and logic issues in this area.

• If the reference attached to an optional element went stale and couldn't be refreshed (element not found), a second fruitless attempt was made to acquire the reference. Now the failed refresh is detected and the original StaleElementReferenceException is thrown.
• Handling of element reference refresh timeouts was incorrect:
  • If the refresh was performed to recover from a stale reference exception, the code was simply re-throwing timeout. Now the original stale reference exception is repackaged to indicate the refresh failure.
  • If the refresh was just acquiring an element reference (not stale reference exception recovery), the timeout was improperly transformed into a refresh failure exception. Now the cause of the timeout is re-thrown instead.
• If we failed to locate an element using the SCRIPT strategy, the message in the NoSuchElementException failure incorrectly referred to a locator and index that don't apply to this strategy. Now we refer to the script and context element as we should.
• I added a bunch of code comments in these areas so I don't have work so hard figuring out how this code works next time.
• I added two new unit tests to keep an eye on this functionality,
• I also added final qualifiers to the "locator" fields in all of the Using enumerations.

Revert PhantomJSDriver to version 1.4.4

In this release, I fix what I broke...

In the last release of Selenium Foundation, I upgraded the version of the PhantomJSDriver dependency to version 1.5.0, failing to notice that this new release targets Selenium 4. Reverting to version 1.4.4 gets PhantomJS support working again.

Update several more dependencies

In this release, I updated several more dependencies:

• HTTPClient: 4.5.13 → 4.5.14
• JSoup: 1.15.1 → 1.15.3
• OKHttp: 4.9.3 → 4.10.0
• WebSocketClient: 9.4.46.v20220331 → 9.4.50.v20221201
• Kotlin: 1.7.0 → 1.8.10
• PhantomJSDriver: 1.4.4 → 1.5.0

Update to latest releases of core dependencies

In this release, I upgraded to the latest releases of the following:

• SettingsAPI: 3.0.2 → 3.0.5
• JUnit Foundation: 17.0.2 → 17.0.4
• TestNG Foundation: 4.0.2-j8 → 4.0.4-j8

Upgrade HtmlUnit to v2.70.0

In this release, I upgraded to the latest release of HtmlUnitDriver (v2.70.0). The dependencies of this new release changed slightly, which necessitated a few minor tweaks to HtmlUnitPlugin.

This is the first official release of Selenium Foundation after I removed the parallel Maven project files. These are no longer useful, as I finally added the last missing capabilities to the Gradle project files for Selenium Foundation. I've updated the documentation to reflect the removal of Maven support.

One more minor revision to 'updateValue'

In this release, I revised the key sequence that's generated when erasing the existing content of an input field in sessions that don't support JavaScript. After erasing the field, updateValue now tabs out of the field to commit the change.

More tweaks to the 'updateValue' method

In this release, I took another stab at the implementation of the updateValue method to make it ubiquitously applicable to the vast majority of scenarios. I recently became aware that the original implementation was incompatible with common front-end libraries like Vue, causing input that was supposed to replace existing content to be appended instead.

The new implementation uses JavaScript to replace the existing content if the browser supports it. Otherwise, updateValue employs basic key sequences to overwrite the field content with the new value.

To facilitate testing of this new behavior, I added an htmlunit.nojs personality that provides HtmlUnit sessions with JavaScript support turned off.

Add Maven command lines for all supported targets

In this release, I added the ability to target each of the supported browser/application targets from the Maven command line. This allows execution of all Selenium Foundation unit tests without needing to mess with dependencies or settings.

Also in this release:

• Set the default "platform" to support to run the non-browser unit tests
• Revise documentation to remove references to Selenium 2
• Update mvn_build shell script, adding the ability to run the unit tests without the clean/install phases

Add multi-browser support to Gradle project

In this release, I added the ability to specify one or more browser profiles to the Selenium Foundation Gradle project. This ability has been available in the Maven project for a while, but it took some head-scratching to figure out how to provide a similar capability in Gradle.

With the revisions in this release, you can now specify one or more browsers, and the corresponding dependencies, properties, and driver plugins will be added to the build/test configuration. Note that the last specified browser will be the target of corresponding unit tests, although support for all specified browsers will be activated in the local Grid launched for the tests. If no browsers are specified, the "support" tests will be executed, and the local Grid will launch in "servlet container" mode.

• I bumped the major version in this release of Selenium Foundation, because I no longer set a default browser specification. You'll now need to specify either BROWSER_NAME or BROWSER_CAPS to indicate which browser you're targeting with your tests.
• I reworked the updateValue unit tests to interact with input elements on the targeted browser instead of relying on mock elements. The example page now specifies initial values for input fields to ensure that the logic to clear prior field content actually works.
• I removed the settings in gradle.properties that disabled Java auto-detect. The addition of these properties was prompted by issues triggered by stale registry entries on my development machine. The real solution was to clean up the registry; allowing auto-detect enables Gradle to use my Maven toolchain to locate the JDK installations needed to build and test Selenium Foundation.
• I upgraded to the latest release of SnakeYAML (version 1.33) to resolve an identified vulnerability.
• I swapped the expected and actual values in affected assertions so failure messages will be accurate.

Add Maven profiles that make it easy to run unit tests on specific browsers and devices

In this release, I added profiles to the Maven project definition (POM) file that make it easy to run the Selenium Foundation unit tests on each supported browser or platform. This new feature has been fully incorporated into the mvn-build.sh shell script, so running through the entire suite of unit tests on all supported platforms is a snap.

In the process of adding this feature, I discovered a few hidden defects in the Local Grid implementation. These have been resolved in this release as well. The most significant issue was that I was using two separate mechanisms to register Grid node plugins, which resulted in very puzzling failures. Registration is now specified by the GRID_PLUGINS setting (selenium.grid.plugins), falling back to the ServiceLoader if this is undefined.

I added entries in logback.xml to suppress the overwhelming spew of debug output we were getting when running on Appium targets.

I also upgraded a couple of core dependencies:

• HtmlUnit: 2.64.0 → 2.67.0
• SnakeYAML: 1.30 → 1.32