Is there a way to assign name for web context in app under test?

[NickAb]

At the moment you can switch to web context using names like WEBVIEW_1 that are assigned by Appium. Is there a way to specify name for web context based on automation id of element or something?

Manually assigning names for web contexts will allow:

• Make code of tests for hybrid apps with multiple web views more readable and easier to maintain.
• Allow for stable testing of hybrid apps that create web views in runtime (auto assigning context names make it harder, as names can change depending on sequence of user actions that lead to creation of corresponding web views).

[moizjv]

@NickAb AFAIK appium does not assign these names. You can always store it in variables and use variable instead to make your code more readable

[Jonahss]

Yeah, though this would be a useful feature, there's no way I know of to dependably keep track of webviews and make sure the same one always gets the same name. If you think about it, it is against the selenium/appium model to name elements as well. The appium server just assigns elements IDs and it is up to the test code to keep track of elements and assign them to variables.

Which appium client do you use? If you use the java client, maybe we could have the Contexts be full Objects instead of strings. Otherwise, you can always use the Page Object model of testing to assign your contexts to names.

[NickAb]

@Jonahss actually the problem is not in storing context names in tests, but in correlating context names and corresponding UIAWebViews in native context.
In our app we have more than one web view at any time (sometimes up to 5). The order of these web views appearing in program might change as it is defined by user interaction. So we can't simple add some constant context name value to our PageObject as it might change for same PageObject but in different test cases (depending on previous action). But we always have accessibility id assigned to each UIAWebView. So I am looking for a way to easily identify which context correspond to which native UIAWebView, so that I could easily switch to web view I need based on its unique and constant name that does not depend on a order of actions.

One option I see is iterating over all web view contexts and checking some attribute in page source to build a map between auto assigned names (like "WEBVIEW_5") and constant unique names defined in code. But I don't like the idea of iterating over all contexts.

In webkit-remote-debbuger besides page key (the number that gets appended to "WEBVIEW_") page title and url are also received.
Is it what you are talking about in

If you use the java client, maybe we could have the Contexts be full Objects instead of strings.

If so, it seems that those values can be used as constant context identifiers. And I think it will certainly help in our case. I use python bindings.
I'm not sure if strings can be changed to objects easily for all bindings. In case of python one could simply return a dictionary, where keys will be context names and values will be dictionaries with title and url, etc and it will most likely work out of box without any need to modify bindings. But in case of C# or Java it might require changing bindings. So I was thinking more of adding a new context endpoint that will return list of contexts with some extra data.

What do you think about it?

[Jonahss]

Oh I see. We could name the webviews based on their accessibility id's or other attributes as well. That's a good suggestion, but I don't think it's possible :(

For example, the way we get a list of the chrome webviews on an Android app is we call ps to list the processes running on the phone, and find instances of chrome webviews running. We can connect to those processes (which is how we automate them) but we have no way of matching the process to the view hierarchy.
It's similar on iOS, we use ios_webkit_debug_proxy which just gives us a list of running webviews and doesn't tell us which UiElement generated each.

A workaround for you: You can add a hidden element in your webviews which records the accessibility Id of the webview. So you can change contexts to each webview and find the hidden element and get the text. You can also call getLocation() on the webview to get the url that the webview is pointed at.

[NickAb]

@Jonahss after reading the code I thought that using accessibility ids for context names would be impossible. And the workaround will work for me, but it will require sending quite a few requests and commands to Appium.
I was wondering if this could be done in one request on iOS. Accroding to webkit-remote-debugger.js#L85-L90 Appium already has url and title data for each page, so it can be obtained in single request. Would you be open to a pull request that adds context endpoint that will respond not with a list of context names as strings, but with a list or map of context objects (as you suggested in your comment)? This endpoint will be iOS specific (as Android implementation differs in this regard). Or, this can be done as some prefixed ExecuteScript command.

[Jonahss]

I wonder if we can find a way to get context metadata for android as well, and then can have /contexts return object for both.

Having the /contexts endpoint return objects with optional metadata is a good idea. Let's see if @jlipps is ok with editing the mobile json wire protocol to include this.

If we make the metadata optional, then it can be included with iOS and not included with Android for now. If @jlipps likes this, we would love a pull request!

[nwlunatic]

👍 would be a big improvement for correct context discovery instead of switching and trying to find something context specific

[NickAb]

@Jonahss @jlipps any updates on the idea of adding optional metadata to mobile jswp?

[jlipps]

sorry, no, however if you want to engage more of the spec authors (which would need to happen anyway), feel free to chime in at http://github.com/SeleniumHQ/mobile-spec or mobile-jsonwp-spec@googlegroups.com

[lock]

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.