Open Bug 1871989 Opened 2 years ago Updated 1 year ago

Crash with JAWS in [@ mozilla::CycleCollectedJSContext::Context]

Categories

(Core :: Disability Access APIs, defect)

Product:
Core
Component:
Disability Access APIs
Platform:
Unspecified
Windows 11
Type:
defect

Tracking

()

People

(Reporter: wsmwk, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: crash, Whiteboard: [tbird crash])

Crash Data

This crash is new with 122.0b1. Perhaps just a bug in JAWS

Crash report: https://crash-stats.mozilla.org/report/index/34d40a11-a82d-4483-9fa9-eabdd0231224

Reason: EXCEPTION_ACCESS_VIOLATION_READ

Top 10 frames of crashing thread:

0  xul.dll  mozilla::CycleCollectedJSContext::Context const  xpcom/base/CycleCollectedJSContext.h:179
0  xul.dll  mozilla::dom::danger::GetJSContext  dom/script/ScriptSettings.cpp:256
1  xul.dll  mozilla::dom::CustomElementRegistry::CallGetCustomInterface  dom/base/CustomElementRegistry.cpp:1405
2  xul.dll  mozilla::dom::Element::GetCustomInterface  dom/base/Element.cpp:4303
2  xul.dll  mozilla::dom::Element::AsXULControl  dom/base/Element.cpp:4475
3  xul.dll  nsXULElement::GetXULFocusability  dom/xul/nsXULElement.cpp:389
4  xul.dll  nsIFrame::IsFocusable  layout/generic/nsIFrame.cpp:10708
5  xul.dll  mozilla::a11y::LocalAccessible::NativeInteractiveState const  accessible/generic/LocalAccessible.cpp:421
6  xul.dll  mozilla::a11y::LocalAccessible::NativeState const  accessible/generic/LocalAccessible.cpp:377
7  xul.dll  mozilla::a11y::LocalAccessible::State  accessible/generic/LocalAccessible.cpp:1588

Are there any steps to reproduce this? I could try to reproduce it and forward it to the developers.

Sadly no user comments, so no steps to reproduce.

Previously cited crashes are all Thunderbird 124 beta. I think two different users.

Severity: -- → S3
Version: unspecified → Thunderbird 115

I have saved and opened attachments in Thunderbird several times now, but Thunderbird has never crashed. Somehow I can't find a way to reproduce this.

Flags: needinfo?(ali-savas)

The following questions would be interesting:

  • Which JAWS version was used?
  • Was JAWS really used or does the user have Fusion as a screen reader? Fusion is the combination of JAWS with ZoomText.
  • How exactly did the user proceed to save the attachments?

I was able to reproduce the problem with Thunderbird 26.0 B1, but I don't have the problem with Daily. Should I reopen the bug or should we wait and see?

What is your crash ID for 126.0b1?

My crash ID is: bp-e3d014c6-4960-4b7d-905f-4fb810240429

I was also able to reproduce it with NVDA.

That says

MOZ_DIAGNOSTIC_ASSERT(IsAtomic<bool>::value || NS_IsMainThread()) (Non-atomic static pref 'accessibility.uia.enable' being accessed on background thread by getter)

Unfortunately, I can't do anything with this information. Apparently there is a problem with UIA, i.e. UI automation.

Steps to reproduce

  • Install and run NVDA or JAWS
  • Start Thunderbird and open an e-mail with attachments
  • Go to the menu bar “Message”, next click on “Attachments” and then go to the submenu of the respective attachment and click on “Save”.

Result

As soon as the dialog box opens, Thunderbird crashes and closes.

Bug 1881190 made accessibility.uia.enable a static pref.

Maybe it should be type: RelaxedAtomicBool?
https://searchfox.org/mozilla-central/rev/2e7374599f4020d0490ec8c5e877c179c9e153c9/modules/libpref/init/StaticPrefList.yaml#246-247

Flags: needinfo?(jteh)

Small update: I saw that the “fsATProxy” process was still active. I have removed it. After that I could no longer reproduce the crash with NVDA. I think this is due to JAWS and its components.

As already written, I could not reproduce it at home with Daily.

A client is never supposed to access Gecko UI from any thread other than the main thread. However, it looks like we bring up file picker dialogs in a background thread, and then JAWS (for some strange and unknown reason) tries to traverse into the (disabled) Gecko UI. Even if we make the UIA pref work on a background thread, we're going to hit all sorts of other problems if this happens.

All of that said, the crashes in comment 0 and comment 9 are very different. Should these be separate bugs?

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

we bring up file picker dialogs in a background thread, and then JAWS (for some strange and unknown reason) tries to traverse into the (disabled) Gecko UI.

Even if it traversed the tree, JAWS shouldn't be directly calling methods on Gecko objects from this thread. It should have used WM_GETOBJECT and ObjectFromLresult one way or another, which means they should be marshaled across threads by the COM marshaler. I can't be absolutely certain but this smells very much like a JAWS bug.

We could try adding some early return code like this to the top of MsaaAccessible::QueryInterface, which might stop the crashes.

Component: General → Disability Access APIs
Flags: needinfo?(jteh)
Product: Thunderbird → Core
Whiteboard: [tbird crash]
Version: Thunderbird 115 → unspecified

JAWS shouldn't be directly calling methods on Gecko objects from this thread.
I can't be absolutely certain but this smells very much like a JAWS bug.

Has a bug been filed? Or do you have a developer contact?

Flags: needinfo?(jteh)

I would have access to their bug tracking system, but only for beta testers. If you could tell me what exactly I should enter there, I could enter it if necessary.

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

Has a bug been filed?

There isn't a bug tracker to which I have access.

Or do you have a developer contact?

I do... but I don't love our chances of a quick fix. In addition, because of the cost of updates, many JAWS users tend to be running old versions, so we'd still be dealing with that problem.

I can throw together a patch based on comment 16, but I don't have the cycles to build and test with Thunderbird.

Flags: needinfo?(jteh)

But also, I still think this is the wrong bug given comment 14. There should probably be a separate bug unless we have reason to believe the crashes are related or that the old crash is gone.

Urgh. The crash in comment 0 has nothing to do with UIA, but it's still related to JAWS poking us on the wrong thread. Comment 16 won't help there because it isn't QueryInterface.

Or maybe it will if JAWS is calling QI first before it calls accState.

See Also: → 1896816

I filed bug 1896816 for the crash in comment 9. I'll try hacking around that one first and then we'll see if the one in comment 0 goes away too.

Blocks: jaws

Thanks Jamie.

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