Linux/atk support for for e10s

RESOLVED WONTFIX

Status

()

Core
Disability Access APIs
RESOLVED WONTFIX
7 years ago
4 years ago

People

(Reporter: Fernando Herrera, Unassigned)

Tracking

unspecified
x86
Linux
Points:
---

Firefox Tracking Flags

(e10slater)

Details

(Whiteboard: [e10s])

Attachments

(1 attachment, 3 obsolete attachments)

(Reporter)

Description

7 years ago
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
(Reporter)

Comment 1

7 years ago
Notice that this approach depends on at-spi2 based stack to work.
Blocks: 646596
(Reporter)

Updated

7 years ago
Assignee: nobody → fherrera
(Reporter)

Comment 2

7 years ago
Created attachment 544237 [details] [diff] [review]
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 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? ;)
(Reporter)

Comment 4

7 years ago
(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

7 years ago
(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.
(Reporter)

Comment 6

7 years ago
(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

7 years ago
(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? :/
(Reporter)

Comment 8

7 years ago
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

7 years ago
If that's possible, then that would be great. Is that a lot of extra work? Sorry for being a bit of a pain.
(Reporter)

Comment 10

7 years ago
(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.
(Reporter)

Comment 11

7 years ago
Created attachment 544592 [details] [diff] [review]
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.
Attachment #544237 - Attachment is obsolete: true

Comment 12

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

Comment 13

6 years ago
(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

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

Updated

6 years ago
Whiteboard: [e10s]
(Reporter)

Comment 15

6 years ago
Created attachment 550918 [details] [diff] [review]
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?
Attachment #544592 - Attachment is obsolete: true
Attachment #550918 - Flags: feedback?(trev.saunders)
Do you have a stack?
Trevor could you comment on the patch? I know you have concerns...
(Reporter)

Comment 18

6 years ago
Created attachment 569599 [details] [diff] [review]
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
Attachment #550918 - Attachment is obsolete: true
Attachment #550918 - Flags: feedback?(trev.saunders)
Assignee: fherrera → nobody
tracking-e10s: --- → +
tracking-e10s: + → later
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.