387838 - No focus events for labels in Thunderbird message header

Status: RESOLVED WONTFIX

(Core :: Disability Access APIs, defect)

Description

[Joanmarie Diggs]

Steps to reproduce:

1.  Launch Accerciser and turn on event monitoring
2.  Launch Thunderbird and view/open a message
3.  Press Tab to move among the fields in the header:
    a. Subject (role entry)
    b. From (role label)
    c. Date (role entry)
    d. To (role entry)

Expected results: a focus: event and an object:state-changed:focused event would each be issued for all of the above fields.

Actual results: a focus: event and an object:state-changed:focused event are issued for the entries but not for the labels. (i.e. No events for the From and To fields)

Comment 1

[Damon Sicore (:damons)]

Not blocking 1.9 for this.

Comment 2

[alexander :surkov (:asurkov)]

Thunderbird has the followin hierarchy:

xul:label@class="headerValue" - label accessible
  xul:mail-emailaddress - focusable but it's not accessible
    xul:label - label accessible

when we catch focus event then it sounds we do not fire ally focus event for xul:label.

1) Why do we need top xul:label element?
2) should we fire focus event when non accessible node get DOM focus event and if we should then which accessible should receive it (top on bottom in this case)?
3) Should be mail-emailaddress accessible?

Comment 3

[Ginn Chen]

1) It's the label of the headerName, e.g. label="&fromField.label;", label="&senderField.label;" right?

2) If we want to fire the focus event, I think top is better.

3) I think we should. Because it contains a label and an image.

BTW: I don't get all the children of "expanedHeaderView" in accerciser, is it a known issue?

Comment 4

[Aaron Leventhal]

David Bolter is on leave for the birth of his new daughter.

Comment 5

[Joanmarie Diggs]

In the good news department, it seems we are now getting focus events for *something*. :-)  Looking at accerciser, the hierarchy seems to be:

- ROLE_LABEL (no name)
  - ROLE_UNKNOWN (name is the displayed email address)
    - ROLE_LABEL (name is the displayed email address)

The focus events we're getting are for the item of ROLE_UNKNOWN.  Because we're getting these events, we are able to speak the address being displayed. However, because it's of ROLE_UNKNOWN, we don't present any role information like we do with header fields that are entries (e.g. date and subject). Could this item be given a different role and/or the focus events be for the 2nd label (i.e. the one with a name) and/or the hierarchy changed (are all three of those things needed?).

Also, unlike the header fields that are entries (date and subject), there is no relationship connecting any of the above three accessible objects with the label associated with it/them (e.g. "To:"). As a result, we present the displayed address but cannot reliably indicate which field it is. (I think it would be a brittle solution were we to guess the label based on the current hierarchy.)

Comment 6

[Evan Yan]

Attachment: patch

Comment 7

[David :Bienvenu]

Evan, have you checked the latest trunk code? The header display stuff has changed a lot in the last couple days. The code you changed hasn't, but I'm not sure it's all still used.

Comment 8

[David :Bienvenu]

Comment on attachment 339418 [details] [diff] [review]
patch

Neil might be a better person to review this, since this is shared code.

Comment 9

[Evan Yan]

(In reply to comment #7)
> Evan, have you checked the latest trunk code? The header display stuff has
> changed a lot in the last couple days. The code you changed hasn't, but I'm not
> sure it's all still used.

Thanks for the reminder. It's still used.

Comment 10

[David :Bienvenu]

Comment on attachment 339418 [details] [diff] [review]
patch

Neil, thoughts on this? I suspect the patch doesn't apply thx to Karsten :-) but before I revive it, what do you think it in general?

Comment 11

[David :Bienvenu]

Comment on attachment 339418 [details] [diff] [review]
patch

dmose would be a better person to look at this.

Comment 12

[Dan Mosedale (:dmosedale, :dmose)]

Attachment: patch for both SeaMonkey and Thunderbird

Sorry that it's taken so long to get this reviewed.  Since that patch was written, there's been some bit rot, and mailWidgets.xml was forked so that Thunderbird now has its own copy.  Here's a version of the patch with bitrot fixed, and with a port to the new Thunderbird copy.  Can someone with a screenreader (Evan?) test this new patch against the current Tb source?

Setting both r? and sr? to myself, as this is a pretty straightforward patch.

Comment 13

[Dan Mosedale (:dmosedale, :dmose)]

Comment on attachment 398502 [details] [diff] [review]
patch for both SeaMonkey and Thunderbird

I spoke a little too quickly on the review bit: sr=dmose, because in general it seems fine, but I haven't been able to locate any documentation for nsIAccessibleProvider that would allow me to figure out whether .XULPane is the right constant or not.  So I'm going to delegate r= to mzehe.

Comment 14

[Marco Zehe (:MarcoZ)]

Comment on attachment 398502 [details] [diff] [review]
patch for both SeaMonkey and Thunderbird

Taking this review off my obsoleted e-mail address (why is this still floating around anyway?). :)

Comment 15

[Marco Zehe (:MarcoZ)]

Comment on attachment 398502 [details] [diff] [review]
patch for both SeaMonkey and Thunderbird

>+        <xul:label class="headerName" xbl:inherits="value=label"
>+                   control="emailAddreses"/>

This is a typo, right? Shouldn't this ID be "emailAddresses" like in the one for SeaMonkey below?

Comment 16

[Marco Zehe (:MarcoZ)]

Comment on attachment 398502 [details] [diff] [review]
patch for both SeaMonkey and Thunderbird

With this patch applied, screen readers on Windows will double-speak each e-mail address field when tabbing through. This bug was filed long before bug 449560 was fixed, so I wonder if it is still applicable at all. Focus now moves through the different e-mail address fields, so I believe there is actually no need to re-class a xul:description as a PANE accessible any more.

Comment 17

[Marco Zehe (:MarcoZ)]

Closing WONTFIX because the better fix is in bug 449560, see also Comment #16.

Comment 18

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1527381