GNOME Bugzilla – Bug 784509
wrong coordinates given to at-spi layer from GTK3 entries
Last modified: 2017-10-15 11:58:59 UTC
When trying to get position from entry text, after an event received through atspi a11y layer, the base text position is wrongly shifted. It looks like the in-text offset of the caret is responsive, meaning when we type a couple letters, it increments the position in Y coordinates correctly. However, the base position of text is shifted to the north-west, like it's missing some in-grid offset, maybe the base text widget position inside the grid. It looks like the text is wrongly located to the north-west corner of the window (or grid), just under window decorations. note: the base widget is rightly positioned, only the text inside is affected. It is blocking for any a11y tool making these events accessible, like software magnifiers such as gnome3 zoom or compiz's ezoom with focus tracking. result is unreadable by visually impaired people. I can try and provide a reproducible example is needed. please consider a quick fix. thank you for reading.
(In reply to ksamak from comment #0) > I can try and provide a reproducible example is needed. Yes, please - always!
Created attachment 357697 [details] wrong upload
I attached a test script that shows an entry. The script reacts with a11y events, pointing the mouse where a change is detected in entries. the base label that the scripts creates works, but the bug appears in mate's suite's labels, like the launch menu (alt-F2) or mate-search-tool. Is it because they are using custom widgets? Anyway i'll try and get someone from mate to have a look too. please indicate me if it's up to them to fix it, i'll forward the bug.
Thanks. (In reply to ksamak from comment #3) > Is it because they are using custom widgets? > > Anyway i'll try and get someone from mate to have a look too. please > indicate me if it's up to them to fix it, i'll forward the bug. I don't know if MATE is using custom widgets. Can you ask them what they're doing, and report back here what the answer is?
Created attachment 357743 [details] test script I attached a test script that shows an entry. The script reacts with a11y events, pointing the mouse where a change is detected in entries. the base label that the scripts creates works, but the bug appears in mate's suite's labels, like the launch menu (alt-F2) or mate-search-tool. Is it because they are using custom widgets? Anyway i'll try and get someone from mate to have a look too. please indicate me if it's up to them to fix it, i'll forward the bug.
Again, we need to know what MATE are doing, so we can ascertain what's going on and whether it's on either the GTK+ or MATE side specifically. It'd be appreciated if you could find out from them what the widgets you mentioned are and how they're implemented. Even just get them to give you links to the source files of a couple of widgets that you know exhibit this problem. Then you can paste those links here and we'll have somewhere to start from. Otherwise this depends on someone here doing the legwork of going and figuring out what a third party is doing with GTK+ widgets, which is less likely to happen quickly - and ideally would be done by someone with passing knowledge of MATE (probably someone here has that; it's just not me). Anyway, thanks for the info so far, and let us know if you find out any more.
(In reply to ksamak from comment #5) > Created attachment 357743 [details] > test script > > I attached a test script that shows an entry. The script reacts with a11y > events, pointing the mouse where a change is detected in entries. > > the base label that the scripts creates works, but the bug appears in mate's > suite's labels, like the launch menu (alt-F2) or mate-search-tool. Is it > because they are using custom widgets? Hello Ksamak, As I remember the bug also appears in network-manager password edit box. Do you confirm this ? Could you also reproduced the bug on gnome-flashback run command dialog ? Best regards.
I can confirm the issue with our alt-f2 dialog in MATE. To clarify, we use Gtk widgets, we don't have any own hand baked widgets like ie. firefox. Just like gnome2....
I forgot...it' a GtkEntry.
So it seems it is the same for ne
... for network-manager. I don't see any reason to override a one-line entry text. The use case into Network-manager is the WiFi password.
Created attachment 359355 [details] demo script
to be clear: The idea of providing global coordinates to a11y tools _from the client-side_ is doomed in the long term. This information is simply not available to clients under Wayland. I haven't investigated what is going wrong in this particular case, but I wanted to provide some background as to why this may not be high up on this list of bugs to fix...
Created attachment 360840 [details] testcase Hello, Just to avoid MATE/nm/etc. questions, the script itself can be modified to show the bug. I have attached a modified version: the first text entry behaves correctly. The second text entry has the shifting issue: the mouse is moved as if the text entry was at the top of the window instead of below the first text entry. Samuel
Created attachment 360969 [details] [review] proposed fix Hello, It seems what is missing is simply the "allocation" part of x/y coordinates. Since gtk_entry_realize doesn't call gtk_widget_set_window(priv->text_area), the coordinates returned by gdk_window_get_origin don't include it. The attached patch fixes this. Samuel
Review of attachment 360969 [details] [review]: ::: gtk/a11y/gtkentryaccessible.c @@ +975,3 @@ + GtkAllocation allocation; + gtk_widget_get_allocation(widget, &allocation); I've not thought much about the sense of it, or whether there's a maybe a better way, but in terms of style it'd need a space before the opening parenthesis.
BTW, yes the absolute coordinate can't be obtained in wayland, but we will still need the coordinate relative to the application window (to be added to the compositor-provided window position), so the fix is needed for that too :)
Created attachment 360971 [details] [review] proposed fix Here it is with fixed coding style.
Hello Samuel and all, I've tested this fix with the compiz screen magnifier and its focus tracking, it works great now on the mate run dialog. It is awesome ! Best regards.
Review of attachment 360971 [details] [review]: ok
Thanks for the patch! Though a git-formatted one would be better next time. I fixed that up and pushed it.
Created attachment 361615 [details] [review] a11y/entry: Fixups for previous commit We still declare all variables at the start of the block. Also, we can use the fast private _gtk_widget_get_allocation().
Comment on attachment 361615 [details] [review] a11y/entry: Fixups for previous commit Attachment 361615 [details] pushed as 6018f90 - a11y/entry: Fixups for previous commit