CSS "display" property and the accessible tree

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

CSS "display" property and the accessible tree

Lukas Loehrer
Hi all,

I am using Minefield from March 31st. My AT extension uses the accessible
tree from Javascript via nsIAccessible and related interfaces. I ran
into the following problem:

As one would expect, DOM nodes that have the CSS display property set
to "none" do not appear in the accessible tree. The problem I
encountered occurs when this property is changed dynamically in
javascript. It seems that the accessible tree is not always updated to
reflect such changes. I would expect that when javascript changes the
display property from "none" to "block", the affected nodes would
appear in the accessible tree and some accessible event is fired. This
is not the case as far as I can tell.

Is this a known problem? I could not find a corresponding bug. I can
post a simple test case with more information if this problem is not
known already.

Best regards, Lukas
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: CSS "display" property and the accessible tree

David Bolter
Thanks Lucas.  I couldn't find a bug for this either although it might
intersect another bug.  I don't see the harm in filing one with more
detail about this problem and your test case. If you do create one
please reply here with the link as I'm interested in dom cache synching
issues which possibly relates.

cheers,
David

Lukas Loehrer wrote:

> Hi all,
>
> I am using Minefield from March 31st. My AT extension uses the accessible
> tree from Javascript via nsIAccessible and related interfaces. I ran
> into the following problem:
>
> As one would expect, DOM nodes that have the CSS display property set
> to "none" do not appear in the accessible tree. The problem I
> encountered occurs when this property is changed dynamically in
> javascript. It seems that the accessible tree is not always updated to
> reflect such changes. I would expect that when javascript changes the
> display property from "none" to "block", the affected nodes would
> appear in the accessible tree and some accessible event is fired. This
> is not the case as far as I can tell.
>
> Is this a known problem? I could not find a corresponding bug. I can
> post a simple test case with more information if this problem is not
> known already.
>
> Best regards, Lukas
> _______________________________________________
> dev-accessibility mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-accessibility
>  

_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: CSS "display" property and the accessible tree

Aaron Leventhal-3
In reply to this post by Lukas Loehrer
Lukas,

It should work as you're describing. In fact we've
worked hard to make it work that way.

In MSAA, you should get EVENT_REORDER on the
parent of the item that becomes shown/hidden,
along with EVENT_SHOW/EVENT_HIDE on the individual
object that is shown/hidden.

Under ATK/AT-SPI there should be children-changed
events, although my understanding is we need to do
some work there.

If it's not working as expected, it's a bug, so
please file it with a simple test case.

- Aaron


Lukas Loehrer wrote:

> Hi all,
>
> I am using Minefield from March 31st. My AT extension uses the accessible
> tree from Javascript via nsIAccessible and related interfaces. I ran
> into the following problem:
>
> As one would expect, DOM nodes that have the CSS display property set
> to "none" do not appear in the accessible tree. The problem I
> encountered occurs when this property is changed dynamically in
> javascript. It seems that the accessible tree is not always updated to
> reflect such changes. I would expect that when javascript changes the
> display property from "none" to "block", the affected nodes would
> appear in the accessible tree and some accessible event is fired. This
> is not the case as far as I can tell.
>
> Is this a known problem? I could not find a corresponding bug. I can
> post a simple test case with more information if this problem is not
> known already.
>
> Best regards, Lukas
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: CSS "display" property and the accessible tree

Lukas Loehrer

Thanks for the information. It helps to know that this is supposed to
work.

I did some testing with other ATs and found that jaws and nvda work
find with the example.

Using my current test case [1] with lsr on Linux, Firefox crashes when
exploring the page after toggling the display property twice. At least
it can see the first change in visibility correctly.

I will have to look into this further.

Best regards, Lukas

[1] http://homepage.hispeed.ch/loehrer/firemacs/tests/display.html

Aaron Leventhal writes ("Re: CSS "display" property and the
accessible tree"): > Lukas, > > It should work as you're describing.
In fact we've > worked hard to make it work that way. > > In MSAA, you
should get EVENT_REORDER on the > parent of the item that becomes
shown/hidden, > along with EVENT_SHOW/EVENT_HIDE on the individual >
object that is shown/hidden. > > Under ATK/AT-SPI there should be
children-changed > events, although my understanding is we need to do
> some work there. > > If it's not working as expected, it's a bug, so
> please file it with a simple test case. > > - Aaron > > > Lukas
Loehrer wrote: > > Hi all, > > > > I am using Minefield from March
31st. My AT extension uses the accessible > > tree from Javascript via
nsIAccessible and related interfaces. I ran > > into the following
problem: > > > > As one would expect, DOM nodes that have the CSS
display property set > > to "none" do not appear in the accessible
tree. The problem I > > encountered occurs when this property is
changed dynamically in > > javascript. It seems that the accessible
tree is not always updated to > > reflect such changes. I would expect
that when javascript changes the > > display property from "none" to
"block", the affected nodes would > > appear in the accessible tree
and some accessible event is fired. This > > is not the case as far as
I can tell. > > > > Is this a known problem? I could not find a
corresponding bug. I can > > post a simple test case with more
information if this problem is not > > known already. > > > > Best
regards, Lukas >
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: CSS "display" property and the accessible tree

Lukas Loehrer
In reply to this post by Aaron Leventhal-3

I did some more research and I am now pretty sure the problem is
limited to the Linux version of Firefox. When I run my AT extension in
the exact same Minefield build under Windows, everything works fine,
i.e. the accessible tree is updated and Firefox does not crash, even
after toggling the "display" property many times. The curious thing is
that I do not use MSAA or ATK/AT-SPI at all. I only access the
accessible tree from javascript and communicate the extracted
information to emacspeak via TCP/IP. I also tried running Firefox in an X
session with accessibility support disabled and the problem persisted,
so it is not due to interactions of Firefox with other AT like orca or
lsr.

Best regards, Lukas

Aaron Leventhal writes ("Re: CSS "display" property and the accessible tree"):

> Lukas,
>
> It should work as you're describing. In fact we've
> worked hard to make it work that way.
>
> In MSAA, you should get EVENT_REORDER on the
> parent of the item that becomes shown/hidden,
> along with EVENT_SHOW/EVENT_HIDE on the individual
> object that is shown/hidden.
>
> Under ATK/AT-SPI there should be children-changed
> events, although my understanding is we need to do
> some work there.
>
> If it's not working as expected, it's a bug, so
> please file it with a simple test case.
>
> - Aaron
>
>
> Lukas Loehrer wrote:
> > Hi all,
> >
> > I am using Minefield from March 31st. My AT extension uses the accessible
> > tree from Javascript via nsIAccessible and related interfaces. I ran
> > into the following problem:
> >
> > As one would expect, DOM nodes that have the CSS display property set
> > to "none" do not appear in the accessible tree. The problem I
> > encountered occurs when this property is changed dynamically in
> > javascript. It seems that the accessible tree is not always updated to
> > reflect such changes. I would expect that when javascript changes the
> > display property from "none" to "block", the affected nodes would
> > appear in the accessible tree and some accessible event is fired. This
> > is not the case as far as I can tell.
> >
> > Is this a known problem? I could not find a corresponding bug. I can
> > post a simple test case with more information if this problem is not
> > known already.
> >
> > Best regards, Lukas
>
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: CSS "display" property and the accessible tree

T.V Raman

Definitely looks like a linux-specific Firefox bug.



Lukas Loehrer writes:
 >
 > I did some more research and I am now pretty sure the problem is
 > limited to the Linux version of Firefox. When I run my AT extension in
 > the exact same Minefield build under Windows, everything works fine,
 > i.e. the accessible tree is updated and Firefox does not crash, even
 > after toggling the "display" property many times. The curious thing is
 > that I do not use MSAA or ATK/AT-SPI at all. I only access the
 > accessible tree from javascript and communicate the extracted
 > information to emacspeak via TCP/IP. I also tried running Firefox in an X
 > session with accessibility support disabled and the problem persisted,
 > so it is not due to interactions of Firefox with other AT like orca or
 > lsr.
 >
 > Best regards, Lukas
 >
 > Aaron Leventhal writes ("Re: CSS "display" property and the accessible tree"):
 > > Lukas,
 > >
 > > It should work as you're describing. In fact we've
 > > worked hard to make it work that way.
 > >
 > > In MSAA, you should get EVENT_REORDER on the
 > > parent of the item that becomes shown/hidden,
 > > along with EVENT_SHOW/EVENT_HIDE on the individual
 > > object that is shown/hidden.
 > >
 > > Under ATK/AT-SPI there should be children-changed
 > > events, although my understanding is we need to do
 > > some work there.
 > >
 > > If it's not working as expected, it's a bug, so
 > > please file it with a simple test case.
 > >
 > > - Aaron
 > >
 > >
 > > Lukas Loehrer wrote:
 > > > Hi all,
 > > >
 > > > I am using Minefield from March 31st. My AT extension uses the accessible
 > > > tree from Javascript via nsIAccessible and related interfaces. I ran
 > > > into the following problem:
 > > >
 > > > As one would expect, DOM nodes that have the CSS display property set
 > > > to "none" do not appear in the accessible tree. The problem I
 > > > encountered occurs when this property is changed dynamically in
 > > > javascript. It seems that the accessible tree is not always updated to
 > > > reflect such changes. I would expect that when javascript changes the
 > > > display property from "none" to "block", the affected nodes would
 > > > appear in the accessible tree and some accessible event is fired. This
 > > > is not the case as far as I can tell.
 > > >
 > > > Is this a known problem? I could not find a corresponding bug. I can
 > > > post a simple test case with more information if this problem is not
 > > > known already.
 > > >
 > > > Best regards, Lukas
 > >
 > _______________________________________________
 > dev-accessibility mailing list
 > [hidden email]
 > https://lists.mozilla.org/listinfo/dev-accessibility

--
Best Regards,
--raman

Title:  Research Scientist      
Email:  [hidden email]
WWW:    http://emacspeak.sf.net/raman/
Google: tv+raman
GTalk:  [hidden email], [hidden email]
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc

_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: CSS "display" property and the accessible tree

Aaron Leventhal-3
In reply to this post by Aaron Leventhal-3
Lukas,

Have you filed a bug on this?

- Aaron

Lukas Loehrer wrote:

> I did some more research and I am now pretty sure the problem is
> limited to the Linux version of Firefox. When I run my AT extension in
> the exact same Minefield build under Windows, everything works fine,
> i.e. the accessible tree is updated and Firefox does not crash, even
> after toggling the "display" property many times. The curious thing is
> that I do not use MSAA or ATK/AT-SPI at all. I only access the
> accessible tree from javascript and communicate the extracted
> information to emacspeak via TCP/IP. I also tried running Firefox in an X
> session with accessibility support disabled and the problem persisted,
> so it is not due to interactions of Firefox with other AT like orca or
> lsr.
>
> Best regards, Lukas
>
> Aaron Leventhal writes ("Re: CSS "display" property and the accessible tree"):
>> Lukas,
>>
>> It should work as you're describing. In fact we've
>> worked hard to make it work that way.
>>
>> In MSAA, you should get EVENT_REORDER on the
>> parent of the item that becomes shown/hidden,
>> along with EVENT_SHOW/EVENT_HIDE on the individual
>> object that is shown/hidden.
>>
>> Under ATK/AT-SPI there should be children-changed
>> events, although my understanding is we need to do
>> some work there.
>>
>> If it's not working as expected, it's a bug, so
>> please file it with a simple test case.
>>
>> - Aaron
>>
>>
>> Lukas Loehrer wrote:
>>> Hi all,
>>>
>>> I am using Minefield from March 31st. My AT extension uses the accessible
>>> tree from Javascript via nsIAccessible and related interfaces. I ran
>>> into the following problem:
>>>
>>> As one would expect, DOM nodes that have the CSS display property set
>>> to "none" do not appear in the accessible tree. The problem I
>>> encountered occurs when this property is changed dynamically in
>>> javascript. It seems that the accessible tree is not always updated to
>>> reflect such changes. I would expect that when javascript changes the
>>> display property from "none" to "block", the affected nodes would
>>> appear in the accessible tree and some accessible event is fired. This
>>> is not the case as far as I can tell.
>>>
>>> Is this a known problem? I could not find a corresponding bug. I can
>>> post a simple test case with more information if this problem is not
>>> known already.
>>>
>>> Best regards, Lukas
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: CSS "display" property and the accessible tree

Lukas Loehrer
Aaron Leventhal writes ("Re: CSS "display" property and the accessible tree"):
> Have you filed a bug on this?

No not yet, But I am planning to do so. I managed to provoke a crash on
Windows too, though with a more complicated example, so I can use the
talkback agent there with jaws I hope.

Am I right to assume that a Firefox extension that only uses
javascript should in theory never be able to crash the browser? I am
asking because I want to make sure the crash is not due to a bug in my extension.

Best regards, Lukas
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: CSS "display" property and the accessible tree

Aaron Leventhal-3
In reply to this post by Aaron Leventhal-3
Correct, you should never be able to crash the
browser.

When you file it, can you specify what happens on
each platform for both Firefox 2 and Firefox trunk?

Thanks,

- Aaron


Lukas Loehrer wrote:

> Aaron Leventhal writes ("Re: CSS "display" property and the accessible tree"):
>> Have you filed a bug on this?
>
> No not yet, But I am planning to do so. I managed to provoke a crash on
> Windows too, though with a more complicated example, so I can use the
> talkback agent there with jaws I hope.
>
> Am I right to assume that a Firefox extension that only uses
> javascript should in theory never be able to crash the browser? I am
> asking because I want to make sure the crash is not due to a bug in my extension.
>
> Best regards, Lukas
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: CSS "display" property and the accessible tree

Lukas Loehrer
Aaron Leventhal writes ("Re: CSS "display" property and the accessible tree"):
> Correct, you should never be able to crash the
> browser.
>
> When you file it, can you specify what happens on
> each platform for both Firefox 2 and Firefox trunk?

I have filed a bug report with two talkback reports:

https://bugzilla.mozilla.org/show_bug.cgi?id=376924

The problem is that their are really two aspects to this bug: the
crashes and the sometimes incorrect updates to the accessible tree. I
have concentrated on the crash aspect in the report so far.

As for Firefox 2: I will try later if my testing code works on it at
all.

Best regards, Lukas
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility