BREAKING CHANGE: The current refactoring is breaking and changes `onUnexpectedShutdown` property to a function, which accepts a handler that is invoked by the driver when it gets shut down unexpectedly
* add executeDriverScript route, command, tests
* allow driver scripts to write and collect console logs
* ensure driver script protocol is set to same protocol as driver, and also includes all appium commands
* implement isFeatureEnabled to check for insecure feature
* add tests for isFeatureEnabled
* update feature flag name to match style of other flags
* add ensureFeatureEnabled method for use by other drivers
* move driver script execution into a child process so we can kill it if necessary
* use this.opts.address instead of this.opts.host
* ensure driver script timeout is a number in the child proc as well
* ensure we get webdriverio without issues
* add -image locator strategy and related logic
* use appium-support jimp helper
* handle find multiple elements by image
* update staleness check variable name
* ensure that a settings object always exists so we can rely on global settings always existing too
* only fix template size if user requests it in settings
* add note about implicit wait error handling
* only automatically update image element position if user turns on an appropriate setting
* add setting to control whether we check for image element staleness
* add setting to determine the image element tap strategy (w3c or mjsonwp)
* prefer single quotes
* add setting to turn off screenshot resizing if not desired
* add docstrings (except for cache class which we may not keep)
* address additional review comments
* add better jsdoc arg info
* use lru-cache npm package instead of rolling our own
* use new versino of appium-support
* make sure the lru cache is checking element size correctly
* give better names and tighten up logic around image el tap strategies
* add some unit tests for image elements
* ensure DeviceSettings has a default no-op update method
* check that driver implements action strategies and fall back / throw as appropriate
* finish out image element unit tests
* have basedriver set noop onSettingsUpdate rather than doing it in DeviceSettings
* move route avoidance detection from protocol to driver
* handle proxying actions to downstream drivers during image tap
* tighten up logic for deciding whether to proxy based on presence of image element
* add find by image specs and fix issues that arose in the process
* clean up regexes
* don't try to be smart and proxy actions for drivers; let them set it up themselves to support image elements
* change default match threshold based on experimentation
* export which settings are handled by basedriver so downstream drivers can utilize this information
* make sure to include a duration for the initial pointerMove action
* add docstring to proxyRouteIsAvoided
* Before, reset was creating a new session and using the processed caps
* The problem with is, if it was W3C it would create a MJSONWP
* Now it checks the protocol before resetting and passes in the appropriate args to createSession depending on the protocol type
* Previously, we were only checking the HTTP payload to see what protocol should be
* This is inadequate, in the case of drivers that don't proxy W3C Capabilities yet
* The fix now is to set the protocol in `createSession` to see if the W3C caps were proxied through, if they're not, set protocol to MJSONWP
* Added unit test and one e2e test to confirm that this works
* Rename 'mjsonwp' to 'protocol'
* Renamed folder from 'mjsonwp' to 'protocol' in `lib/` and `test/`
* Renamed 'mjsonwp.js' to 'protocol.js'
* Renamed any import statements that use 'mjsonwp'
* _Possible breaking change_: MJSONWireProtocol class exposed in index was renamed to just Protocol.... checked Appium repo and found no libraries that use MJSONWireProtocol
* Lint fix
* Moved 'ProxyRequestError' handling outside of the MJSONWP block.
* When it's a proxy error, Appium translates the error (based on statusCode) to it's proper Error
* W3C weren't doing this when ProxyRequestError was being used
* Now W3C translates proxy errors
* Added tests in `mjsonwp-e2e-specs` that test JWProxy
* Test successful 200 proxies
* Tested unsuccessful responses to see that a JSONWP response with status = 6 would return the correct 'NoSuchDriverError' with statusCode = 404
* Made an 'automations.js' file that lists all valid automations as an Object instead of hard-coding it
* appium/appium will use this instead of hardcoding automation names
* Make desired-caps pull in the values of those automations for validation instead of hard-coding them
* Expose 'validAutomations' to Driver object
* Fixed a defect in 'firstMatch' validation
* Previously, it was validating the firstMatch capabilities and was failing on the first validation failure, which is a problem if firstMatch has a length > 1 and it fails before finding a potentially passing capabilities set is found
* Now, it doesn't error-out on the first failure. If it fails, it skips over it to the next one until it finds one that passes and returns that.
* Altered the 'presence' constraint validation
* Don't validate 'presence' on 'alwaysMatch' because if a capability isn't present on 'alwaysMatch' it may be present in one of the 'firstMatch' capabilities
* Validate presence on all of the 'firstMatch' capabilities, except for the keys that are present in 'alwaysMatch'. If the key is in 'alwaysMatch', strip out the presence constraint because we know that it has passed already
* Changed the default protocol
* If MJSONWP _and_ W3C are provided, initiate a W3C session by default. If clients are passing in W3C parameters to create a session, we can safely assume that they've implemented the rest of the W3C spec
* Improved error logging
* If errors were found, show a message saying `Could not find matching capabilities: ${errors}` where `errors` are a list of all the validation error messages for each of the attempts to validate `firstMatch` caps
* If `firstMatch` caps has a length of one, then don't show the message saying `Could not find matching capabilities` portion of it, just show the errors
* Other remediations
* Allow `alwaysMatch` and `firstMatch` to be `null` or `undefined`
* Added single quotes around names of capabilities when showing their errors
* Remember protocol requested in createSession
* Also renamed 'processCaps' to 'processCapabilities'
* Checks the parameters in 'createSession' and determines if it's W3C or MJSONWP
* Add W3C error format
* Add W3C status codes to errors
* When deciding error format to return in mjsonwp.js, check format and then return eitherJSONWP or W3C format
* Update hash
* Add validateCapabilities and parseCapabilities
* Added merge capabilities
* Moved capabilities into it's own file
* Added capabilities as a possible required param
* Can pass desiredCapabilities or capabilities into createSession
* Remove 'required' desiredCapabilities
* desiredCapabilities isn't required any more because we can provide capabilities as well
* Will need to update validation logic in 'driver.createSession' to do the validation there instead
* Code cleanup
* Skip presence constraint in parseCapabilities
* We don't need to check that items are present until after we've formed the matched capabilities
* Added validation function to routes
* Function 'validate' takes params as an arg and then returns a message if the validation fails
* Uses this to validate that either "capabilities" or "desiredCapabilities" was provided
* Renamed capabilities to caps
* Move caps required validator from process to parse
* Removed InvalidParametersError
* Update BadParametersError so that if a message is added as the 3rd argument it shows a different error message
* Made validation re-usable
Mykola Mokhnach