Open mills-andrew opened 4 years ago
Part of W3C WebDriver work is already implemented in v1.2-RC which fixed https://github.com/webdriverio/webdriverio/pull/4369. set ms:experimental-webdriver to true will enable this feature, and here is C# example to enable it.
appCapabilities.SetCapability("ms:experimental-webdriver", true)
If you found more incompliant, please comment and vote on #840
Hi @KitoCoding,
Let us know if there's anything particular gap you'd like us to fill.
the ms:experimental-webdriver. is there more documentation regarding this? I noticed the expected API is not directly 1 to 1. Is there an updated documents list that i am not familiar with? Is there plans to open source?
There is very limited description on https://github.com/microsoft/WinAppDriver/releases I don't know if there is plan on it or not. There is Microsoft.Windows.Apps.Test, which is branched from WinAppDriver and an kind of .net core implementation. Although it's not source code opensourced, Microsoft published it as nuget, and allow customers to develop their own automation framework based on it. WinUI is one of the open sourced project from Microsoft and developed its own infra structure based on it.
Not only capabilities need to be WebDriver conform, also command responses require a value property that should be null
if it has no value, e.g. currently WinAppDriver fail due to these requests:
POST /session/6D4345E0-AA2B-41DD-89CC-33DA1CE411C4/element/42.3279966.4.13/click HTTP/1.1
Accept: application/json
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Content-Length: 2
Content-Type: application/json; charset=utf-8
Host: 127.0.0.1:4723
User-Agent: webdriver/7.7.3
{}
HTTP/1.1 200 OK
Content-Length: 63
Content-Type: application/json
{"sessionId":"6D4345E0-AA2B-41DD-89CC-33DA1CE411C4","status":0}
The response must contain a value
property that might be null, see 5.3 Processing Mode
If request’s method is POST: Let parse result be the result of parsing as JSON with request’s body as the argument. If parse result is an error or if it is a success but its associated data is not an Object, send an error with error code invalid argument and jump back to step 1 in this overall algorithm. Otherwise, let parameters be parse result’s data. Otherwise, let parameters be null.
Still nothing?
Hello everyone! Sorry for the radio silence here. We haven't been able to dedicate as much engineering time to this problem as we'd hoped we would.
The team is preparing a prototype/beta for release in early 2023 that includes support for the non-draft W3C WebDriver specification.
Any update on this and when should we expect the release?
Hey guys! Waiting on this update since January, any progress?
Hi guys!
are there updates about that? I’ve got some problems about that for my product development. I cannot downgrade appium for some reason.
Thanks in advance!
So, I'm a Windows and Appium n00b, but I think I figured out a workaround at least.
I couldn't get Appium Inspector to work - eventually noticed the protocol differences in the logs (compared to my test runs, which work). I tried WinAppDriver 1.2.99 (RC for 1.3), no dice.
What did work for me is to use Appium Server, which has a driver that apparently acts as a proxy between Appium and WinAppDriver to make it support the new protocol. Basically get Node.js, then, from a command prompt:
npm i --location=global appium
appium driver install --source=npm appium-windows-driver
appium
I had to provide the capabilities appium:automationName
and platformName
- both set to Windows
.
Hope it helps someone! Would still argue it'd be more logical for WinAppDriver to support the new protocol directly.
Hi guy,
I'm also facing this problem in my project. Any update?
Thanks in advance!
Is there plans to become W3C WebDriver Protocol ready? It seems to be on track, but it has minor differences and issues. Missing endpoints, different expected formatted capabilities etc.
Does anyone know if there is a milestone report, expected end day? ETC.