| 2015-05-22 13:25:29 |
Leo Arias |
description |
When you have python3-xlib installed in the phone, the tests will register a cleanup for the x11 keyboard even if they are not using it. When a test fails, the cleanup is executed and fails because trying to call events from the x11 keyboard will raise an exception on the phone.
<elopio_> ping vila: I now more or less understand the X11 Mouse on Touch error.
<vila> elopio_: \o/ tell me more
<elopio_> but I'm not closer to a solution.
<elopio> vila: here a Keyboard is instantiated in the base test case: http://bazaar.launchpad.net/~autopilot/autopilot/trunk/view/head:/autopilot/testcase.py#L165
<elopio> here, the keyboard is going to pick a backend, with a preferrence for X11: http://bazaar.launchpad.net/~autopilot/autopilot/trunk/view/head:/autopilot/input/__init__.py#L125
<elopio> as python3-xlib is installed, the imports in this module succeed: http://bazaar.launchpad.net/~autopilot/autopilot/trunk/view/head:/autopilot/input/_X11.py
<elopio> so we hit this statement: http://bazaar.launchpad.net/~autopilot/autopilot/trunk/view/head:/autopilot/input/_X11.py#L283
<elopio> class Mouse(MouseBase):
<elopio> MouseBase is an alias for http://bazaar.launchpad.net/~autopilot/autopilot/trunk/view/head:/autopilot/input/__init__.py#L243
<elopio> class Mouse(CleanupRegistered):
<elopio> CleanupRegistered does a little black magic to put a clean up in the test case when the class is defined, not when it is instantiated.
<vila> elopio: so, this confirms installing python3-xlib is the culprit
<elopio> in the Mouse case, it tries to move the mouse on cleanup.
<vila> elopio: urgh, black magic...
<elopio> so even if we don't instantiate Mouse, the cleanup gets registered.
<vila> indeed, urgh black magic ?
<elopio> vila: yes, without python3-xlib the _X11 imports will fail, so we won't hit the class definintion statement.
<elopio> http://bazaar.launchpad.net/~autopilot/autopilot/trunk/view/head:/autopilot/utilities.py#L330
<elopio> CleanupRegistered = _TestCleanupMeta('CleanupRegistered', (object,), {})
<vila> elopio: trying to reformulate: the bug is that a useless package triggers an unexpected AP behavior because of ... internal reasons ?
<elopio> vila: the bug is that having installed python3-xlib triggers an xlib cleanup which fails on touch.
<elopio> the immediate cause I think is that we are instantiating a keyboard on the testcase, which makes no sense to be, but we need to confirm with veebers.
<vila> elopio: right, xlib shouldn't be installlled on touch. But what if it for other reasons ? As long as AP is not told to care about X11, it shouldn't. No ?
<elopio> s/to be/to me
<vila> right
<elopio> vila: if xlib is installed but we don't instantiate anything from that backend, we are ok.
<elopio> then there's the underlying problem, that's autopilot doing extra stuff on class declarations instead of during __init__.
<vila> elopio: ok, so you're saying adding the keyboard is what trigger the x11 code (what happens if x11 is not there again ?)
<elopio> if x11 is not there, the import will fail, and a evdev keyboard will be instantiated instead.
<elopio> we will never hit the class declaration of Mouse.
<vila> right
<vila> elopio: my kbd is acting
<vila> can't type long sentences :-/
<vila> elopio: is there a way to make these input devices declarations more explicit (instead of relying on installed packages) ?
<elopio> vila: you can choose the backend, and make an explicit if, like we are doing almost everywhere:
<elopio> http://bazaar.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/trunk/view/head:/tests/autopilot/ubuntuuitoolkit/_custom_proxy_objects/_common.py#L45
<elopio> this is one more case where autopilot was designed to be (IMO) unnecessarily smart
<vila> elopio: /me nods
<elopio> vila: but what I'm wondering is about removing these mouse and keyboard properties: http://bazaar.launchpad.net/~autopilot/autopilot/trunk/view/head:/autopilot/testcase.py#L186
<elopio> we have been instantiating the keyboard and mouse on the custom proxy objects for UI widgets that need them. In the apps tests we are never using these properties, so I would deprecate them.
<elopio> the problem is that we instantiate many keyboards and mouses, but it's not too bad as the backend is a singleton.
<vila> elopio: hmpf. I can't say with my limited knowledge... But somehow, if that's where those are created implicitly... That seems to match what we've been talking about |
When you have python3-xlib installed in the phone, the tests will register a cleanup for the x11 keyboard even if they are not using it. When a test fails, the cleanup is executed and fails because trying to call events from the x11 keyboard will raise an exception on the phone.
There seem to be two problems:
- I think that the test case shouldn't have an instance of keyboard and mouse. This should be in the helpers that require keyboard or mouse.
- The cleanup is registered when the interpreter reads the class declaration, not when the class is instantiated.
<elopio_> ping vila: I now more or less understand the X11 Mouse on Touch error.
<vila> elopio_: \o/ tell me more
<elopio_> but I'm not closer to a solution.
<elopio> vila: here a Keyboard is instantiated in the base test case: http://bazaar.launchpad.net/~autopilot/autopilot/trunk/view/head:/autopilot/testcase.py#L165
<elopio> here, the keyboard is going to pick a backend, with a preferrence for X11: http://bazaar.launchpad.net/~autopilot/autopilot/trunk/view/head:/autopilot/input/__init__.py#L125
<elopio> as python3-xlib is installed, the imports in this module succeed: http://bazaar.launchpad.net/~autopilot/autopilot/trunk/view/head:/autopilot/input/_X11.py
<elopio> so we hit this statement: http://bazaar.launchpad.net/~autopilot/autopilot/trunk/view/head:/autopilot/input/_X11.py#L283
<elopio> class Mouse(MouseBase):
<elopio> MouseBase is an alias for http://bazaar.launchpad.net/~autopilot/autopilot/trunk/view/head:/autopilot/input/__init__.py#L243
<elopio> class Mouse(CleanupRegistered):
<elopio> CleanupRegistered does a little black magic to put a clean up in the test case when the class is defined, not when it is instantiated.
<vila> elopio: so, this confirms installing python3-xlib is the culprit
<elopio> in the Mouse case, it tries to move the mouse on cleanup.
<vila> elopio: urgh, black magic...
<elopio> so even if we don't instantiate Mouse, the cleanup gets registered.
<vila> indeed, urgh black magic ?
<elopio> vila: yes, without python3-xlib the _X11 imports will fail, so we won't hit the class definintion statement.
<elopio> http://bazaar.launchpad.net/~autopilot/autopilot/trunk/view/head:/autopilot/utilities.py#L330
<elopio> CleanupRegistered = _TestCleanupMeta('CleanupRegistered', (object,), {})
<vila> elopio: trying to reformulate: the bug is that a useless package triggers an unexpected AP behavior because of ... internal reasons ?
<elopio> vila: the bug is that having installed python3-xlib triggers an xlib cleanup which fails on touch.
<elopio> the immediate cause I think is that we are instantiating a keyboard on the testcase, which makes no sense to be, but we need to confirm with veebers.
<vila> elopio: right, xlib shouldn't be installlled on touch. But what if it for other reasons ? As long as AP is not told to care about X11, it shouldn't. No ?
<elopio> s/to be/to me
<vila> right
<elopio> vila: if xlib is installed but we don't instantiate anything from that backend, we are ok.
<elopio> then there's the underlying problem, that's autopilot doing extra stuff on class declarations instead of during __init__.
<vila> elopio: ok, so you're saying adding the keyboard is what trigger the x11 code (what happens if x11 is not there again ?)
<elopio> if x11 is not there, the import will fail, and a evdev keyboard will be instantiated instead.
<elopio> we will never hit the class declaration of Mouse.
<vila> right
<vila> elopio: my kbd is acting
<vila> can't type long sentences :-/
<vila> elopio: is there a way to make these input devices declarations more explicit (instead of relying on installed packages) ?
<elopio> vila: you can choose the backend, and make an explicit if, like we are doing almost everywhere:
<elopio> http://bazaar.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/trunk/view/head:/tests/autopilot/ubuntuuitoolkit/_custom_proxy_objects/_common.py#L45
<elopio> this is one more case where autopilot was designed to be (IMO) unnecessarily smart
<vila> elopio: /me nods
<elopio> vila: but what I'm wondering is about removing these mouse and keyboard properties: http://bazaar.launchpad.net/~autopilot/autopilot/trunk/view/head:/autopilot/testcase.py#L186
<elopio> we have been instantiating the keyboard and mouse on the custom proxy objects for UI widgets that need them. In the apps tests we are never using these properties, so I would deprecate them.
<elopio> the problem is that we instantiate many keyboards and mouses, but it's not too bad as the backend is a singleton.
<vila> elopio: hmpf. I can't say with my limited knowledge... But somehow, if that's where those are created implicitly... That seems to match what we've been talking about |
|
