STR: 1. Start Thunderbird nightly. 2. Press CTRL+N to start a new message. 3. You land in the textbox where you can enter an address. 4. Shift+Tab to the combo where you can choose whether this is a to: CC: etc., address. Notice that NVDA will read the entries correctly as you arrow up and down. 5. Choose TO. (which was chosen in the beginning), and tab forward again. Enter an address like my e-mail address. 6. Press ENTER. This will create a new row for a second address. 7. Shift-Tab back again to choose that this new address will be a CC. Bug: Notice that, when arrowing, NVDA will not announce anything. Inspection shows that neither the combobox, nor its child accessibles, are being created for this field selection. This is reproducible 100% of the time when composing a new message, or when replying and adding an address by pressing ENTER after the last current address to add a new one. I'm also seeing this in Thunderbird 5, so this is probably a regression from the tree creation work we did for Firefox 4.
I'm not sure if this is related and haven't had a chance to investigate it myself yet, but NVDA users are also reporting trouble reading the addressee suggestions in the addressee entry fields. See http://www.nvda-project.org/ticket/1623 and http://www.nvda-project.org/ticket/1689
I can reproduce this issue, but I see worse than described. I'll intersperse my findings with Marco's original str: (In reply to Marco Zehe (:MarcoZ) from comment #0) > 1. Start Thunderbird nightly. > 2. Press CTRL+N to start a new message. > 3. You land in the textbox where you can enter an address. > 4. Shift+Tab to the combo where you can choose whether this is a to: CC: > etc., address. > Notice that NVDA will read the entries correctly as you arrow up and down. > 5. Choose TO. (which was chosen in the beginning), and tab forward again. > Enter an address like my e-mail address. > 6. Press ENTER. This will create a new row for a second address. Actual: Focus is fired on the row accessible for the recipient. The row accessible has no children. Expected: Focus should be fired on the editable text field for the recipient address, which should be contained in the second cell of the row. > 7. Shift-Tab back again to choose that this new address will be a CC. Actual: The focus does not move. Expected: The focus should move to the combo box for the recipient type, which should be contained in the first cell of the row. Interestingly: 8. Press tab to move back to the recipient address field. 9. Type a character; e.g. z. Result: The row loses the focused state. The cells for the two fields magically appear as children of the row. The editable text field inside the combo box inside the second cell gets the focused state as it should, but no focus event is fired. Tested with Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a1) Gecko/20111007 Thunderbird/10.0a1
On the odd/unlikely chance that it might be fixed first and provide relief for this problem, I mention Bug 449299 - (tabbed_composition) Allow opening compose window in new tab (write messages in tabs; writing, composing mail)
Fixed by bug 656225.
Verified fixed in Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120329 Thunderbird/14.0a1