Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support new winAppDriver(v1.0) feature "Attaching to an Existing App Window" #9106

Closed
vickywyy opened this issue Aug 29, 2017 · 15 comments
Closed
Labels
Enhancement feature P1 Windows Windows-specific issue

Comments

@vickywyy
Copy link

vickywyy commented Aug 29, 2017

appium-server-logs_with_both_app_and_addTopLevelWindow.txt
appium-server-logs_without_app_option.txt

The problem

in winAppDriver v1.0, there is a new feature “Attaching to an Existing App Window”.
please refer the details in https://github.com/Microsoft/WinAppDriver.

and I am using robotframework+appiumlibrary+Appium+winAppDriver to do the automation of my windows application.
i want to use the new feature mentioned above in Open Application keyword in robotframework appiumlibray

e.g
Open Application platformName=Windows deviceName=WindowsPC app=Root automationName=appium
Open Application platformName=Windows deviceName=WindowsPC appTopLevelWindow= automationName=appium

it failed when opening the handler, in the appium server log, it is said that “Option ‘app’ is required”.

then if i add the app argument as below:
Open Application platformName=Windows deviceName=WindowsPC app=Root automationName=appium
Open Application platformName=Windows deviceName=WindowsPC appTopLevelWindow= app=Root automationName=appium

in the appium server log, there is winAppDriver error: “invalid argument: bad capabilities: specify either app or appTopLevelWindow to create a session”

so how can Appium support this new winAppDriver feature?

thanks!

Environment

  • Appium version (or git revision) that exhibits the issue: v1.6.5
  • Last Appium version that did not exhibit the issue (if applicable): not try
  • Desktop OS/version used to run Appium: Win10
  • Node.js version (unless using Appium.app|exe): Appium exe
  • Mobile platform/version under test: windows desktop application
  • Real device or emulator/simulator: real device
  • Appium CLI or Appium.app|exe: appium exe

Details

as problem description

Link to Appium logs

N/A

Code To Reproduce Issue [ Good To Have ]

N/A

@mykola-mokhnach mykola-mokhnach added Enhancement feature Windows Windows-specific issue labels Aug 29, 2017
@dpgraham
Copy link
Contributor

Do you mind providing a Gist of the Appium server logs?

@dpgraham dpgraham added the Needs Info typically non-actionable; needs author to respond label Aug 29, 2017
@vickywyy
Copy link
Author

vickywyy commented Aug 30, 2017 via email

@dpgraham
Copy link
Contributor

Can you provide a link to the logs?

@jlipps
Copy link
Member

jlipps commented Aug 30, 2017

@yodurr do you have any ideas on this one?

@vickywyy
Copy link
Author

vickywyy commented Aug 31, 2017 via email

@yodurr
Copy link
Contributor

yodurr commented Aug 31, 2017

@timotiusmargo could you take a look?

I'm so glad we improved the error messaging in WinAppDriver :)

@timotiusmargo
Copy link

Hi @jlipps,

This is understood and WinAppDriver behaves as designed. In WinappDriver v1.0-RC release, we introduced a new feature to create a session by attaching to an existing app window. This is one of the most requested features due to the wide variations on how app launches in Windows desktop. To support this feature, we introduced appTopLevelWindow capability to allow user to specify the application top level window to attach to when creating session.

When this capability/feature is used, it doesn't make sense to specify app capability at the same time. As a result WinAppDriver rejects the request with a clear message to prevent user from specifying both capabilities. However, it looks like, Appium is enforcing the existence of app capability that would need to be null in such situation. We would then need to make a little adjustment in Appium that prevents session creation without app capability. Any thoughts are greatly welcome.

@jlipps jlipps added P1 and removed Needs Info typically non-actionable; needs author to respond labels Sep 1, 2017
@jlipps
Copy link
Member

jlipps commented Sep 1, 2017

@timotiusmargo I see. I think this should be an easy fix in appium-windows-driver, so I've added this to our backlog to look at

@deguangyu
Copy link

@jlipps do you know how to make the fix? I'm currently blocked on it for our testing. or can you please fix it soon?

@yodurr
Copy link
Contributor

yodurr commented Oct 20, 2017

I should be able to investigate this weekend

@yodurr
Copy link
Contributor

yodurr commented Oct 23, 2017

This PR fixes the issue: appium/appium-windows-driver#15

@yodurr
Copy link
Contributor

yodurr commented Jan 5, 2018

unfortunately that fix didn't make it into the latest release of Appium-windows-driver. I'll re-submit it for the next release.

@m33x
Copy link

m33x commented Jan 30, 2018

[Appium] Welcome to Appium v1.7.2
...
[Appium] Creating new WindowsDriver (v1.0.0) session
[Appium] Capabilities:
[Appium]   appTopLevelWindow: 0xd0654
[BaseDriver] The following capabilities were provided, but are not recognized by appium: appTopLevelWindow.

Any news on this? Can I patch my local installation by myself? What needs to be updated? (My automation script is written in Python not C# but that shouldn't be the problem here.)
Thanks

Edit: Found a way to patch it myself.

C:\Users\%USERNAME%\AppData\Roaming\npm\node_modules\appium\node_modules\appium-windows-driver\build\lib\winappdriver.js
change
var REQD_PARAMS = ['app'];
to
var REQD_PARAMS = [];

C:\Users\%USERNAME%\AppData\Roaming\npm\node_modules\appium\node_modules\appium-windows-driver\lib\winappdriver.js
change
const REQD_PARAMS = ['app'];
to
const REQD_PARAMS = [];

Restart appium afterward. Works ;)

@mykola-mokhnach
Copy link
Collaborator

I assume the feature has been included to the recent Appium release

@lock
Copy link

lock bot commented Aug 4, 2019

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock lock bot locked and limited conversation to collaborators Aug 4, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Enhancement feature P1 Windows Windows-specific issue
Projects
None yet
Development

No branches or pull requests

8 participants