* 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
Kazuaki Matsuo