Closed
Bug 669625
Opened 13 years ago
Closed 10 years ago
Linux/atk support for for e10s
Categories
(Core :: Disability Access APIs, defect)
Tracking
()
RESOLVED
WONTFIX
Tracking | Status | |
---|---|---|
e10s | later | --- |
People
(Reporter: fherrera, Unassigned)
References
Details
(Whiteboard: [e10s])
Attachments
(1 file, 3 obsolete files)
15.62 KB,
patch
|
Details | Diff | Splinter Review |
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•13 years ago
|
||
Notice that this approach depends on at-spi2 based stack to work.
Blocks: 646596
Reporter | ||
Updated•13 years ago
|
Assignee: nobody → fherrera
Reporter | ||
Comment 2•13 years ago
|
||
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•13 years ago
|
||
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•13 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•13 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•13 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•13 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•13 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•13 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•13 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•13 years ago
|
||
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•13 years ago
|
||
Just curious, how can we talk about asap landing (per today meeting) without any review?
Reporter | ||
Comment 13•13 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•13 years ago
|
||
Got it. Yep I've got impression that everything is ready. Thank you.
Updated•13 years ago
|
Whiteboard: [e10s]
Reporter | ||
Comment 15•13 years ago
|
||
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)
Comment 16•13 years ago
|
||
Do you have a stack?
Comment 17•13 years ago
|
||
Trevor could you comment on the patch? I know you have concerns...
Reporter | ||
Comment 18•13 years ago
|
||
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)
Updated•12 years ago
|
Assignee: fherrera → nobody
Updated•10 years ago
|
tracking-e10s:
--- → +
Updated•10 years ago
|
Updated•10 years ago
|
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•