[v1.28.0] Not able to inspect elements in WebView (android, emulator, API 33)

[Dambakk]

Describe the bug
I am not able to assert that some text is visible in an Android WebView when targeting API 33. The hierarchy does not contain any of the texts I expect, and Studio does not let me inspect any of the elements. (I also experience the same on my Pixel device running Android 14 preview) It works on emulator targeting API 32.

Slack thread discussing the issue: https://mobile-dev-inc.slack.com/archives/C041FU72T54/p1685687193237819
Cloud run that fails because of this: https://console.mobile.dev/uploads/290128bd-c337-499b-a1f9-a7aa6ef9109c?teamId=d654771a-0d9f-4d20-9c2a-c0dcd36c08b5&appId=69c4e90d-9edc-4c1f-82bd-03d096219a01&analysisId=36fe9c6b-eee0-4f15-a87d-a2894e9c8aab&checkIdx=0

To Reproduce
See the cloud run above to see the issue, but in short;

• have an app that opens a webpage in a classic xml WebView
• launch the app on an emulator targeting API 33.
• run a flow or open Studio and try to do assertions in the webview.

Expected behavior
I want to be able to assert visibility of elements in a Android WebView.

Screenshots

Environment information (please complete the following information):

• Maestro version: 1.28.0
• Platform: Android, API 33
• Framework: Native Android
• Device model and OS version: Emulator (and possibly also device) targeting API 33 and above
• Host Mac M1

[Dambakk]

One strange thing I notice: If I go back one step (still inside webview) and tap on the element that open this page again, then I am able to inspect the elements on the page! I guess that makes it clear that we can rule out any issues with the webpage being displayed.

[TaimoorWaseemKhan93]

@Dambakk can you please name the apk ? or you can share the application on which you are getting the error ?

[Dambakk]

Can you DM in the maestro slack? I can share it with you there :)

[gabrielgolla]

I have similar issue. I'm trying to interact with elements in webview but Maestro sees whole screen as an element. Do you have a detailes documentation about testing webview with Maestro?

[senf666]

Same here. Using Maestro studio and an Android apk when I open a webview, I can only do tapOn on the webview, I can't assert on any elements of the webview as Maestro Studio doesn't see them.

[Dambakk]

Still happens on 1.35.0

[rafinskipg]

+1 it seems webview on android doesnt work for certain things, we would also need the webview to behave the same in android and ios

[mervebozkir]

+1 I face this issue too, sometimes it detects the entire webview as a single component in android but sometimes, its able to view the hierarchy of the components inside webview.

[holzgeist]

Could this be related to leancodepl/patrol#244?
@bartekpacia I saw you are active in both Patrol and Maestro. And you (partly?) fixed the issue I linked in Patrol. Could there be a similar fix here? Or is it completely unrelated after all?

(I'm experiencing the same issue with a Flutter InAppWebView btw)

[bartekpacia]

Could this be related to leancodepl/patrol#244?

It's possible, but unfortunately people who reported this problem in this issue don't specify what technology their app is built in – so we're not sure if it's only Flutter.

[holzgeist]

@bartekpacia they mention Framework: Native Android in the initial report, so I guess it's not only flutter.

I'll give it a new try with the new Flutter release 3.24 and report back

[holzgeist]

No luck with 3.24

[rewgoes]

It is sill a problem on API 34, maestro 1.37.9. (Android Native)

[Fishbowler]

Is someone able to provide an APK to test with? I'd love to work out what's going on here.

[rewgoes]

Is someone able to provide an APK to test with? I'd love to work out what's going on here.

I won't say that this problem applies to a specific APK, as in my tests I've noticed that the problem sporadically happens for the same APK and emulator/devices.

[Fishbowler]

Sounds like a Studio bug then, if it's only reproducible intermittently?
Have you seen it affect real tests?

[rewgoes]

Yes, it has happened on our tests that run on CI.

Edited: it does look more stable nowadays, so I wonder if there is anything to do with some version of the WebView installed in the emulator. I won't have the version of the WebView that I identified the problem though.

[lypanov]

Running into this when running tests on infinite retry till fail (in an attempt to reduce test flake). After max ~3 passes I see assertVisible failures from Maestro, and when firing up maestro studio on the still running app instance I can clearly see that Maestro is simply not "diving into" the iframe in the webview and is instead seeing the entire iframe as a single block with no searchable content.

Recordings (and physical device inspection) clearly show that the content is very much present at the time the assertVisible fires and it's Maestro failing to traverse the iframe's in the webview (or a failure deeper in Android accessibility APIs itself feasibly).

For now worked around it by modifying my Maestro test run wrapper to entirely ignore any failures with 'WebviewInspectable' in the assert and asserting that previous to the real assertVisibles (and injecting that text invisibly in my web views... and praying it won't cause a test vs production diff).

[CDRussell]

Will add some observations from when I last saw this:

• it never happened API 30, only on >= API 33 devices
• API 30 emulator comes with a really old WebView out of the box, so it’s possibly related to a feature/bug in newer WebView versions only
• if I added in an arbitrary scroll command first before trying to assert anything about what’s visible in the WebView, it seemed to work. possibly a coincidence, but possibly that helped expose the proper WebView hierarchy in some way (e.g. because it’s a user gesture?)

I didn’t get to the bottom of it at the time because we decided to stick with API 30 devices for our testing, but I’d like to be able to use newer ones so hoping some of the above sparks some inspiration into the problem.

[Leland-Takamine]

Hey folks - there is a new experimental option available that may resolve this issue. Please give it a try and let us know how it goes!

Add androidWebViewHierarchy: devtools to the config section of your top-level flow you want to apply this to (it will be ignored if added to a subflow file).

appId: com.example.app
androidWebViewHierarchy: devtools
---
- launchApp

[nielsdekeijzer]

@Leland-Takamine , unfortunately the issue still occurs.

• using emulator, API 36.
• added androidWebViewHierarchy: devtools to the top-level flow file as described above.
• I have 1.40.2 installed.

[Leland-Takamine]

@nielsdekeijzer would you be able to provide a repro case that we can test on our end?