Crash report: https://crash-stats.mozilla.org/report/index/1a1f07b3-1190-42a3-a1a5-3b4f70221005

Reason: SIGSEGV / SEGV_MAPERR

Top 10 frames of crashing thread:

0 libxul.so mozilla::a11y::Accessible::FirstChild const accessible/basetypes/Accessible.h:173
0 libxul.so mozilla::a11y::Accessible::HasChildren const accessible/basetypes/Accessible.h:170
0 libxul.so mozilla::a11y::TextLeafPoint::TextLeafPoint accessible/base/TextLeafRange.cpp:471
1 libxul.so mozilla::a11y::TextLeafPoint::FindBoundary const accessible/base/TextLeafRange.cpp:916
2 libxul.so mozilla::a11y::HyperTextAccessibleBase::TextBounds accessible/basetypes/HyperTextAccessibleBase.cpp:210
3 libxul.so mozilla::a11y::RemoteAccessible::TextBounds accessible/ipc/other/RemoteAccessible.cpp:282
4 libxul.so getRangeExtentsCB accessible/atk/nsMaiInterfaceText.cpp:387
5 libatk-bridge-2.0.so.0 impl_GetRangeExtents atk-adaptor/adaptors/text-adaptor.c:675
6 libatk-bridge-2.0.so.0 handle_message droute/droute.c:601
7 libdbus-1.so.3 dbus_connection_dispatch /build/dbus-IAhSsk/dbus-1.12.20/dbus/dbus-connection.c:4576

I have managed to reproduce the issue while browsing on www.google.com and navigating between search results with with the Tab key and with accessibility.cache.enabled set to true and ORCA enabled.

I can not reproduce the issue with a new profile.

Jamie can this crash be something related to the "Cache the World" feature?

This does seem to be related to CTW, yes. Thanks.

:Jamie this looks suspiciously like the iframe crash you patched -- and it looks like the stack for this crash doesn't contain that fix.

The only other thing I can think of is that we maybe should check acc && acc->HasChildren() in GetChild() before trying to return FirstChild() or LastChild(). But apart from that, I'm not sure where to go with this. Interested in your thoughts.

I agree it's suspiciously close to that iframe fix. That said, it's a little different in that it fails before we even construct the previous character, rather than getting the wrong Accessible and then getting stuck in an infinite loop as a result.

If I'm reading this right, it looks like searchFrom.mAcc ends up null here. I say that because the only reason we should crash in HasChildren/FirstChild is if it's getting called on a null pointer. That said, I would have thought PrevLeaf/NextLeaf (called earlier in FindBoundary) would have crashed if passed a null acc, but maybe they don't.

That said, I also can't see how searchFrom.mAcc could be null, unless the origin TextLeafPoint had a null mAcc in the first place.

In the absence of any further ideas, I guess the best thing to do here is leave this open and see if it shows up again, hoping that bug 1793408 dealt with this after all.

No crashes since October. Looks like this was fixed by bug 1793408.