1853823 - Assertion failure: index == static_cast<int32_t>(charData.Length()) in RemoteAccessible::GetCachedCharRect with NVDA

Status: NEW

(Core :: Disability Access APIs, defect)

Description

[Nathan LaPré]

STR:

1. Open a Wikipedia article page, such as this one.
2. With NVDA running, hit-test the elements with ids "ca-view", "ca-edit", and "ca-history". These are the "Read, "Edit," and "View history" buttons.
3. Assertion!

This doesn't happen 100% of the time, and doesn't seem to happen with all Wikipedia pages. But it happens pretty consistently on the referenced page.

I set up a debug, optimizations-disabled build to get the values here. For me, the values are, consistently: index: 40, charData.Length(): 36. See the call stack below:

Assertion failure: index == static_cast<int32_t>(charData.Length()), at C:/mozilla-source/mozilla-unified/accessible/ipc/RemoteAccessible.cpp:1297
#01: mozilla::a11y::RemoteAccessible::GetCachedCharRect (C:\mozilla-source\mozilla-unified\accessible\ipc\RemoteAccessible.cpp:1297)
#02: mozilla::a11y::TextLeafPoint::CharBounds (C:\mozilla-source\mozilla-unified\accessible\base\TextLeafRange.cpp:1750)
#03: mozilla::a11y::TextLeafPoint::ContainsPoint (C:\mozilla-source\mozilla-unified\accessible\base\TextLeafRange.cpp:1764)
#04: mozilla::a11y::HyperTextAccessibleBase::OffsetAtPoint (C:\mozilla-source\mozilla-unified\accessible\basetypes\HyperTextAccessibleBase.cpp:323)
#05: mozilla::a11y::ia2AccessibleText::get_offsetAtPoint (C:\mozilla-source\mozilla-unified\accessible\windows\ia2\ia2AccessibleText.cpp:148)
#06: mozilla::a11y::ia2AccessibleHypertext::get_offsetAtPoint (C:\mozilla-source\mozilla-unified\accessible\windows\ia2\ia2AccessibleHypertext.h:41)
#07: NdrInterfacePointerMemorySize[C:\WINDOWS\System32\RPCRT4.dll +0x67e23]
#08: NdrInterfacePointerMemorySize[C:\WINDOWS\System32\RPCRT4.dll +0x66bac]
#09: NdrStubCall2[C:\WINDOWS\System32\RPCRT4.dll +0x41eea]
#10: CStdStubBuffer_Invoke[C:\WINDOWS\System32\combase.dll +0xc358d]
#11: CStdStubBuffer_Invoke[C:\WINDOWS\System32\RPCRT4.dll +0xaba5]
#12: WindowsGetStringRawBuffer[C:\WINDOWS\System32\combase.dll +0x9c0ad]
#13: WindowsGetStringRawBuffer[C:\WINDOWS\System32\combase.dll +0x9be38]
#14: Ordinal67[C:\WINDOWS\System32\combase.dll +0xc7c81]
#15: DllGetClassObject[C:\WINDOWS\System32\combase.dll +0x9ee67]
#16: CoWaitForMultipleHandles[C:\WINDOWS\System32\combase.dll +0x3cb79]
#17: DllGetClassObject[C:\WINDOWS\System32\combase.dll +0xa48e9]
#18: Ordinal87[C:\WINDOWS\System32\combase.dll +0x5d7c8]
#19: Ordinal87[C:\WINDOWS\System32\combase.dll +0x5e099]
#20: DispatchMessageW[C:\WINDOWS\System32\user32.dll +0x18241]
#21: DispatchMessageW[C:\WINDOWS\System32\user32.dll +0x17d01]
#22: nsAppShell::ProcessNextNativeEvent (C:\mozilla-source\mozilla-unified\widget\windows\nsAppShell.cpp:668)
#23: nsBaseAppShell::DoProcessNextNativeEvent (C:\mozilla-source\mozilla-unified\widget\nsBaseAppShell.cpp:131)
#24: nsBaseAppShell::OnProcessNextEvent (C:\mozilla-source\mozilla-unified\widget\nsBaseAppShell.cpp:267)
#25: nsThread::ProcessNextEvent (C:\mozilla-source\mozilla-unified\xpcom\threads\nsThread.cpp:1117)
#26: NS_ProcessNextEvent (C:\mozilla-source\mozilla-unified\xpcom\threads\nsThreadUtils.cpp:480)
#27: mozilla::ipc::MessagePump::Run (C:\mozilla-source\mozilla-unified\ipc\glue\MessagePump.cpp:82)
#28: MessageLoop::RunInternal (C:\mozilla-source\mozilla-unified\ipc\chromium\src\base\message_loop.cc:370)
#29: MessageLoop::RunHandler (C:\mozilla-source\mozilla-unified\ipc\chromium\src\base\message_loop.cc:364)
#30: MessageLoop::Run (C:\mozilla-source\mozilla-unified\ipc\chromium\src\base\message_loop.cc:346)
#31: nsBaseAppShell::Run (C:\mozilla-source\mozilla-unified\widget\nsBaseAppShell.cpp:150)
#32: nsAppShell::Run (C:\mozilla-source\mozilla-unified\widget\windows\nsAppShell.cpp:532)
#33: nsAppStartup::Run (C:\mozilla-source\mozilla-unified\toolkit\components\startup\nsAppStartup.cpp:295)
#34: XREMain::XRE_mainRun (C:\mozilla-source\mozilla-unified\toolkit\xre\nsAppRunner.cpp:5683)
#35: XREMain::XRE_main (C:\mozilla-source\mozilla-unified\toolkit\xre\nsAppRunner.cpp:5884)
#36: XRE_main (C:\mozilla-source\mozilla-unified\toolkit\xre\nsAppRunner.cpp:5940)
#37: mozilla::BootstrapImpl::XRE_main (C:\mozilla-source\mozilla-unified\toolkit\xre\Bootstrap.cpp:45)
#38: do_main (C:\mozilla-source\mozilla-unified\browser\app\nsBrowserApp.cpp:227)
#39: NS_internal_main (C:\mozilla-source\mozilla-unified\browser\app\nsBrowserApp.cpp:445)
#40: wmain (C:\mozilla-source\mozilla-unified\toolkit\xre\nsWindowsWMain.cpp:151)
#41: __scrt_common_main_seh (D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288)
#42: BaseThreadInitThunk[C:\WINDOWS\System32\KERNEL32.DLL +0x1257d]
#43: RtlUserThreadStart[C:\WINDOWS\SYSTEM32\ntdll.dll +0x5aa68]

Comment 1

[James Teh [:Jamie]]

How are you hit testing? Just moving the mouse over the text?
Do you get 40 and 36 regardless of which of those links you test?
This suggests we're hitting a text node which contains 9 character rects, but we think it should contain at least 10. What's confusing to me is that if we're hit testing those links, we should only be searching within the generic container which contains the text, and none of them are 10 characters. "View history" is the closest at 12 characters.

Comment 2

[Nathan LaPré]

How are you hit testing? Just moving the mouse over the text?

Yep, just moving the mouse over the text. I can also get a slightly different callstack by clicking-and-dragging the links, but not consistently, and it bottoms out at the same assert.

Do you get 40 and 36 regardless of which of those links you test?

Yup! That seemed strange to me considering they're different amounts of text.

I did try to get a reduced test case for this, but had no luck in the hour or so I spent on it. FWIW, I can't get the problem to reproduce on other Wikipedia pages, such as this one.

Comment 3

[James Teh [:Jamie]]

I guess FindBoundary must be walking out of the container it's supposed to remain within. The question of course is why...