334386 - repeating DHTML Accessibility alert not spoken by WindowEyes 5.5

Status: RESOLVED FIXED

(Firefox :: Disability Access, defect)

Description

[Becky Gibson]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.2) Gecko/20060308 Firefox/1.5.0.2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.2) Gecko/20060308 Firefox/1.5.0.2

When I create an alert using the DHTML accessibility techniques at www.mozilla.org/access/dhtml, it is not spoken by WindowEyes (WE) when it is repeated. 
I will attach a sample file once this bug is submitted. 
When I press the display a single dhtml alert via a button, the alert will be spoken by the WindowEyes screen reader (if it isn't, restart both WE and FF - that is also a problem I need to file). The alert is programmed to be automatically hidden after a few seconds.  If I press the show single alert button again, the alert will not be spoken. If I change focus on the page and then press the button again, it WILL be spoken.
The example also has a button to create a repeating alert. The alert will we displayed and removed in an infinite loop. The first alert will be spoken but subsequent alerts will not be spoken.  Again, if I change the focus on the page between alerts, then each alert will be spoken. 

Reproducible: Always

Steps to Reproduce:
1.Using attached alertex.html file
2.Start WindowEyes 5.5
3.Start Firefox and load alertex.html
3a.press ctrl-shift-a to toggle WE into browse off mode.
4.press the "Create Single Alert" button
5.The alert should be displayed and spoken by WE
6.After the alert disappears, press the "Create Single Alert" button again
7.The alert will display but will not be spoken by WE



Expected Results:  
The alert should be spoken each time it is displayed as long as WindowEyes remains in browse-off mode.

Comment 1

[Becky Gibson]

Attachment: Demonstrates repeating Accessible DHTML alerts

Comment 2

[Aaron Leventhal]

There seem to be problems in both Window-Eyes and Firefox.

Firefox -- not firing another EVENT_ALERT unless alert has disappeared
Window-Eyes -- in the case where another EVENT_ALERT is fired the 2nd is ignored

Wayne, can you file a bug on GW Micro for the Window-Eyes problem?

Comment 3

[Aaron Leventhal]

Mark, did you mean to assign it yourself? The assigned property means the engineer is accepting the bug.

Comment 4

[Aaron Leventhal]

Attachment: Ensure alert events get fired whenever any content inside an alert changes

A fix will still be needed on the Window-Eyes end to allow alerts after the first to be spoken.

Comment 5

[Dan Kinnunen]

Aaron, went to recreate this problem so I could report this to GW Micro and it seems that I cannot recreated this w/ the latest and greatest WE beta 5.5e.

Comment 6

[Dan Kinnunen]

Aaron, for some reason I am able recreate this with WE as suggested, I have opened a bug w/ GW Micro, the current open bug is 3075.

Comment 7

[alexander :surkov (:asurkov)]

in-testsuite+ per bug 591199