1840343 - Crash in [@ mozilla::a11y::RemoteAccessibleBase<T>::DoFuzzyHittesting]

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[Gabriele Svelto [:gsvelto]]

Crash report: https://crash-stats.mozilla.org/report/index/45ce1fc9-2c33-4b55-a9ba-96a030230624

Reason: EXCEPTION_ACCESS_VIOLATION_READ

Top 10 frames of crashing thread:

0  xul.dll  mozilla::a11y::RemoteAccessibleBase<mozilla::a11y::RemoteAccessible>::DoFuzzyHittesting  accessible/ipc/RemoteAccessibleBase.cpp:446
1  xul.dll  mozilla::a11y::RemoteAccessibleBase<mozilla::a11y::RemoteAccessible>::ChildAtPoint  accessible/ipc/RemoteAccessibleBase.cpp:562
2  xul.dll  mozilla::a11y::OuterDocAccessible::ChildAtPoint  accessible/generic/OuterDocAccessible.cpp:214
3  xul.dll  mozilla::a11y::MsaaAccessible::accHitTest  accessible/windows/msaa/MsaaAccessible.cpp:1281
4  rpcrt4.dll  Invoke  
5  rpcrt4.dll  NdrStubCall2  
6  ole32.dll  CStdStubBuffer_Invoke  d:\w7rtm\com\rpc\ndrole\stub.cxx:1505
7  oleaut32.dll  virtual long __stdcall CUnivStubWrapper::Invoke  
8  ole32.dll  SyncStubInvoke  d:\w7rtm\com\ole32\com\dcomrem\channelb.cxx:1187
9  ole32.dll  StubInvoke  

This appears to be a new crash, possibly a regression since it's only happening on nightly. From a very quick glance it seems like child might be NULL here.

Comment 1

[James Teh [:Jamie]]

I agree it does look like child might be null there, but I don't see how and I really hope that's not true. RemoteAccessible::RemoteChildAt shouldn't be able to return null when called with an index less than RemoteAccessible::ChildCount.

Comment 2

[James Teh [:Jamie]]

Oh durp. We set maybeTextLeaf here, but we deliberately don't break out of the loop. However, the loop still assumes maybeTextLeaf is unchanged and tries to call RemoteChildAt on it, but we're now dealing with a descendant! I suspected something wasn't quite right with this loop when I reviewed it, but I couldn't quite figure out what it was despite reading it many times and ended up putting it down to me being thick. :)

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

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

:morgan, since you are the author of the regressor, bug 1837024, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 4

[Morgan Reschenberg [:morgan]]

Attachment: Bug 1840343: Track containers and text leaves separately when fuzzy hittesting r?Jamie

Comment 5

[Dianna Smith [:diannaS]]

Just as a reminder, tomorrow is soft freeze for 116 in case we wanted to land this soon :)

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/4570141f12e9
Track containers and text leaves separately when fuzzy hittesting r=Jamie

Comment 7

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/4570141f12e9

Comment 9

[BugBot [:suhaib / :marco/ :calixte]]

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

Comment 10

[James Teh [:Jamie]]

Comment on attachment 9341392 [details]
Bug 1840343: Track containers and text leaves separately when fuzzy hittesting r?Jamie

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: Needed to fix various accessibility regressions introduced by the Cache the World project which shipped in 115.
• User impact if declined: Potential crash introduced by bug 1837024.
• Fix Landed on Version: 116
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Isolated to a specific case of accessibility testing. Covered by automated test. Baked on release since 116 without problems.

Comment 11

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr115/rev/a00dcad72e2a

Comment 12

[Donal Meehan [:dmeehan]]

Comment on attachment 9341392 [details]
Bug 1840343: Track containers and text leaves separately when fuzzy hittesting r?Jamie

Approved for 115.4esr.