1972457 - TB freezes ("Not Responding") while typing email reply; accessibility.force_disabled value 1 fixes it.

Status: RESOLVED DUPLICATE of bug 2006816

(Core :: Disability Access APIs, defect)

Description

[Graham Moore]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/137.0.0.0 Safari/537.36

Steps to reproduce:

I replied to an email, nothing unusual and no attachments. Typing froze about 1/3 of the way through the 2nd line - TB completely froze with a (Not Responding) notation in the header.

Actual results:

TB completely froze. I closed the email and shut down TB. u/siffered on Reddit suggested clearing the cache and disabling the Accessibility Service. This solved my problem. u/wsmwk suggested changing accessibility.force_disabled back to '0' and the problem didn't return until now, 13 days later.

Expected results:

The freezing didn't happen again, at least so far today.

Comment 1

[Anje]

Also just reported by another user in Thundebird Support forum:
https://support.mozilla.org/en-US/questions/1514833

I advised them to alter preference: accessibility.force_disabled to 1
This appeared to work, so asked if they would test resetting it back to default = 0
After 4 days the problem returned and so they have to use setting 1

Also reported here:
https://www.reddit.com/r/Thunderbird/comments/1guswmy/intermittently_unresponsive_while_composing_html/

Comment 2

[Wayne Mery (:wsmwk)]

Thanks Anje!
And thanks Graham!

Comment 3

[Wayne Mery (:wsmwk)]

Full workaround instructions:

1. get to config editor https://support.mozilla.org/en-US/kb/config-editor
2. in search type: force
3. look for: accessibility.force_disabled
4. default has zero 0 setting
5. click on the pencil icon
6. Remove the zero and type : 1
7. click on the tick icon to save.
8. restart Thunderbird

Please report on results. If it helps, then you are seeing Bug 1972457 - TB freezes ("Not Responding") while typing email reply; accessibility.force_disabled value 1 fixes it.

Note it will disable accessibility features such as screen readers.

Comment 4

[Dan]

Hi all,

Screen reader user here :) so I can't force disable accessibility in Thunderbird to fix this. I'm experiencing many crashes per day while typing my messages.

NVDA logs are here too in case helpful:
https://github.com/nvaccess/nvda/issues/18315

Reproduceable in Thunderbird 139, 140, 140.0.1 at least -- not sure about older versions.

Thank you

Comment 5

[Magnus Melin [:mkmelin] (away until Aug 10)]

Dan, if you really mean crashes (not hangs), please provide the crash ids. See https://support.mozilla.org/en-US/kb/thunderbird-crashes

Comment 6

[Dan]

Hi Magnus -- thank you! It's a hang; the crash reporter doesn't show up, but Windows says it isn't responding.

Should I follow these instructions to create a stack trace?
https://firefox-source-docs.mozilla.org/contributing/debugging/stacktrace_windbg.html#how-to-get-a-stacktrace-with-windbg

Comment 7

[Wayne Mery (:wsmwk)]

This instructions are good - just substitute "thunderbird" where you see "firefox".

Comment 8

[Dan]

Hmm -- I'm having trouble finding the 32-bit debugging tools. I tried the 64-bit version of windbg but it's failing to download the thunderbird symbols.

Will keep churning... thanks!

Comment 9

[Dan]

Is anyone else having trouble getting the Thunderbird symbols to load?

0:000> .sympath SRV*c:\symbols*http://symbols.mozilla.org/thunderbird;SRV*c:\symbols*http://msdl.microsoft.com/download/symbols
Symbol search path is: SRV*c:\symbols*http://symbols.mozilla.org/thunderbird;SRV*c:\symbols*http://msdl.microsoft.com/download/symbols
Expanded Symbol search path is: srv*c:\symbols*http://symbols.mozilla.org/thunderbird;srv*c:\symbols*http://msdl.microsoft.com/download/symbols

************* Path validation summary **************
Response                         Time (ms)     Location
Deferred                                       SRV*c:\symbols*http://symbols.mozilla.org/thunderbird
Deferred                                       SRV*c:\symbols*http://msdl.microsoft.com/download/symbols
0:000> .symfix+ c:\symbols
0:000> .reload /f
Reloading current modules
......................

************* Symbol Loading Error Summary **************
Module name            Error
thunderbird            The system cannot find the file specified
mozglue                The system cannot find the file specified

You can troubleshoot most symbol related issues by turning on symbol loading diagnostics (!sym noisy) and repeating the command that caused symbols to be loaded.
You should also verify that your symbol search path (.sympath) is correct.

Comment 10

[Wayne Mery (:wsmwk)]

Thanks for including all that detail. I know it can be challenging.

It's been a couple years since I looked at this so I'm rusty. But the symbol server should be giving you something. I'm checking on it.

Comment 11

[Wayne Mery (:wsmwk)]

Might be because of bug 1975034

Comment 12

[Dan]

Is this possible, but a couple days ago I switched my composition preferences to compose in text, not HTML, and this freeze hasn't happened yet.

Comment 13

[Wayne Mery (:wsmwk)]

Graham, do the symbols load now?

Comment 14

[Graham Moore]

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

Graham, do the symbols load now?

Wayne, I've never had a problem with the various symbols loading. It was the freezing when trying to type a response to an email that was my issue.

Comment 15

[Anje]

Seeing reports in support forum
https://support.mozilla.org/en-US/questions/1524944

Comment 16

[Wayne Mery (:wsmwk)]

(In reply to Anje from comment #15)

Seeing reports in support forum
https://support.mozilla.org/en-US/questions/1524944

Do you have any more reports?

Comment 17

[Ed]

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

(In reply to Anje from comment #15)

Seeing reports in support forum
https://support.mozilla.org/en-US/questions/1524944

Do you have any more reports?

https://support.mozilla.org/en-US/questions/1530434

Comment 18

[Wayne Mery (:wsmwk)]

Can someone who reproduces this please find the regression range using https://mozilla.github.io/mozregression/documentation/usage.html ?

Comment 19

[Anje]

I'm still watching out, but not seen any more.

Comment 20

[Graham Moore]

It's been OK for me as well.

Comment 21

[Hasbro]

I have been struggling with Tbird hanging on message composition for 2 weeks now. It was an immediate onset thing 2 weeks ago. Perhaps tied to an update. I am running 140.2.1 now. Symptoms continued through this morning when I found this conversation. Symptoms were that on every new or reply compose message action, after maybe 2.5 lines of typed text, the app would hang, and only way out was to force exit. I never let it send the report to Microsoft, just hit cancel on that. When I reopened the app, the draft message was in Drafts, I'd open it, and try to continue. Often, it would just hang again after a few keystrokes.

A few days ago I found some advice about going into the Config thing and finding something (can't remember the name) that sometimes defaults to 300000 but it should have another zero, set to 3000000. I modified that setting. No effect.

This morning I have tried what is described above -- visit Config and then change accessibility.force, change default 0 to 1, etc., and for a few hours now, it seems to be fixed.

Oh yeah, I also previously found advice about going into settings removing the ability to interface with Windows on something (can't remember that either) and also changing the setting on hardware acceleration, but neither of those did the trick either.

I know this is not technically correct and precise, but I just want to post to let you know that this thread seems to be working for me and maybe if that other experience I am trying to describe helps anyone figure this out it will be worth it for me to post this. Many thanks to all of you who understand this stuff and post it for the rest of us. So valuable.

Hasbro

Comment 22

[Ed]

Also: https://support.mozilla.org/en-US/questions/1540793

Comment 23

[Wayne Mery (:wsmwk)]

Dan, do the symbols load now?

Comment 24

[Wayne Mery (:wsmwk)]

Jamie, any suggestions?

Comment 25

[James Teh [:Jamie]]

This would suggest that there is an accessibility client on the system which is misbehaving pretty badly. Otherwise, Gecko accessibility wouldn't be instantiated at all.

I haven't used Thunderbird in years, so I'm not sure how to best debug something like this in Thunderbird. If this were Firefox, I would be first asking for the information in the Accessibility section of about:support (with accessibility.force_disabled reset to its default). I assume you can get about:support in TB, but I don't know how. Second, it'd be useful to have a minidump or a stack trace when the hang occurs, but that can be tricky to get and it seems Dan ran into trouble getting that in comment 9.

Comment 27

[Wayne Mery (:wsmwk)]

Attachment: Screenshot 2025-11-05 at 10.00.35 AM.png

Hasbro, Ralph, Dan,

Per comment 25, please reset accessibility.force_disabled to default, post what you see in accessibility from Help > Troubleshooting Information (example attached).

Comment 28

[Wayne Mery (:wsmwk)]

I have also requested information from users in most of the SUMO reports.

Comment 29

[mgoldey]

Per Wayne's request, I have restored accessibility.force_disabled to zero and checked Help > Troubleshooting > Accessibility. This is what I find:

Activated true
Prevent Accessibility 0
Accessible Handler Used
Accessibility Instantiator UIAUTOMATION|C:\Windows\System32\EoAExperiences.exe

EoAExperiences.exe involves Windows' mouse implementation, and I have definitely adjusted my mouse cursor to be brightly colored and to make a bullseye when I press the SHIFT(?)+CRTL(?) key or whatever combination Windows likes to use (I am remoted in to that machine and examining the mouse settings brings up the local machine, so I can't tell exactly what changes I had made to the machine where TB hangs).

I can confirm that with accessibility.force_discabled set to zero, TB hangs when composing an e-mail. First try, 30 words in. As before, it happened almost immediately after I typed an apostrophe.

I hope that helps. Please LMK if more would be helpful

Comment 30

[Ed]

Attachment: Screenshot of about:support info from https://support.mozilla.org/en-US/questions/1550999

Comment 31

[James Teh [:Jamie]]

Perhaps we could we use the utility to intentionally crash Firefox? I'm hoping that would cause the crash reporter to come up, which would let a user submit a crash report and thus let us see the stack. For anyone comfortable with basic command line usage, the flow would go something like this:

1. Download the crashfirefox64.exe utility and save it somewhere easy to get to from the command line.
2. Reproduce the freeze in Thunderbird.
3. In a command prompt, run:
   crashfirefox64.exe thunderbird.exe
4. The Thunderbird crash reporter should appear. Submit a crash report.
5. Give us the id of the latest crash listed in Thunderbird.
   • How do you get to submitted crash reports in Thunderbird? In Firefox, you go to about:crashes, but I'm not sure how to do this in Thunderbird.

Comment 32

[Anje]

(In reply to James Teh [:Jamie] from comment #31)

Perhaps we could we use the utility to intentionally crash Firefox? I'm hoping that would cause the crash reporter to come up, which would let a user submit a crash report and thus let us see the stack. For anyone comfortable with basic command line usage, the flow would go something like this:

1. Download the crashfirefox64.exe utility and save it somewhere easy to get to from the command line.
2. Reproduce the freeze in Thunderbird.
3. In a command prompt, run:
   crashfirefox64.exe thunderbird.exe
4. The Thunderbird crash reporter should appear. Submit a crash report.
5. Give us the id of the latest crash listed in Thunderbird.
   • How do you get to submitted crash reports in Thunderbird? In Firefox, you go to about:crashes, but I'm not sure how to do this in Thunderbird.

re: Crash Reports
Settings > Privacy & Security
scroll down to 'Thunderbird Data Collection and Use'
Select 'Allow Thunderbird to send backlogged crash reports on your behalf'

Help > Troubleshooting Information
Scroll down to 'Crash reports for the last 3 days'
It will list ID number
Or click on 'All crash reports' to see list if ID numbers.

Comment 33

[James Teh [:Jamie]]

I came across a screen reader user who is able to reproduce this often enough and has sufficient technical expertise to get us crash reports using crashfirefox.

bp-ebce0ea0-8239-471f-b114-a883f0251213

Because the user is using NVDA, UIA gets disabled. But even with UIA force enabled, we get the same hang, just triggered from a different place:

bp-4276c17f-38be-4516-849b-631aa0251213
bp-2cb8459c-f853-43a1-8c34-cb2820251214

They all hang in HyperTextAccessibleBase::CaretLineNumber calling (probably repeatedly) TextLeafPoint::FindPrevLineStartSameLocalAcc. I'm not sure what triggers it yet.

Comment 34

[James Teh [:Jamie]]

Unfortunately, the crash dumps don't include any of the memory that would allow me to determine anything about the Accessible objects that might explain what triggers this. So all we have for now is "typing in the message composer". :(

This loop is likely where we're running into trouble:

for (TextLeafPoint line = point; line && firstPointInThis < line; line = line.FindBoundary(nsIAccessibleText::BOUNDARY_LINE_START, eDirPrevious)) {

That would suggest that FindLineBoundary keeps returning the same point (or maybe a point after the requested point) when it shouldn't. It's unclear whether FindLineBoundary or FindPrevLineStartSameLocalAcc is the culprit, but given that we don't have any reports of this in Firefox, my guess is that it doesn't affect RemoteAccessible, so it's probably FindPrevLineStartSameLocalAcc.

Comment 35

[James Teh [:Jamie]]

I've discovered a couple of bugs in CaretLineNumber, but I'm not specifically sure whether any (or some) of them are responsible for this problem:

1. CaretLineNumber calls TextLeafPoint::GetCaret. For LocalAccessible, GetCaret calls HyperTextAccessible::CaretOffset, then HyperTextAccessibleBase::ToTextLeafPoint. However, that will return the wrong point if the caret is more than a single Accessible deep (i.e. grandchild or deeper) beneath the origin and not immediately at the start of all the descendants. The reason is that ToTextLeafPoint will traverse descendants using offset 0. We need to use SelectionManager::AccessibleWithCaret, and it that fails, use HyperTextAccessible::CaretOffset and keep traversing using CaretOffset on each descendant until we get a leaf. This bug causes us to report the same line number on every line of a descendant container.
2. CaretLineNumber gets the caret, gets the start of the origin container and walks back by line until it hits the start of the origin container, increasing the line count as it goes. This means that if you're somewhere after the first character on the line, the line count is off by 1, since the first line you hit is actually the start of the line under the caret. This could be fixed by including the origin when querying the first line. Alternatively, it's probably easier to walk forward instead of backward, in which case you don't need to treat the first differently.

Walking forward is also a more tested code path than walking backward, since we use that to build the RemoteAccessible cache. Obviously, we should fix bugs in both, but if we're going to change it for other reasons anyway, that might be more reliable.

Comment 36

[James Teh [:Jamie]]

Another possibility is that we're in the middle of an interruptible reflow (PresShell::IsReflowInterrupted) when the client call arrives, so the frame tree is not in a usable state. I'm very much hoping that's not the case, but it needs to be considered.

Comment 37

[James Teh [:Jamie]]

Since it's not quite clear what exactly is going on here, I suggest we get the correctness issues in comment 35 sorted out. I filed bug 2006816 for that. Once that's landed, we can see if this fixes the problem for Thunderbird Nightly users. If not, we go back to the drawing board.

Do Thunderbird nightly builds use the latest mozilla-central?

Comment 38

[Magnus Melin [:mkmelin] (away until Aug 10)]

Yes, they do

Comment 39

[James Teh [:Jamie]]

(In reply to James Teh [:Jamie] from comment #37)

Since it's not quite clear what exactly is going on here, I suggest we get the correctness issues in comment 35 sorted out.

Curiously, the patches for these actually make the problem worse. On one hand, that's good: I can reproduce it even in Firefox, so I have more of a chance of tracking it down. On the other hand, I still don't know what's causing it yet.

Comment 40

[James Teh [:Jamie]]

Ah, no, the patches introduced a slightly different version of the same problem. I've fixed that now.

Comment 41

[James Teh [:Jamie]]

The user I mentioned in comment 33 tested Thunderbird Daily and confirmed that bug 2006816 appears to fix this. If the problem persists in Daily/Thunderbird 148, please follow the instructions in comment 31 and comment 32 and provide crash ids. Thanks.