669625 - Linux/atk support for for e10s

Status: RESOLVED WONTFIX

(Core :: Disability Access APIs, defect)

Description

[Fernando Herrera]

This bug is to keep track of the Linux/Atk specific work needed for the e10s process content.

The plan is to use AtkPlug / AtkSocket

1.- Get proper accessibility service running on the content processes
2.- Being able to create full accessible trees for each document 
3.- Implement an AtkPlugAccessible wrapper 
4.- Create an AtkPlug for each document  
5.- Create an AtkSocket for each open tab
6.- Tell the chrome (main window) the id of every AtkPlug, so it can be connected on the proper AtkSocket

Comment 1

[Fernando Herrera]

Notice that this approach depends on at-spi2 based stack to work.

Comment 2

[Fernando Herrera]

Attachment: WIP patch1 implementing AtkPlug and hooking it for each nsRootAccessible

This patch implements 1-4 steps from the plan. It prints the plug id into the console. You should get an string like this:

:1.377:/org/a11y/atspi/accessible/8

Then you can use any external AtkSocket program to plug that plugid into it. I'm using this sample program to test it:

https://gitorious.org/atksocket-atkplug-example

Comment 3

[David Bolter [:davidb] (NeedInfo me for attention)]

Comment on attachment 544237 [details] [diff] [review]
WIP patch1 implementing AtkPlug and hooking it for each nsRootAccessible

>+ * The Initial Developer of the Original Code is
>+ * Novell, Inc.

Something you're not telling me? ;)

Comment 4

[Fernando Herrera]

(In reply to comment #3)
> Comment on attachment 544237 [details] [diff] [review] [review]
> WIP patch1 implementing AtkPlug and hooking it for each nsRootAccessible
> 
> >+ * The Initial Developer of the Original Code is
> >+ * Novell, Inc.
> 
> Something you're not telling me? ;)

Haha, copy and pasted header from AtkSocketAccessible.cpp in the same directory :)

Comment 5

[Chris Coulson]

(In reply to comment #1)
> Notice that this approach depends on at-spi2 based stack to work.

This is concerning. What happens on distro's which don't have at-spi2? (eg, in Ubuntu, the only version we have with a supported at-spi2 stack at the moment is 11.10, which is still in development and won't even be released until October). Will accessibility break for users of distro's without at-spi2 in a future Firefox release? The current Ubuntu LTS doesn't have an at-spi2 stack and is supported until April 2013.

Comment 6

[Fernando Herrera]

(In reply to comment #5)
> (In reply to comment #1)
> > Notice that this approach depends on at-spi2 based stack to work.
> 
> This is concerning. What happens on distro's which don't have at-spi2? (eg,
> in Ubuntu, the only version we have with a supported at-spi2 stack at the
> moment is 11.10, which is still in development and won't even be released
> until October). Will accessibility break for users of distro's without
> at-spi2 in a future Firefox release? The current Ubuntu LTS doesn't have an
> at-spi2 stack and is supported until April 2013.


With the current patch distros without at-spi2 _and_ firefox 8, 9 or whatever version e10s got landed into won't show up content process accessible tree. 

Is that a real situation? Distributions more than two years old marked as LTS upgrading to latest firefox? It should be the same when firefox 8, 9 or whatever gets ported to gtk3: some old distros won't have it.

Comment 7

[Chris Coulson]

(In reply to comment #6)
> (In reply to comment #5)
> > (In reply to comment #1)
> > > Notice that this approach depends on at-spi2 based stack to work.
> > 
> > This is concerning. What happens on distro's which don't have at-spi2? (eg,
> > in Ubuntu, the only version we have with a supported at-spi2 stack at the
> > moment is 11.10, which is still in development and won't even be released
> > until October). Will accessibility break for users of distro's without
> > at-spi2 in a future Firefox release? The current Ubuntu LTS doesn't have an
> > at-spi2 stack and is supported until April 2013.
> 
> 
> With the current patch distros without at-spi2 _and_ firefox 8, 9 or
> whatever version e10s got landed into won't show up content process
> accessible tree. 
> 
> Is that a real situation? Distributions more than two years old marked as
> LTS upgrading to latest firefox? It should be the same when firefox 8, 9 or
> whatever gets ported to gtk3: some old distros won't have it.

Well, the plan was that we would just ship the latest stable version of Firefox to all Ubuntu users (although I'm not sure what other distro's are doing here). I thought that this would be the only sane thing to do, rather than try to maintain my own branch and spend 3 years backporting security patches to it. I also thought this is what Mozilla wanted too (although, tbh this isn't really clear to me either)? If this isn't the case, then how on earth are we meant to support Firefox at all? :/

Comment 8

[Fernando Herrera]

Well, we could detect at runtime if we are running a newer enough version of atk to use atkplug/socket, and if not, we can place those content process accessible subtree at top level tree (like a new window per teb from the a11y point of view).

Comment 9

[Chris Coulson]

If that's possible, then that would be great. Is that a lot of extra work? Sorry for being a bit of a pain.

Comment 10

[Fernando Herrera]

(In reply to comment #9)
> If that's possible, then that would be great. Is that a lot of extra work?
> Sorry for being a bit of a pain.

Well, I got that working yesterday before placing the atkplug code. It is more about keeping codepaths to support old envs. Anyway we should check with orca guys that this is a reasonable solution for the case of old distro with old libs + latest firefox.

Comment 11

[Fernando Herrera]

Attachment: WIP patch2

This new WIP patch adds steps 5 and 6 support:

When a content process creates a new Root element, it send the AtkPlug id  though IPC (using TabChild class) to the parent. At that point the parent destroys any accessible child from the FrameElement accesible, creates a new AtkSocket and connect to the plug using that id.

Comment 12

[alexander :surkov (:asurkov)]

Just curious, how can we talk about asap landing (per today meeting) without any review?

Comment 13

[Fernando Herrera]

(In reply to comment #12)
> Just curious, how can we talk about asap landing (per today meeting) without
> any review?

Not at all, sorry if that was the impression from the meeting. I was asking about the target time for landing: anytime soon or when e10s branch is close to be merged on trunk (around March?). In both cases that should happen after proper discussion, testing and reviews.

Comment 14

[alexander :surkov (:asurkov)]

Got it. Yep I've got impression that everything is ready. Thank you.

Comment 15

[Fernando Herrera]

Attachment: WIP patch3

Updated patch removing the a11y service init and moving the plug/socket creation to nsRootAccessible Wrap as per Trevor suggestion.

There is a problem with this version causing a segfault in the content processes that I cannot figure out right now. Trevor, can you take a look at it?

Comment 16

[David Bolter [:davidb] (NeedInfo me for attention)]

Do you have a stack?

Comment 17

[David Bolter [:davidb] (NeedInfo me for attention)]

Trevor could you comment on the patch? I know you have concerns...

Comment 18

[Fernando Herrera]

Attachment: WIP patch v4

This is an updated version of the patch working with current mozilla-central.

The plug/socket creation is done in this patch at nsAccDocManager::CreateDocOrRootAccessible beacuase doing it at nsRootAccessible Wrap constructor is failing. I'll investigate that and I'll update the patch