Open Bug 420722 Opened 14 years ago Updated 5 years ago
Don't process events for a11y when a11y not being used
Spun off from bug 418845. On Gnome desktops there is a crude switch to tell whether a11y on or off. When it's on, a lot of extra Mozilla a11y code runs, which slows things down and uses up extra memory. On Windows a11y is only turned on by demand, so we don't have this problem. One reasonable solution is to create app, root & doc accessibles when a11y is turned on for Linux, but only start processing events if a11y appears to be used. We need to design that test. My first try is to say that a11y is being used if: 1) the role of the root or doc accessible is requested 2) a descendant accessible of one a root/doc accessible is created
Hm, it really seems like there should be a way for applications to find out which events have registered listeners. Is that not the case?
(In reply to comment #1) > Hm, it really seems like there should be a way for applications to find out > which events have registered listeners. Is that not the case? No, and this doesn't have that level of granularity. I don't think we even need that much detail. We just need to know if a11y is really being used or is on just because it can be. The way Linux deals with this stinks IMO. On Windows we get a window message when an AT makes a request for an accessible object. This indicates to us that something is really happening. Why have a global on/off option on the desktop? Makes no sense. There's a bugzilla.gnome.org bug on this somewhere. In the meantime I think a fix like this would help a lot.
GetRole is called every where, say creating any atk object for Mozilla, we will check role in IsEmbeddedObject(). So this patch is not working as expected. Also, if there's a a11y tool, it waits a special event, say document-load-complete, and then starts working. It may not work after the fix of this bug.
Ginn, can you figure out a way to make something like this work?
I'll try to fix bug 418845 and then check if this bug is really necessary to fix. On Linux, other gnome applications don't have this feature.
Please note related email thread: http://mail.gnome.org/archives/gnome-accessibility-list/2008-October/msg00073.html This bug is pretty serious since some people are really pushing for a faster, but less accessible browser on GNOME.
Actually this is the better thread (mozilla.dev.accessibility): http://groups.google.com/group/mozilla.dev.accessibility/browse_thread/thread/6ca3d1e8d50f19d6#
Ginn, are you still working on this? I think, as David said, this bug is pretty serious.
(In reply to Marco Castelluccio from comment #13) > Ginn, are you still working on this? > I think, as David said, this bug is pretty serious. This bug has major severity but there's no ready-to-wear idea we could follow to fix this bug. It's still on investigation stage and I think it doesn't have real assignee since Ginn is not active in a11y world nowdays, so I don't think he's going to do anything with this bug in nearest future. Initial suggestion from comment #0 is not easy to implement since it requires big core changes, other problem of the suggestion is these are empirical observations that may not work in all cases. Registry API approach is not free of problems and there's no agreement on it. However I would say while there's no any real testing results how slow Firefox is when a11y is running and how much faster it is when a11y sleeps then this bug is interesting from theoretical rather than practical point of view.
from gnome perspective in https://wiki.gnome.org/Accessibility/Roadmap it doesn't lookt like much has changed.
You need to log in before you can comment on or make changes to this bug.