* When doing refactoring, erroFromCode was split into 'errorFromMJSONWPStatusCode' and 'errorFromW3CJsonCode'
* 'errorFromCode' was being exported as an alias for 'errorFromW3CJSONCode' to avoid breaking changes
* Should have been an alias for 'errorFromMJSONWPStatusCode' though
* Do proxying for W3C responses
* If a W3C Response is provided by a proxy, map to the correct error
* Checks if `value` is an object and `value.error` and maps it based on that (`value.error` is the W3C error code)
* Broke off `errorFromCode` into `errorFromMJSONWPStatusCode` and `errorFromW3CJsonCode`
* Rename '.error' property to correct W3C property
* The error property in the ProtocolError objects should match up with https://www.w3.org/TR/webdriver/#handling-errors under the 'JSON Error Code' column
* Added tests for all of these
* Make ProxyRequestError work for W3C
* Added an arg called `.w3c` that passes in the proxied W3C error
* Fixed the `getActualError` function that looks for the .w3c variable and parses error from the code
* 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
* Use uia2 backend by default if platform version is greater or equal to 6
* Allow to force set the backend to UIA1
* Add unit tests
* Tune the log message
* Print a warning message instead of changing the driver type
* Remove redundant imports
* Tune the message
* Address PR comments
* Fixed HTTPResponseBody for W3C error
* Refactored `getResponseForW3CError` into errors.js file
* Changed method so that it returns `{value: {stack: '...', message: '...', error: '...'}}`
* Message is the same as the JSONWP error message
* Error is a static message indicating the type of error
* 'stack' is the callstack provided in the error
* Added W3C 'error' messages to all of the errors
* Make 'getResponseForW3CError' handle BadParametersError
* Refactor 'getResponseForJsonwpError' to errors.js
* 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
* Update `parseCapsForInnerDriver` so that now if it finds extraneous keys in `jsonwpCaps`, fall back to using MJSONWP instead of W3C
* After getting processed caps, check the protocol again because if `processedW3CCapabilities` was set to null, it should be JWP
* Removed tests that tested for capabilities being merged together (those are no longer needed)
* Added tests (unit test and e2e test) that check that creation of a new session will fall back to JSONWP when there are extraneous keys
* 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
* Refactored code from createSession into parseCapsForInnerDriver()
* parseCapsForInnerDriver() takes jsonwp and w3c capabilities and translates them into objects that can be accepted by the "inner driver" that it proxies to
* It adds defaultCapabilities to capabilities.firstMatch and jsonwp caps
* It finds matching caps for W3C and then creates a new W3C capabilities object that only has the valid matching one
* After parseCapsForInnerDriver() parses the JSONWP and W3C it passes the results along to the inner-driver and it's up to the inner driver to create a W3C or JSONWP session
* Add validation to W3C session creation
* Call to 'processCapabilities' does validation now so that it will match an object that passes Appium's validation rules (e.g.: platformName, deviceName required; automation name must be valid, etc...)
* Test that it accepts combo of W3C and JSONWP capabilities
* Test that it rejects invalid W3C capabilities with 400 error
* Also added 'createSession' unit test
* Stripped out unnecessary async/await from driver-specs
* Insert Appium prefixes into W3C caps
* Previously, Appium just took the W3C capabilities, processed them into a caps object and
passed them into the inner driver as
```
{
alwaysMatch: parsedCaps,
firstMatch: [{}],
}
```
* The problem with this is that all of the parsedCaps were unprefixed, and therefore the Inner
Driver complained about it
* Now, it takes the parsedCaps and calls a new method called 'insertAppiumPrefixes' on the
parsed caps like this:
```
{
alwaysMatch: {...insertAppiumPrefixes(parsedCaps)},
firstMatch: [{}],
}
```
* Refactored tests that were affected by this change
* Added tests to test insertAppiumPrefixes function
* 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
* 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
* Make malformed caps return 400 error
* Add InvalidArgumentTypeError to errors
* Made 'NotYetImplementedError' the 405 (Method Not Allowed) status code
* Made errors in 'createSession' return InvalidArgumentTypeError
* Fix incorrect W3C responses
* Add w3c status for NotImplemted and NotYetImplemented
* Changed `getResponseForW3CStatusError` so that throws an unknown error if the exception isn't a w3c exception
* Checks for property `w3cStatus` to confirm if it's a proper protocol-blessed exception
* Moved logic that reassigned errors into MJSONWP blocks; W3C shouldn't reassign errors because they all have proper status codes
* Added endpoint tests that check that you can create sessions in W3C and that subsequent calls to the session return the correct responses
* 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
* The 'executeCommand' on appium-base-driver checks the protocol by looking for the w3c 'capabilities' object
* Right now it's finding it and then appium is merging capabilities into desiredCapabilities so we're getting a case of 'createSession' misidentified as W3C
* Fix for next release is just to monkey-patch the method that determines the protocol to return MJSONWP
Dan Graham