677485 - Write window (ctrl+r) accessibility problems

Status: RESOLVED INVALID

(Thunderbird :: Disability Access, defect)

Description

[alexander :surkov (:asurkov)]

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?

Comment 1

[Blake Winton (:bwinton) (:☕️)]

I'm afraid I don't know the details, other than sometimes it gets re-used…

Bienvenu (cc-ed) might know more.

Comment 2

[David :Bienvenu]

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.

Comment 3

[alexander :surkov (:asurkov)]

(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.

Comment 4

[alexander :surkov (:asurkov)]

friendly ping, this issue is serious one and few screen readers are affected.

Comment 5

[Blake Winton (:bwinton) (:☕️)]

Alexander,

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

Later,
Blake.

Comment 6

[Wayne Mery (:wsmwk)]

(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?

Comment 7

[alexander :surkov (:asurkov)]

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?

Comment 8

[Marco Zehe (:MarcoZ)]

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).

Comment 9

[Wayne Mery (:wsmwk)]

We killed recycled compose window in bug 777732 so I suspect this is issue dead

Comment 10

[Marco Zehe (:MarcoZ)]

Agreed, this should no longer be an issue, then.