https://bugzilla.mozilla.org/show_bug.cgi?id=330624
I'm wondering if this could be contributing to the reports of huge
memory leaks that we're getting with Firefox 1.5. I'd be interested in
knowing answers to the following:
* How can a user tell if Mozilla's accessibility code is enabled for
them? (Preferably in a way that doesn't depend on assuming that the
code that determines whether to enable it is correct.)
* If it is enabled, how can a user turn it off to test the effects of
disabling it?
(In GNOME, what triggers turning on Mozilla's accessibility code is the
preference Desktop -> Preferences -> Accessibility -> Assistive
Techology Support -> Enable assistive technologies. Changing it
requires logging out of GNOME and back in.)
Without knowing the answers to those (and I've poked around a little,
and they don't seem obvious), it's hard to know if this leak could be a
significant part of the reports of huge leaks in Firefox 1.5.
If, in fact, more of our users have this code enabled than we thought,
I'm wondering if release drivers should be more conservative about
approving accessibility fixes during release freezes on the basis that
they only affect users who use screen readers, magnifiers, etc. In
fact, I'm suspicious of such reasoning even if those are the only users
affected, since they deserve the stability that comes from gradually
restricting what can be checked in just as much as other users do.
-David
[1] https://www.redhat.com/archives/olpc-software/2006-March/msg00115.html
--
L. David Baron <URL: http://dbaron.org/ >
Technical Lead, Layout & CSS, Mozilla Corporation
The bug I filed about nsAppRootAccessible is not related to this one.
This one is in cross-platform code in accessible/src/base/.
> David, are the huge leak reports happening on all platforms?
I've heard complaints on both Windows and Linux; not sure about Mac.
I'd also really appreciate if somebody could answer the basic questions
below about detecting and changing whether the accessibility code is
being used.
-David
I agree with you that the accessibility code should receive more
attention from the mainstream rather than being set aside as
"that is only used by a small number of users" --- if nothing
else,
that would potentially lead the access code over time becoming
an interesting source of security attacks.
--Raman
>>>>> "L" == L David Baron <dba...@dbaron.org> writes:
L> I recently (thanks to the X pixmap measurements of some of
L> the folks working on one-laptop-per-child [1]) found that
L> there's a *huge* leak when accessibility is enabled:
L>
L> https://bugzilla.mozilla.org/show_bug.cgi?id=330624
L>
L> I'm wondering if this could be contributing to the reports
L> of huge memory leaks that we're getting with Firefox 1.5.
L> I'd be interested in knowing answers to the following:
L>
L> * How can a user tell if Mozilla's accessibility code is
L> enabled for them? (Preferably in a way that doesn't
L> depend on assuming that the code that determines whether
L> to enable it is correct.)
L>
L> * If it is enabled, how can a user turn it off to test
L> the effects of disabling it?
L>
L> (In GNOME, what triggers turning on Mozilla's
L> accessibility code is the preference Desktop ->
L> Preferences -> Accessibility -> Assistive Techology
L> Support -> Enable assistive technologies. Changing it
L> requires logging out of GNOME and back in.)
L>
L> Without knowing the answers to those (and I've poked
L> around a little, and they don't seem obvious), it's hard
L> to know if this leak could be a significant part of the
L> reports of huge leaks in Firefox 1.5.
L>
L> If, in fact, more of our users have this code enabled than
L> we thought, I'm wondering if release drivers should be
L> more conservative about approving accessibility fixes
L> during release freezes on the basis that they only affect
L> users who use screen readers, magnifiers, etc. In fact,
L> I'm suspicious of such reasoning even if those are the
L> only users affected, since they deserve the stability that
L> comes from gradually restricting what can be checked in
L> just as much as other users do.
L>
L> -David
L>
L> [1]
L> https://www.redhat.com/archives/olpc-software/2006-March/msg00115.html
L>
L> -- L. David Baron <URL: http://dbaron.org/ > Technical
L> Lead, Layout & CSS, Mozilla Corporation
L> _______________________________________________
L> dev-accessibility mailing list
L> dev-acce...@lists.mozilla.org
L> https://lists.mozilla.org/listinfo/dev-accessibility
--
Best Regards,
--raman
Email: ra...@users.sf.net
WWW: http://emacspeak.sf.net/raman/
AIM: emacspeak GTalk: tv.ra...@gmail.com
PGP: http://emacspeak.sf.net/raman/raman-almaden.asc
Google: tv+raman
Thank you for investigating this. I'm CC'ing Ginn Chen from Sun. His
team in Beijing wrote this code. Ginn, will your team be able to look at
this high priority bug? My new guys who will be working on Linux
accessibility haven't started yet.
I believe this is only a problem on Linux. First, the AppRootAccessible
object only exists on Linux. Secondly, the accessibility architecture on
Windows allows us to only create accessible objects if there is an
assistive technology asking for them. We don't even load that
accessibility code at all unless we need it there. On Linux it's not so
smooth. Everything needs to be set up via desktop prefs so it's all or
nothing.
Also, on OS X we never initialize accessibility.
David, are the huge leak reports happening on all platforms?
- Aaron
L. David Baron wrote:
> I recently (thanks to the X pixmap measurements of some of the folks
> working on one-laptop-per-child [1]) found that there's a *huge* leak
> when accessibility is enabled:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=330624
>
> I'm wondering if this could be contributing to the reports of huge
> memory leaks that we're getting with Firefox 1.5. I'd be interested in
> knowing answers to the following:
>
> * How can a user tell if Mozilla's accessibility code is enabled for
> them? (Preferably in a way that doesn't depend on assuming that the
> code that determines whether to enable it is correct.)
>
> * If it is enabled, how can a user turn it off to test the effects of
> disabling it?
>
> (In GNOME, what triggers turning on Mozilla's accessibility code is the
> preference Desktop -> Preferences -> Accessibility -> Assistive
> Techology Support -> Enable assistive technologies. Changing it
> requires logging out of GNOME and back in.)
>
> Without knowing the answers to those (and I've poked around a little,
> and they don't seem obvious), it's hard to know if this leak could be a
> significant part of the reports of huge leaks in Firefox 1.5.
>
> If, in fact, more of our users have this code enabled than we thought,
> I'm wondering if release drivers should be more conservative about
> approving accessibility fixes during release freezes on the basis that
> they only affect users who use screen readers, magnifiers, etc. In
> fact, I'm suspicious of such reasoning even if those are the only users
> affected, since they deserve the stability that comes from gradually
> restricting what can be checked in just as much as other users do.
>
> -David
>
> [1] https://www.redhat.com/archives/olpc-software/2006-March/msg00115.html
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> dev-accessibility mailing list
> dev-acce...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-accessibility
>
Do you think this issue is unique to GNU/Linux? Or to Firefox running
on UNIX in general (e.g. Solaris)?
Regards,
Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.
To follow up on this point, aaronl did find a way to do this:
https://bugzilla.mozilla.org/show_bug.cgi?id=331120#c1
and I just turned it into an extension:
https://addons.mozilla.org/firefox/2407/
that adds an "about:accessibilityenabled" page that says whether
accessibility is or is not active. This is useful (for now) primarily
for users who would like to provide a data point about whether the large
leaks they were saying were related to this bug or not.
-David
--
L. David Baron <URL: http://dbaron.org/ >
Technical Lead, Layout & CSS, Mozilla Corporation