Closed Bug 334386 Opened 14 years ago Closed 14 years ago

repeating DHTML Accessibility alert not spoken by WindowEyes 5.5


(Firefox :: Disability Access, defect)

Windows XP
Not set





(Reporter: gibson.becky, Assigned: aaronlev)



(Keywords: fixed1.8.1)


(2 files)

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

When I create an alert using the DHTML accessibility techniques at, 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 ctrl-shift-a to toggle WE into browse off mode. 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.
Ever confirmed: true
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?
Mark, did you mean to assign it yourself? The assigned property means the engineer is accepting the bug.
Assignee: nobody → pilgrim
Blocks: fox2access
Assignee: pilgrim → aaronleventhal
A fix will still be needed on the Window-Eyes end to allow alerts after the first to be spoken.
Attachment #219197 - Flags: review?(ginn.chen)
Attachment #219197 - Flags: review?(ginn.chen) → review+
Attachment #219197 - Flags: superreview?(bzbarsky)
Attachment #219197 - Flags: superreview?(bzbarsky) → superreview+
Attachment #219197 - Flags: approval-branch-1.8.1?(ginn.chen)
Closed: 14 years ago
Resolution: --- → FIXED
Attachment #219197 - Flags: approval-branch-1.8.1?(ginn.chen) → approval-branch-1.8.1+
Keywords: fixed1.8.1
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.
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.
Flags: in-testsuite?
in-testsuite+ per bug 591199
Flags: in-testsuite? → in-testsuite+
You need to log in before you can comment on or make changes to this bug.