appium-for-mac
appium-for-mac copied to clipboard
appium
Is it possible to use appium-for-mac to automate tests on a WebKit/WebView browser that is embedded in a Mac OS X desktop application?
This is perhaps an enhancement request. Is it possible to use appium-for-mac server to automate tests on a WebKit/WebView browser that is embedded in a Mac OS X desktop application? I reviewed the instruction of Appium server for hybrid app in https://github.com/appium/appium/blob/master/docs/en/advanced-concepts/hybrid.md I got stuck when I tried to switch from native to webview through below code. //python from appium import webdriver from time import sleep
print ('Starting the WebDriver session') driver = webdriver.Remote( command_executor='http://localhost:4622/wd/hub', desired_capabilities={'platform':'Mac'})
print ('Desktop app') driver.get("Desktop app")
// got stuck here webview = driver.contexts.last driver.switch_to.context('WEBVIEW_1') print(driver.contexts.last)
I got below errors. The problem here is I couldn't call derive.contexts
Traceback (most recent call last):
File "desktop.py", line 10, in
Your help is really appreciated!
We should be able to add support for this as the same technique used by appium (the WebKit remote debugging protocol) should be feasible in mac apps
Web views are a problem. AppiumForMac runs in its own process. It doesn't have direct access to web views inside another application. This means no direct JavaScript injection, no running scripts, and most importantly, no way to find elements using a DOM Xpath, such as you might use for ChromeDriver or SafariDriver. You also can't locate elements by CSS class, for example. You just can't get there from here.
The news is not entirely bleak. The OS X accessibility APIs do allow access to the visible UI elements inside web views. You have to use accessibility XPaths instead of DOM XPaths. (What is an accessibility XPath? See the newest version of appium-for-mac for details). So you can see and manipulate the web view like any native UI elements, but you still can't inject JavaScript and do other things that require direct access.
It is possible (but difficult) to take AppiumForMac and essentially paste the code into your own application, thereby giving the handlers direct access to the entire application, including web views. I don't recommend this approach, but if you've got the time.... Also, beware that the PFAssistive.framework is freely licensed ONLY inside AppiumForMac.app. If you copy the code into your own app, you need to contact PFiddleSoft and acquire a separate license. They're not expensive and you will not regret the amazing documentation of the framework, and excellent support.
Maybe one day someone will re-package AppiumForMac as some sort of framework that can be easily dropped into any application. I've heard rumors about such things, but haven't seen one in public... there may also be licensing issues with this approach.
As far as adding remote debugging protocol to non-Chromium-based Mac apps: It would definitely be possible and desirable, but I don't have any idea of the scope. It will not be easy, but it is much better than cramming AfM into your app. Perhaps that could be another framework. Hmm, ideas aplenty!
Any update on this? I have the same requirement to Automate the Webviews embedded within a MAC OSX application
The answer is yes, and no, depending on how you want to automate your web views.
AfM is a stand-alone application. It uses macOS accessibility API's to examine and control the macOS UI (including applications under test). As a separate app, it has no way to go into the AUT and directly access objects such as a web view. As such, it can not use normal web view XPaths. These can only be used from inside the AUT, because accessing them requires DOM methods which are not exposed by the accessibility APIs.
However, the accessibility APIs do provide accessibility-based paths for some web view elements, just like accessibility paths for native macOS controls. They are not standard DOM paths. I call them "AXPaths" because at every level the classes and attributes begin with "AX...". The Accessibility Inspector application shows these attributes.
So if you are willing to use AXPaths, the answer is Yes. To find an AXPath for any element (web view or native) just run AfM, point to an element on screen, and press the function (fn) key. In a second or two you will see the AfM dock icon bounce and you can release the fn key. Your clipboard will contain the full path.
If you must use standard DOM xpaths, then the answer is No, AfM can not help you.
Thanks for your reply @stuartbrussell-intuit .Do i need to use contextSwitch() to switch to webview?
Is there a way to say get the remote debugging protocol and pass that to selenium? safari can detect the protocol.
If the app you are testing supports the remote debugging protocol, you can create two WebDriver instances. One is connected to AFM using one IP port; this gives you native macOS elements and native events. The other WebDriver is connected to the remote debugging protocol; then you can directly access the embedded WebView.
Hi - Did anybody here find a solution? Could you please share how you were able to automate Webkit/Webview? Currently I am using Appium-mac2-driver and I am able to do UI interaction with the Webview using Appium-mac2-driver. But I am unable to run javascript. I am trying to find a way to attach Webview (embedded in a native app) to Safari driver. Any inputs on how I can do that? There is ios-webkit-debug-proxy for attaching ios webviews, but didn't find anything for macOSx native app webviews.
@sramssh Can you explain how to do UI automation with appium mac2 driver ?
