Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1517301 - At-spi returns incorrect object positions on wayland
Summary: At-spi returns incorrect object positions on wayland
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: at-spi2-core
Version: 7.5
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: ---
Assignee: Matthias Clasen
QA Contact: Desktop QE
Depends On:
Blocks: 1520787 1520786
TreeView+ depends on / blocked
Reported: 2017-11-24 14:56 UTC by Vitezslav Humpa
Modified: 2019-02-06 10:45 UTC (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1520786 (view as bug list)
Last Closed: 2019-02-06 10:45:23 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
GNOME Bugzilla 710012 None None None 2019-02-13 14:53:12 UTC

Description Vitezslav Humpa 2017-11-24 14:56:38 UTC
Description of problem:
When running under Wayland session (via gnome-session-wayland-session), at-spi component.queryComponent().getPosition() does always return the coordinates for CoordType.WINDOW even for when we demand CoordType.SCREEN.

In effect this means, we're unable to get positions of objects in respect to the screen (only window - so i.e. a button will always return the same screen position no matter where the window has moved). Which means we do not have valid coordinates for a subsequent action most importantly a mouse event (which itself also doesn't work under wayland, which is related other issue I am filing)

This is somewhat of a deal-breaker for our entire pyatspi/dogtail based desktop test set as far as Wayland goes (and most importantly Fedora and RHEL8 desktop testing) - as we can see and work with the at-spi tree just fine but are unable to make actions via generateMouseEvent and generateKeyboardEvent methods (invoking the a11y actions directly via do_action() is not enough for a good deal of object types that don't have them defined - but have positions and can be clicked directly).

Version-Release number of selected component (if applicable):
at-spi2-core-2.22.0-1.el7.x86_64, pyatspi-2.20.3-1.el7.noarch

How reproducible:
Best via dogtail/pyatspi (best get i.e. here for rhel-7.5 (as well as F27):

Run gedit.

$ python
import pyatspi
from dogtail.tree import root
app = root.application('gedit')
node = app.child('Open') # the open button
node.position # dogtail's wrapper, OR:
# directly via pyatspi
(32, 24)
# move window somewhere else
(32, 24) # still (0, 0) is always the corner of the window, not screen

Additional info:
Indeed same on Fedora.
We do realize this issue in core might run into very design conception of wayland, though we need this resolved and will be glad for any help. Some ideas were discussed before in these somewhat related bugs: and

Comment 3 Bastien Nocera 2018-01-31 14:42:15 UTC
There's no support for this under Wayland.

See and

Comment 4 Tomas Pelka 2018-02-01 09:01:14 UTC
Thanks Bastien for failing the issue in upstream github.

We do understand that that a11y is potential security threat and might violate all the clients isolation concept of Wayland. And also a11y is quite old and expect stuff that might not be valid for modern desktop. But unfortunately all our automation depends on atspi and therefore on a11y too. Without it we can simply throw 90% of all our automation.

Based on talk with Matthias here are two points he made and QE can second them:
1) we can either hack/enable a11y just for testing purposes
2) in theory as mutter is the compositor responsible for drawing windows and widgets it should know their positions. So it might be possible to expose interface(s) over dbus and get what we need from mutter it self.

Comment 6 Red Hat Bugzilla Rules Engine 2018-02-12 17:34:14 UTC
Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.

Comment 10 Vitezslav Humpa 2019-02-06 10:45:23 UTC
Same reason as in - closing as not a bug. Also I presume that the solution that was done to overcome this in the upstream and RHEL-8.0 forward won't be needed for the rest of EL7 lifetime.

Note You need to log in before you can comment on or make changes to this bug.