Closed Bug 1723010 Opened 4 years ago Closed 4 years ago

Crash in [@ mozilla::EventStateManager::LookForAccessKeyAndExecute]

Categories

(Core :: DOM: Core & HTML, defect, P2)

Product:
Core
Component:
DOM: Core & HTML
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
93 Branch
Tracking Flags:
Tracking Status
firefox-esr78 --- unaffected
firefox-esr91 --- unaffected
firefox91 --- unaffected
firefox92 --- wontfix
firefox93 --- fixed

People

(Reporter: u608768, Assigned: edgar)

References

Details

(Keywords: crash)

Crash Data

Attachments

(3 files)

minimal-accesskey-to-crash.html
601 bytes, text/html
Details
Bug 1723010 - Part 2: Stop iterating to find next element for an accesskey once the accesskey has been processed;
48 bytes, text/x-phabricator-request
Details | Review
Bug 1723010 - Part 1: Add more accesskey tests;
48 bytes, text/x-phabricator-request
Details | Review

Maybe Fission related. (DOMFissionEnabled=1)

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

MOZ_CRASH Reason: MOZ_DIAGNOSTIC_ASSERT(length == mAccessKeys.Count())

Top 10 frames of crashing thread:

0 libxul.so mozilla::EventStateManager::LookForAccessKeyAndExecute dom/events/EventStateManager.cpp:1140
1 libxul.so mozilla::EventStateManager::WalkESMTreeToHandleAccessKey dom/events/EventStateManager.cpp:1248
2 libxul.so mozilla::EventStateManager::PreHandleEvent dom/events/EventStateManager.cpp:826
3 libxul.so mozilla::PresShell::EventHandler::DispatchEvent layout/base/PresShell.cpp:8218
4 libxul.so mozilla::PresShell::EventHandler::HandleEventWithCurrentEventInfo layout/base/PresShell.cpp:8187
5 libxul.so mozilla::PresShell::EventHandler::HandleEventAtFocusedContent layout/base/PresShell.cpp:7916
6 libxul.so mozilla::PresShell::EventHandler::HandleEvent layout/base/PresShell.cpp:6935
7 libxul.so mozilla::PresShell::HandleEvent layout/base/PresShell.cpp:6853
8 libxul.so nsViewManager::DispatchEvent view/nsViewManager.cpp:704
9 libxul.so nsView::HandleEvent view/nsView.cpp:1136

This was added in bug 1717020. pystub can reproduce, see bug 1717020 comment #7.

Severity: -- → S2
Flags: needinfo?(sefeng)

Looks like element->PerformAccesskey can possibly run the event handlers, thus an access key can be removed from the array? Edgar would know how to fix this, maybe we need a data structure to know which access keys have been processed already?

Flags: needinfo?(sefeng) → needinfo?(echen)

Does this need a minimum repro page or is there enough details in the crash?

If yes, what would the best way to share it?

Yeah, it'd be great to have a minimum reproducible example. One could just write an HTML test case and attach it to the bug?

Aside from <head> and text node adding, I couldn't remove anything else.

(In reply to pystub from comment #4)

Created attachment 9234585 [details]
minimal-accesskey-to-crash.html

Thanks for the test case!

(In reply to Sean Feng [:sefeng] from comment #1)

Looks like element->PerformAccesskey can possibly run the event handlers, thus an access key can be removed from the array? Edgar would know how to fix this, maybe we need a data structure to know which access keys have been processed already?

Thanks for adding MOZ_DIAGNOSTIC_ASSERT in bug 1717020.

Assignee: nobody → echen
Component: DOM: Events → DOM: Core & HTML
Flags: needinfo?(echen)
Priority: -- → P2
Attachment #9235787 - Attachment description: Bug 1723010 - Stop iterating to find next element for an accesskey once the accesskey has been processed; → Bug 1723010 - Part 2: Stop iterating to find next element for an accesskey once the accesskey has been processed;
Pushed by echen@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/94c9836864cf Part 1: Add more accesskey tests; r=masayuki https://hg.mozilla.org/integration/autoland/rev/62facfd599d0 Part 2: Stop iterating to find next element for an accesskey once the accesskey has been processed; r=masayuki

(In reply to Atila Butkovits from comment #11)

Backed out for causing mochitest failures on test_bug226361.xhtml.

Hmm, strange, I could not reproduce this locally, but my local codebase is a bit old. Let me pull the latest code and try again.

Okay, it looks like the newly added test and somehow affects the test_bug226361.xhtml.

Flags: needinfo?(echen)
Pushed by echen@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/335db9369114 Part 1: Add more accesskey tests; r=masayuki https://hg.mozilla.org/integration/autoland/rev/bc650f27bb1e Part 2: Stop iterating to find next element for an accesskey once the accesskey has been processed; r=masayuki

https://hg.mozilla.org/mozilla-central/rev/335db9369114
https://hg.mozilla.org/mozilla-central/rev/bc650f27bb1e

Status: NEW → RESOLVED
Closed: 4 years ago
status-firefox93: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 93 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: