Open Bug 1972175 Opened 5 months ago Updated 4 months ago

When focusing the chat input in Thunderbird 128.11.1 (for Matrix or IRC), NVDA freezes with watchdog errors until a message is sent.

Categories

(Chat Core :: General, defect)

Thunderbird 128
defect

Tracking

(Not tracked)

UNCONFIRMED

People

(Reporter: david, Unassigned)

References

Details

(Keywords: access)

Steps to reproduce:

Tried to access certain IRC channels or matrix rooms with NVDA 2024.4.2.
This does not happen reliably on all channels or rooms. I suspect it may be linked to number of users but it's only a guess.

Actual results:

NVDA freezes.
When focusing the chat input in Thunderbird 128.11.1 (for Matrix or IRC), NVDA freezes with watchdog errors until a message is sent.

  • Before any message is posted, the chat area (chrome://chat/content/conv.html) exposes a ROLE_SYSTEM_DOCUMENT object that is FOCUSABLE, READONLY, but has no caret, no accessible text descendants, and malformed IA2 attributes (text-align:start).
  • NVDA attempts to fetch text or caret info and fails:
  • RuntimeError: No caret
  • LookupError: Object has no text descendants
  • After sending any message, the IA2 tree is repaired, and NVDA works again.
  • This issue does not affect all chats, but occurs across both Matrix and IRC protocols.
  • It is layout-dependent: worsens when Thunderbird is maximised.
  • Restarting or running in safe mode does not resolve it.

This breaks accessibility and should be addressed in Thunderbird’s chat rendering layer.

Tested With:

  • Thunderbird 128.11.1
  • NVDA 2024.4.1
  • Windows 10

Expected results:

Expected results:

NVDA reads the chat or room correctly, and allows to navigate with tab or shift-tab, or arrows.

Keywords: access

The bug is still present in thunderbird 139.0.2 with NVDA 2025.1.2.

Does this happen if there are messages from others in the channel since you joined it and it is only fixed if you send a message?

You're saying you've encountered it with both Matrix and IRC?

Have you tried different chat themes (Settings → Chat → Styling → Theme) - by default we use "Thunderbird". To reliably get the new theme, I'd recommend restarting Thunderbird (we only apply the theme to channels joined after the preference is changed). I'm asking because the different themes will generate different markup for messages in the channel.

Does this happen if there are messages from others in the channel since you joined it and it is only fixed if you send a message?

Yes, until I send a message the other messages seem to be stuck and not read; NVDA doesn't show them.

You're saying you've encountered it with both Matrix and IRC?

Yes. It doesn't happen with all channels and I can't easily tell what causes it.

Have you tried different chat themes (Settings → Chat → Styling → Theme) - by default we use "Thunderbird". To reliably get the new theme, I'd recommend restarting Thunderbird (we only apply the theme to channels joined after the preference is changed). I'm asking because the different themes will generate different markup for messages in the channel.

I tried the Simple theme and it doesn't seem to happen with it; it was happening with the Thunderbird theme. I could try different themes to pinpoint which trigger it if that's useful.

Depends on: 1975117
Severity: -- → S3

Thank you.

(In reply to David from comment #3)

Yes, until I send a message the other messages seem to be stuck and not read; NVDA doesn't show them.

Do you have other screen readers available? We're wondering if this is specific to NVDA, or if the issue lies within what Thunderbird reports to screenreaders.

I tried the Simple theme and it doesn't seem to happen with it; it was happening with the Thunderbird theme. I could try different themes to pinpoint which trigger it if that's useful.

Okay, I assume that means - for now - the issue seems to have a work around. As we're wanting to rebuild how the chat conversation browser works (including an overhaul to message theming, see also bug 1733582) we're unlikely to spend much time trying to fix this. Especially considering that from the description it's not something we're inherently doing wrong, but instead something either in how Thunderbird reports the state to NVDA or how NVDA handles what it gets from Thunderbird. However, that's code we don't control and inherit from Firefox, so it's possible this is surfacing an issue in Firefox code.

However, I'd expect that it's possible to avoid this bugged condition all together by changing the markup we generate, so I'm leaving this open.

Unfortunately not. I can't try with another screen reader. Hopefully someone can take a look at this and work it out.

You need to log in before you can comment on or make changes to this bug.