Driver.navigate.back isn't as reliable as clicking with the mouse button.

[sleekweasel]

It's going to be hard to come up with an example for this because even on our tests it's about a 3% incident, but I've recently replaced our use of the official 'go back' with a mouse.move_by(20, screen_height+20), mouse.click, and it seems to work better for a number of occasions where I previously had a second or two sleep followed by the click, followed by another second's sleep.

I'm guessing you'll probably tell me that the official back is implemented through mouse clicks anyway, so I'm effectively just adding more sleeps, but... :)

[NickAb]

The back is implemented simple by sending a F1 which is hot key for emulator's Back button according to msdn article.

I guess you are using Windows 10 emulators, because screen_height+20 should only work for emulators with onscreen back button. Am I correct?

Also, could you clarify the bit about use of sleep. Did you have the following setup:

1. some code -> go_back -> some code And now you have:
2. some code -> sleep -> click back -> sleep -> some code Or do you have sleep in both cases?

Note that 'go back' is not a synchronous command, i.e. it will issue Back button action and return control back to you right away without waiting for any navigation of pages, possible animations, etc., the wait part has to be done on test side.

I think there is a back method on XdeAutomationClient that I am planning to migrate most of the interactions with emulator (like gestures, etc.). This might be more reliable then use of emulator controller's TypeKey, but my understanding is that the use same backend to do this.

[sleekweasel]

Hey Nick.

It was some_code -> go_back -> code_to_wait_for_screen. Manually clicking back always worked; the automated 'back' event usually worked, but when it was swallowed, it didn't matter how long I waited. I don't believe the 'back' automated press was interrupting an animation, but I suppose it's possible.

I only said it was 'more' reliable: even the mouse-based solution wasn't perfect, and it could be something subtle in our app. I've ended up just trying a second click if the first doesn't cause the screen shift within some number of seconds, because I wanted a working solution (pressure to get the tests going) but I could try reverting that and trying to characterise it. Unfortunately, I haven't cooked up a video-clip automation for Windows like I have with our other platforms, so I don't have something I can review frame-by-frame for clues.

The Windows Phone version being emulated is 8.1, hosted by... Windows 8.1. The bottom of the emulator looks like this:

[NickAb]

Hey Tim,

This is strange, the driver should not be able to click outside virtual screen, even on XDE window. Maybe Windows 8.1 does has onscreen back button, but it is out of bounds.

P.S. to record screen on test runs on Windows I used VLC with remote interface. It woks quite good, although it is separate process and one has to wait to finish flushing the video to file before killing it, there is no event for this. Also, XDE streams emulator screen from Hyper-V using RDP, but when you connect to it from Hyper-V management, the XDE disconnects form emulator. But maybe it is possible to somehow connect to same session, as desktop Windows 8 and Windows Server 2012 support such features.