Autopilot

frequent issues with X sync

Bug #1212635 reported by Michael Zanetti
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Autopilot
New
Undecided
Unassigned

Bug Description

When running our tests, we frequently have issues with X not being synced. Not only on slow VM's but also on real hardware.

For example:

We have a text input field and use autopilot to
- click the text field
- assertThat(textfield.activeFocus, Eventually(Equals(True)))
- type some letters ("foobar")
- verify that some component received the input text

Quite often this only produces the input "oobar" because the "f" is typed before X actually syncs the input focus state.

Another example:

We have a hidden component somewhere in the ui. For instance some sort of dialog which contains a button and do the test:
- dialog.show()
- assertThat(button.visible, Eventually(Equals(True)))
- click the button
- assert that the button's action has been executed

This quite often clicks on the right place but does the click too early, because all the app's states in memory are updated already, but X is not yet synced to it.

I think autopilot needs to become more reliable in those areas. Is it possible to wait for X to be synced somehow? If yes, I think autopilot should wait for such a sync every time before doing any input.

See original description
Michael Zanetti (mzanetti)
description: updated
Revision history for this message
Thomi Richards (thomir-deactivatedaccount) wrote : Re: [Bug 1212635] [NEW] frequent issues with X sync

Hi Michael,

just to make sure I understand, it sounds like both of these cases boil
down to the same issue:

The widget says it's focused/visible before that's actually the case.

Does that sum up the issue properly?

I'll have to think about how we can fix this in autopilot.

--
Thomi Richards
<email address hidden>

Revision history for this message
Michael Zanetti (mzanetti) wrote :

Hi, it's not really only focusing issues. The button for example doesn't need to be focused, still the same issue happens with items change from invisible to visible, or change their position. Basically everything that causes the painting on the screen to update is async and autopilot is often too fast because it only checks the app's state in memory and not regarding the state of the screen which is the one dictating where mouse/keyboard input is directed to.

If you need examples let me know, we have tons of failed jenkins test runs (on VM and on real hardware) that show this kind of behavior.

Revision history for this message
Thomi Richards (thomir-deactivatedaccount) wrote : Re: [Bug 1212635] Re: frequent issues with X sync

Right, that makes sense.

I'm not sure how you think we can fix this. The fundamental facts are:

1) Autopilot runs in a separate process.
2) Autopilot delivers input outside of the application event loop (either
via Xlib or UInput).
3) X11 is asynchronous for most operations.
4) Application state does not allow for the asynchronicity of X11
operations.

We could solve it by changing number 2, but I think that's a mistake.

I need to think about this some more.

--
Thomi Richards
<email address hidden>

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.