Closed Bug 424971 Opened 12 years ago Closed 12 years ago

"Remember password" alert no longer spoken by screen readers

Categories

(Core :: Disability Access APIs, defect, major)

x86
Windows XP
defect
Not set
major

Tracking

()

VERIFIED FIXED
mozilla1.9

People

(Reporter: MarcoZ, Assigned: MarcoZ)

References

Details

(Keywords: access, regression)

Attachments

(1 file, 1 obsolete file)

This broke somewhere between the 8th and 16th of March. Sorry I can't be more specific, but the Windows builds of March 9 through March 15 immediately crash on startup for me. This was the week I was at CSUN, so hadn't noticed it then. The last good build where this alert still works is March 8, the first working build that has the failure in is March 16.

STR:
1. go to mail.google.com.
2. Enter something for e-mail and password.
3. Press ENTER.

Expected: JAWS should read "Do you want Minefield to remember this password?"
Actual: Nothing of the sort is spoken.
Flags: blocking1.9?
More info: In AccProbe, the hierarchies for the alert and its children are the same for both the good and broken builds. So I suspect it's an event that is missing.

The regression range is
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2008-03-08+00:00&maxdate=2008-03-16+05:00&cvsroot=/cvsroot
The XBL code is supposed to fire AlertActive and we are supposed to respond by firing EVENT_ALERT. Which is not happening?
Right. The alert comes up, I can find it in accProbe and also tab to the buttons, but it is no longer spoken automatically by JAWS.
This sounds like a blocker.
Flags: blocking1.9? → blocking1.9+
Attachment #312035 - Attachment description: Needs testing → Works! Alerts should be delayed in case layout is asynchronously making the ALERT visible. That allows the layout info to be ready when the event is fired.
Attachment #312035 - Flags: review? → review?(marco.zehe)
Marco says:
>  8th of March was still OK, the 16th was broken.

And, the only mozilla/accessible changes during the regression range are bug 421650, bug 420863, bug 419416, bug 421565

Marco, have you checked if backing any of those out fixes it?
It's a regression from bug 421650.
Depends on: 421650
It's probably the PR_FALSE/NULL returns at work again. I can't reproduce the bug otherwise I'd help figure out which one.

Does it work if you just remove lines like:
if (blah.IsEmpty())
  return PR_FALSE;

For example, if accessible name is NULL maybe JAWS doesn't look at the children. And perhaps they fixed it in the version I'm running.
Assignee: aaronleventhal → surkov.alexander
Assignee: surkov.alexander → marco.zehe
Attachment #312035 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #312274 - Flags: review?(aaronleventhal)
Attachment #312035 - Flags: review?(marco.zehe)
Attachment #312274 - Flags: review?(aaronleventhal) → review+
This bug has blocking status, so requesting checkin without prior approval. Thanks!
Keywords: checkin-needed
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Verified fixed using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008032904 Minefield/3.0pre.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.