1717020 - Crash in [@ InvalidArrayIndex_CRASH | mozilla::EventStateManager::LookForAccessKeyAndExecute]

Status: RESOLVED FIXED

(Core :: DOM: Events, defect)

Description

[Sean Feng [:sefeng211]]

Maybe Fission related. (DOMFissionEnabled=1)

Crash report: https://crash-stats.mozilla.org/report/index/504a836e-8f02-4d86-b042-a72b80210613

MOZ_CRASH Reason: ElementAt(aIndex = 11, aLength = 11)

Top 10 frames of crashing thread:

0 libxul.so InvalidArrayIndex_CRASH xpcom/ds/nsTArray.cpp:28
1 libxul.so mozilla::EventStateManager::LookForAccessKeyAndExecute dom/events/EventStateManager.cpp:1097
2 libxul.so mozilla::EventStateManager::WalkESMTreeToHandleAccessKey dom/events/EventStateManager.cpp:1204
3 libxul.so mozilla::EventStateManager::PreHandleEvent dom/events/EventStateManager.cpp:783
4 libxul.so mozilla::PresShell::EventHandler::DispatchEvent layout/base/PresShell.cpp:8212
5 libxul.so mozilla::PresShell::EventHandler::HandleEventWithCurrentEventInfo layout/base/PresShell.cpp:8181
6 libxul.so mozilla::PresShell::EventHandler::HandleEventAtFocusedContent layout/base/PresShell.cpp:7910
7 libxul.so mozilla::PresShell::EventHandler::HandleEvent layout/base/PresShell.cpp:6929
8 libxul.so mozilla::PresShell::HandleEvent layout/base/PresShell.cpp:6829
9 libxul.so nsViewManager::DispatchEvent view/nsViewManager.cpp:704

Comment 1

[Chris Peterson [:cpeterson]]

Is this a regression? All the crash reports are from Nightly 90.a1 and 91.0a1 on Linux, but there are no reports yet from Beta 90.0b yet. Is this code for a Nightly-only feature? The earliest build ID in a crash report is 20210428100720.

(Adding [not-a-fission-bug] whiteboard tag because this doesn't look like a Fission bug, even though some of the recent crash reports (including comment 0's) have "DOMFissionEnabled=1".)

Comment 2

[Sean Feng [:sefeng211]]

Attachment: Bug 1717020 - Add an assertion to EventStateManager::LookForAccessKeyAndExecute to diagnose the invalid index crash r=edgar

We've used a remainder already, so I don't see a reason for the crash.
The only possibility that I see is the length of the array gets changed
in the loop, so I added this assertion to see if that was the case.

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/81a42afe6451
Add an assertion to EventStateManager::LookForAccessKeyAndExecute to diagnose the invalid index crash r=edgar

Comment 4

[Alexandru Michis [:malexandru]]

https://hg.mozilla.org/mozilla-central/rev/81a42afe6451

Comment 5

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

The patch landed in nightly and beta is affected.
:sefeng, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.

Comment 6

[Sean Feng [:sefeng211]]

No need to uplift this patch

Comment 7

[pystub]

New crash report: https://crash-stats.mozilla.org/report/index/d8e36cda-d0ab-451a-9c10-af12d0210726

Happens after this handler returns:

this.body.addEventListener('click', (function (event) {
	if (!(event.target instanceof HTMLAnchorElement)) {
		return
	}
	var	url = new URL(event.target.href)
	,	current = location.origin + location.pathname
	,	clicked = url.origin + url.pathname
	if (current !== clicked) {
		return
	}
	this.virtualNavigate(url.hash.replace(/^#/, ''))
	event.preventDefault()
	event.stopImmediatePropagation()
}).bind(this))

for reference

that.virtualNavigate = function (hash) {
	var	step = null
	,	path = hash.split ('/')
	,	o = this.fs
	while (step = this.fsCleanup.pop())
		step.call(this)
	while (path.length > 0) {
		step = path.shift()
		if (step in o) {
			o = o[step]
		} else {
			return
		}
		if (o['/<'] instanceof Function)
			this.fsCleanup.push(o['/<'])
		if (o['/>'] instanceof Function)
			if (o['/>'].call(this, path))
				return
	}
	if (o['/v'] instanceof Function)
		o['/v'].call(this)
}

Comment 8

[pystub]

I should add that this happens only if the link was "clicked" using Alt+Shift+1 (see accesskey attribute) while link's parent is display:none at the same time.