After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 663876 - Make sure the a11y hierarchy under an AtkPlug is generated when embedding
Make sure the a11y hierarchy under an AtkPlug is generated when embedding
Status: RESOLVED FIXED
Product: at-spi
Classification: Platform
Component: at-spi2-atk
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Li Yuan
Depends on:
Blocks:
 
 
Reported: 2011-11-11 18:09 UTC by Mario Sánchez Prada
Modified: 2011-11-12 00:16 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch proposal (1.23 KB, patch)
2011-11-11 18:15 UTC, Mario Sánchez Prada
none Details | Review

Description Mario Sánchez Prada 2011-11-11 18:09:18 UTC
Currently, when using AtkSocket and AtkPlug to connect two a11y hierarchies in different processes, ATs won't notice events happening in the plug's process (e.g. state-change:focused) if the hierarchy hasn't been drilled down yet from the socket's process, which will force those AtkObjects in the plug's process to be generated at that moment.

As a consequence, Orca won't be able to see anything in the plug's process unless it drills down the whole hierarchy first, which is a problem.

I've observed this issue while developing an implementation of AtkSocket and AtkPlug for WebKit2GTK, but others have observed similar problems in other environments, such as Firefox (Fernando Herrera told me the same happens to him).

So, I'd say the solution would be to somehow make sure that the a11y hierarchy under the AtkPlug object, if any, is generated at the very same moment of embedding the plug in the socket, so further emission of events will be visible by ATs monitorizing the socket's process.
Comment 1 Mario Sánchez Prada 2011-11-11 18:15:28 UTC
Created attachment 201248 [details] [review]
Patch proposal

Simple patch that would fix this issue, while not being intrusive at all (it keeps belonging to the Atk bridge's implementation and doesn't add heavy logic at all, just a simple call to get the number of children for the AtkPlug instance.

Tested with my implementation of AtkSocket / AtkPlug for WebKit2GTK
Comment 2 Mike Gorse 2011-11-11 19:46:29 UTC
I don't really understand why this should be needed and wonder if there's a deeper issue somewhere, but on the other hand I don't think it would do any harm, so I'm okay with it going in. I think that a comment referencing the bug number would be useful, to keep a record of why it was added.
Comment 3 Mario Sánchez Prada 2011-11-12 00:16:30 UTC
(In reply to comment #2)
> I don't really understand why this should be needed and wonder if there's a
> deeper issue somewhere, but on the other hand I don't think it would do any
> harm, so I'm okay with it going in.

Yeah, I agree it's a weird patch, but the fact is that after heavily debugging this issue during this week I came down to the conclusion of this being the best and cleanest solution to make sure that the a11y hierarchy in the plug's process is properly initialized when embedding the plug in the socket.

> I think that a comment referencing the bug
> number would be useful, to keep a record of why it was added.

I added a reference to this bug's URL both in the git log message and in a comment in the code before pushing it to the master branch. Now marking as resolved.

Thanks for the feedback and review.