If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Write window (ctrl+r) accessibility problems

NEW
Unassigned

Status

Thunderbird
Disability Access
--
major
6 years ago
2 years ago

People

(Reporter: surkov, Unassigned)

Tracking

(Blocks: 1 bug, {access})

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

6 years ago
After write window appears, accessible objects are never destroyed as well as frame tree. All accessible objects inside this window expose sensible and enabled states and expose not empty (x, y, width, height) rect. This is sort of incorrect.

Also, when window is closed then message accessible document (under xul:editor element) has readonly state, when window is open then the document gets editable state but there's no notification (we listen for obs_documentCreated observer notification).

Blake, could you please look and say what specific does Thunderbird do with "Write" window? How does it get open and closed? How does message document become editable?
I'm afraid I don't know the details, other than sometimes it gets re-used…

Bienvenu (cc-ed) might know more.

Comment 2

6 years ago
We cache the compose window because in the bad old days, the compose window was so complicated and expensive to instantiate that we only did it the first time and then used a cached window after that. This mostly had to do with the cost of xul, and iirc, xul overlays. It's quite possible that this caching is more or less irrelevant today.

I think if you set mail.compose.max_recycled_windows to 0, we won't cache/recycle compose windows. If performance of opening a second compose window after closing the first compose window is roughly the same as that of opening the first compose window, then ripping out the compose window caching code would be fine with me.
(Reporter)

Comment 3

6 years ago
(In reply to David :Bienvenu from comment #2)
> We cache the compose window because in the bad old days

How do you do caching? Can you point me to the code please?

> I think if you set mail.compose.max_recycled_windows to 0, we won't
> cache/recycle compose windows. If performance of opening a second compose
> window after closing the first compose window is roughly the same as that of
> opening the first compose window, then ripping out the compose window
> caching code would be fine with me.

this is good approach to proceed however I prefer if accessibility module handles correctly all crazy stuffs (in meaning of unusual) not depending how much they are crazy.
(Reporter)

Comment 4

6 years ago
friendly ping, this issue is serious one and few screen readers are affected.
Severity: normal → major
Alexander,

the caching seems to happen near here:
http://mxr.mozilla.org/comm-central/source/mailnews/compose/src/nsMsgComposeService.cpp#255

Later,
Blake.
(In reply to Blake Winton (:bwinton) (:☕️) from comment #5)
> Alexander,
> 
> the caching seems to happen near here:
> http://mxr.mozilla.org/comm-central/source/mailnews/compose/src/
> nsMsgComposeService.cpp#255

Hi surkov. Are you currently using workaround?
Flags: needinfo?(surkov.alexander)
(Reporter)

Comment 7

2 years ago
honestly I didn't look at the issue these years. Apparently the bug doesn't hit the users too much (if it still exists) since there's no complains in the bug, neither from users nor from AT developers.

Marco, are you aware of any existing problems with Write dialog?
Flags: needinfo?(surkov.alexander)

Comment 8

2 years ago
No I am not. But I am also not using Thunderbird as much these days any more, have moved all my mail to the web (Gmail).
You need to log in before you can comment on or make changes to this bug.