Crash report: https://crash-stats.mozilla.org/report/index/70029924-2e73-488e-96e6-cac9c0230420

Reason: EXC_BAD_ACCESS / KERN_INVALID_ADDRESS

Top 10 frames of crashing thread:

0  XUL  mozilla::a11y::Accessible::IsOuterDoc const  accessible/basetypes/Accessible.h:536
0  XUL  mozilla::a11y::TextLeafPoint::TextLeafPoint  accessible/base/TextLeafRange.cpp:575
1  XUL  mozilla::a11y::DocAccessibleChildBase::RecvSetTextSelection  accessible/ipc/DocAccessibleChildBase.cpp:238
2  XUL  mozilla::a11y::PDocAccessibleChild::OnMessageReceived  ipc/ipdl/PDocAccessibleChild.cpp
3  XUL  mozilla::dom::PContentChild::OnMessageReceived  ipc/ipdl/PContentChild.cpp:8767
4  XUL  mozilla::ipc::MessageChannel::DispatchAsyncMessage  ipc/glue/MessageChannel.cpp:1800
4  XUL  mozilla::ipc::MessageChannel::DispatchMessage  ipc/glue/MessageChannel.cpp:1725
5  XUL  mozilla::ipc::MessageChannel::RunMessage  ipc/glue/MessageChannel.cpp:1525
5  XUL  mozilla::ipc::MessageChannel::MessageTask::Run  ipc/glue/MessageChannel.cpp:1623
6  XUL  mozilla::RunnableTask::Run  xpcom/threads/TaskController.cpp:555

Not sure what happened, I was navigating a web page with VoiceOver. No specific steps, and nothing I hadn't done before. Needless to say, it is also not reproducible at will.

I guess the Accessible in question died while we were trying to set its text selection. Either DocAccessibleChildBase::RecvSetTextSelection or TextLeafPoint::TextLeafPoint shouldn't assume that the provided Accessible is non-null.

Set release status flags based on info from the regressing bug 1811092

:eeejay, since you are the author of the regressor, bug 1811092, could you take a look?

For more information, please visit auto_nag documentation.

The bug is linked to a topcrash signature, which matches the following criterion:

• Top 10 content process crashes on beta

For more information, please visit auto_nag documentation.

DocAccessibleChildBase::RecvSetTextSelection and RecvScrollTextLeafRangeIntoView constructs TextLeafPoints without null checking the retrieved Accessible.
This can be null if the Accessible was destroyed in the content process but the parent process didn't know about this yet when it sent the request.
TextLeafPoint currently crashes if constructed with a null Accessible.
These DocAccessibleChildBase methods do check the validity of the range, which will be invalid if the TextLeafPoints are invalid.
Therefore, just construct an invalid TextLeafPoint if a null Accessible is given.

Comment on attachment 9330295 [details]
Bug 1829167: Construct an invalid TextLeafPoint if null is supplied to the constructor.

Beta/Release Uplift Approval Request

• User impact if declined: Crash.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Adds a null check.
• String changes made/needed:
• Is Android affected?: No

https://hg.mozilla.org/mozilla-central/rev/cf1fd02da077

Comment on attachment 9330295 [details]
Bug 1829167: Construct an invalid TextLeafPoint if null is supplied to the constructor.

Approved for 113.0b9.

https://hg.mozilla.org/releases/mozilla-beta/rev/684ecdf765f5

Fix verified in Firefox Nightly 114.0a1 ( 20230427095144). I can no longer reproduce this crash with the scenario that was crashing frequently before this patch.