Jaws doesn't update elements with overflow:hidden-style

RESOLVED WORKSFORME

Status

()

Core
Disability Access APIs
RESOLVED WORKSFORME
9 years ago
5 years ago

People

(Reporter: Alexander Farkas, Unassigned)

Tracking

(Blocks: 1 bug)

Trunk
x86
Windows XP
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [bk1], URL)

Attachments

(2 attachments)

(Reporter)

Description

9 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1) Gecko/20090624 Firefox/3.5 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1) Gecko/20090624 Firefox/3.5 (.NET CLR 3.5.30729)

Jaws (10.0.1151) doesn´t update its virtual buffer, if the visibility of an element is toggeld, and this element has an overflow hidden style as well as the toggeling button or the toggeld element uses some WAI-Aria attributes (for example aria-expanded).

Reproducible: Always

Steps to Reproduce:
Go to the demo page http://frontend.aperto.de/jaws-bug/overflow-hidden.html and toggle the first button.
Actual Results:  
The new content of div#slave1 is not updatet in Jaws virtual buffer. You have to update the buffer manually (Ins + Esc).

Expected Results:  
- same result as with the second button.
Surkov, is this specific scenario covered by our mochitests? If so, this bug is invalid because it is not a Firefox bug, but a JAWS one that Freedom Scientific is already aware of.
Component: Disability Access → Disability Access APIs
Product: Firefox → Core
QA Contact: disability.access → accessibility-apis
Version: unspecified → Trunk

Comment 2

8 years ago
I think it's not covered by our mochitests, I mean one to one. But we fire show/hide and reorder events so it could a bit complicated problem. I don't recall how we expose overflow style via AT API if we do this at all (though of course JAWS can get an access to it via ISimpleDOMNode). I supposed it might be states but DOMi reports nothing special.
Summary: Jaws doesn´t update elements with overflow:hidden-style → Jaws doesn't update elements with overflow:hidden-style

Comment 3

7 years ago
Can we get test case on this since the URL is not valid any more?

Comment 4

7 years ago
(In reply to comment #3)
> Can we get test case on this since the URL is not valid any more?

Ping?
Marco,

Would you mind trying to reproduce this and making a test case, if you can?

Thanks,
Whiteboard: [bk1]
(Reporter)

Comment 6

6 years ago
Hi,

sorry, that I haven't answered. I could try to re-create my original testcase on saturday/sunday. It might be possible, that this is already fixed. I haven't seen this bug, since long time. 

cheers.

alex
(Reporter)

Comment 7

6 years ago
Created attachment 572615 [details]
testcase a hidden p element is not updated if it's in a div with overflow: hidden
(Reporter)

Comment 8

6 years ago
Created attachment 572616 [details]
a hidden p element is not updated if it is a direct child of body
(Reporter)

Comment 9

6 years ago
I couldn't find my original tests so I tryed to made a new one, but I'm not sure, wether this is the original bug. In case of a hidden p element, I have to add overflow: hidden not to p but to the direct parent and then it fails to update. 

Note: I have done the tests only with Jaws 10 and old FF 3.6. Both tests do not fail with Jaws 10 and IE8.

I have also added another test, which should been already tracked by you.
Attachment #572615 - Attachment mime type: text/plain → text/html
I believe this is a JAWS bug. With NVDA, I see it working, with JAWS, I can reproduce the bug. I suspect we fire the correct events, but because JAWS is using a different method to get at the content, it fails to update its virtual buffer.

Comment 11

6 years ago
(In reply to Marco Zehe (:MarcoZ) from comment #10)
> I believe this is a JAWS bug. With NVDA, I see it working, with JAWS, I can
> reproduce the bug. I suspect we fire the correct events, but because JAWS is
> using a different method to get at the content, it fails to update its
> virtual buffer.

Marco, we need to make sure we do right things so checking events and tree is a right way to proceed. Working NVDA shouldn't be used as a primary test that everything is ok on our side.
Well, at least this tells us that a) the tree gets updated since NVDA builds its virtual buffer from the tree, and that we fire a reorder event to tell screen readers that an update occurred, or otherwise NVDA's virtual buffer would not update to show the content.

Comment 13

6 years ago
(In reply to Marco Zehe (:MarcoZ) from comment #12)
> Well, at least this tells us that a) the tree gets updated since NVDA builds
> its virtual buffer from the tree, and that we fire a reorder event to tell
> screen readers that an update occurred, or otherwise NVDA's virtual buffer
> would not update to show the content.

I'm not sure how overflow affects on accessible tree so I can't say certainly about tree state. Note, in addition reorder event we fire show/hide events. Anyways NVDA tests is just reflection of our logic, it really gives us a good guess but we should be confident about what we do on our side.
Updating to NEW since several comments confirmed the bug existed.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Blocks: 617918

Comment 15

5 years ago
I can't confirm in JAWS13 on nightly (a test case: after clicking at first button I can read 'some hidden text not working'). Marco, can you try please?
Flags: needinfo?(marco.zehe)
Attachment #572616 - Attachment mime type: text/plain → text/html
I also cannot reproduce this with current Firefox 20 release and JAWS 13 and 14. Note that this was initially tested with Firefox 3.6 and JAWS 10, and that this may have been fixed since Firefox 4 already.
Flags: needinfo?(marco.zehe)

Comment 17

5 years ago
workforme per comment #16 and comment #15
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.