Closed Bug 1729314 Opened 1 year ago Closed 11 months ago

Attachment bar is not accessible

Categories

(Thunderbird :: Message Compose Window, defect)

defect

Tracking

(thunderbird_esr91 wontfix)

RESOLVED FIXED
94 Branch
Tracking Status
thunderbird_esr91 --- wontfix

People

(Reporter: henry, Assigned: henry)

References

(Blocks 3 open bugs)

Details

(Keywords: access)

Attachments

(1 file)

The attachment area is meant to open/close on clicking the attachment bar. However, it cannot be focussed through the keyboard. Nor is this expanding behaviour advertised to the accessibility tree (e.g. with aria-expanded).

We can replace this area with a <html:details>, which handles the semantics and behaviour for us.

affects version 91?

(In reply to Wayne Mery (:wsmwk) from comment #2)

affects version 91?

Yes, this isn't a regression. The attachment toolbar is old markup.

See Also: → 1729714
Blocks: tb91found
Keywords: access
See Also: → 1719350

Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/59c602cfd601
Make attachment pane more accessible. r=aleca

Status: ASSIGNED → RESOLVED
Closed: 11 months ago
Resolution: --- → FIXED
Target Milestone: --- → 94 Branch

This fix introduces some string changes so we can't uplift it to 91.

See Also: → 1732260

Doesn't a XUL splitter need to be placed between two XUL "boxes" to work?
https://hg.mozilla.org/comm-central/rev/59c602cfd601#l2.28
And wouldn't flexing the <html:details> work with CSS display: contents? Maybe some inspiration here.

The expensive height calculation https://hg.mozilla.org/comm-central/rev/59c602cfd601#l1.42 appears a bit complicated, it would be good if it could be avoided.

Please, avoid writing on a closed bug unless the patch caused a regression.
Feel free to open a new bug with the issue or enhancement request you'd like to highlight.

Just for my understanding: Wouldn't the staff developer in charge evaluate any comment and then file a follow-up bug himself in case an improvement/simplification can be made?

Is good practice to no write on a closed bug as the conversation might get lost if it doesn't fully belong to the context of the patch.
The bag is also marked with "See also: bug 1732260", which is a continuation of the work done on this bug to convert the whole attachment view to pure HTML, so the work is not done.

Unless this patch caused a breakage, an issue, or a regression, it's good practice to open a new bug with the depends flag pointing at this one, to state your enhancement propositions.
Doing so helps keep the bug history clean, and properly notifies all the developers that worked on this bug that a "follow up" was opened, and the conversation can be done in the new bug without polluting a closed one.

No one disputes what a new bug should be filed. The question is just who should file it. I still think the developer in charge knows best what to do, especially given the other work panned in that area.

See Also: → 1741368
See Also: → 1741361
Blocks: 1745009
You need to log in before you can comment on or make changes to this bug.