https://chromium.googlesource.com/chromium/blink/+/eb86bb4125b6063202536b960da0f013d1d0d1a revealed that we're clearing the access key map in scheduleStyleRecalc. That seems way too often. We need to either not cache the map at all or cache it better by updating the map when elements are added or removed or when relevant attributes are changed.
There's a hilarious comment: // FIXME: Why on earth is this here? This is clearly misplaced. invalidateAccessKeyMap();
I am getting following behavior across all browsers using test case from Chromium patch: Link - https://jsfiddle.net/La1zdv2f/show NOTE - I modified the test slightly because there was double </head> end tag. ** Safari 15.6 ** Need to focus on input field and it automatically generated first access key and then later pressing CTRL+OPTION+B and C leads to one by one event show up (C leads to two event and then complete test) and later show "PASS". ** Firefox Nightly 105 ** Need to focus on input field and it automatically generated first access key and then later pressing CTRL+OPTION+B and C leads to one by one event show up (C leads to two event and then complete test) and later show "PASS". ** Chrome Canary 106 ** Need to focus on input field and it automatically generated first access key and later just pressing one shortcut lead to whole test being complete rather than "B" and "C" being separate. ____ I am not sure on web-spec but Safari matches with Firefox in above test case but different from Chrome. Appreciate if someone else can comment and mark this bug accordingly. Thanks! Also is these WPT tests related to following: https://wpt.fyi/results/uievents/interface/keyboard-accesskey-click-event.html?label=master&label=experimental&aligned&view=subtest&q=access%20key
The test is only tangentially related to the issue at hand, which is a performance issue. We don't have the "Why on earth is this here" comment anywhere in WebKit any more, and we don't have an "invalidateAccessKeyMap" function, so I'm claiming Config Changed.