* If`executeCommand` returns an object that has a property 'protocol' and either a 'value' property or an 'error' property, respond with the provided protocol
* If the object is of this form, than it came from another driver that knows what protocol is being used so we re-assign the protocol to whatever was reported
* Added to delay in the 'unexpected exits' test because I was getting a race condition
* Add common websocket handlers
* tune the default prefix
* Add integration test
* Tune the test
* Fix the functional test
* Tune socket import
* Address review comments
* Tune some expectations
* 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
* If server encounters a response that has the wrong key name (ELEMENT when it should be 'element-6066-11e4-a52e-4f735466cecf'), rename all instances of that key
* Added a helper method (with tests) that recursively finds instances of a 'key' and renames it
* Added e2e test that mocks `findElements`, calls `/elements` endpoint and verifies that the payload was correctly renamed
* Previously, it was going through alwaysMatch and all of the firstMatch caps and individually logging when any of them had unprefixed, non-standard caps
* Now it does them all at once
* Made a helper function that takes a caps object ({alwaysMatch, firstMatch}) and finds all of the non-prefixed caps in all of them
* Calls that function and logs warning
* If 'capabilities' and 'desiredCapabilities' were provided, and 'capabilities' is NOT a plain object, fall back to 'desiredCapabilities'
* Added more logging to the W3C vs. MJSONWP determination logic
* Rename `createSession` args to be more descriptive
* Added basic W3C unit tests for above fix
* fix timeouts for w3c
* revert lock file
* add validation for previous timeouts
* implement custom validator for W3C
* improve if condition
* define isW3CProtocol
* rewrite validation a bit
* apply util.hasValue and string protocol
* add tests
* refactor timeouts for mjsonwp and w3c
* use const
* remove previous timeouts
* use undefined
* rename to timeouts again
* wrap some commands
* remove ...args
* define each command
* 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
* Doesn't make sense to validate 'presence' in the firstMatch caps, because the firstMatch caps extend alwaysMatch
* Only 'alwaysMatch' should validate 'presence'
* Add aliased W3C routes
* Implement getTimeouts command
* getTimeouts returns an object containing all the timeouts and their values as key-value pairings
* Added routeHandler too
* Added w3c routes
* 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
* Added a test for unzipFile (which uses adm-zip)
* Tested that it worked with adm-zip and then failed once adm-zip was taken out
* Replaced 'adm-zip' with zip.extractAllTo from appium-supprt
* 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
APK files were not being installed because they were being written to a file without an "apk" extension. So added back the appExt suffix logic. If it's given and the downloaded file is not a ZIP file, then everything behaves normally. If the downloaded file is a ZIP file, then regardless of what we thought initially, it will be unzipped and placed into another temp location.
Mykola Mokhnach