903 bytes, text/html
686 bytes, text/html
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.
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.
Can we get test case on this since the URL is not valid any more?
(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,
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
Created attachment 572615 [details] testcase a hidden p element is not updated if it's in a div with overflow: hidden
Created attachment 572616 [details] a hidden p element is not updated if it is a direct child of body
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.
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.
(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.
(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.
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?
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.
workforme per comment #16 and comment #15