_ElementSelectAction : JS refactoring + case insensivity

[mlipok]

Pull request

Proposed changes

Case Insensivity as requested here: https://github.com/Danp2/au3WebDriver/pull/377#issuecomment-1218443860 Code is refactored to use the same JS variable names, and the same JS coding style

Checklist

• [x] I have read and noticed the CODE OF CONDUCT document
• [x] I have read and noticed the CONTRIBUTING document
• [ ] I have added necessary documentation or screenshots (if appropriate)

Types of changes

Please check x the type of change your PR introduces:

• [ ] Bugfix (change which fixes an issue)
• [x] Feature (change which adds functionality)
• [x] Code style update (formatting, renaming)
• [x] Refactoring (functional, structural)
• [ ] Documentation content changes
• [ ] Other (please describe)

What is the current behavior?

if you use

_WD_ElementSelectAction($sSession, $sSelectElement, 'SINGLESELECT', 'ParroT')

instead

_WD_ElementSelectAction($sSession, $sSelectElement, 'SINGLESELECT', 'Parrot')

then you will get error= $_WD_ERROR_NoMatch

What is the new behavior?

no error, element is selected

Additional context

https://github.com/Danp2/au3WebDriver/pull/377#issuecomment-1218443860

System under test

not related

[Danp2]

• You appear to be using tabs instead of spaces in some areas. This creates some unusual indenting such as here --

https://github.com/Danp2/au3WebDriver/blob/fe4b7a95d744e0334e1052cc4859ed674b8d6f0c/wd_helper.au3#L1056-L1058

• Instead of if ( !( IsDisabled || IsHidden ) && Matching ), wouldn't it be more optimized to reverse the checking, ie: if ( Matching && !( IsDisabled || IsHidden ) )?

• Taking that a step further, you should calculate Matching first. If it is False, then there's no reason to continue with further calculations / checks for disabled or hidden.

[mlipok]

• You appear to be using tabs instead of spaces in some areas. This creates some unusual indenting such as here --

Unusual indenting are visible only on GitHub but in SciTE editor it looks like:

• Instead of if ( !( IsDisabled || IsHidden ) && Matching ), wouldn't it be more optimized to reverse the checking, ie: if ( Matching && !( IsDisabled || IsHidden ) )?
• Taking that a step further, you should calculate Matching first. If it is False, then there's no reason to continue with further calculations / checks for disabled or hidden.

Please take a look at: Matching logic changed