424971 - "Remember password" alert no longer spoken by screen readers

Status: VERIFIED FIXED

(Core :: Disability Access APIs, defect)

Description

[Marco Zehe (:MarcoZ)]

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.

Comment 1

[Marco Zehe (:MarcoZ)]

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

Comment 2

[Aaron Leventhal]

The XBL code is supposed to fire AlertActive and we are supposed to respond by firing EVENT_ALERT. Which is not happening?

Comment 3

[Marco Zehe (:MarcoZ)]

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.

Comment 4

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

This sounds like a blocker.

Comment 5

[Aaron Leventhal]

Attachment: 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.

Comment 6

[Aaron Leventhal]

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?

Comment 7

[Marco Zehe (:MarcoZ)]

It's a regression from bug 421650.

Comment 8

[Aaron Leventhal]

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.

Comment 9

[Marco Zehe (:MarcoZ)]

Attachment: Remove name.isEmpty check and return of s_false from get_accName for MSAA

Comment 10

[Marco Zehe (:MarcoZ)]

This bug has blocking status, so requesting checkin without prior approval. Thanks!

Comment 11

[Marco Zehe (:MarcoZ)]

Verified fixed using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008032904 Minefield/3.0pre.