This code expects documentElement to be <dialog> which isn't true anymore as of bug 1585482:

let buttonBox = window.top.document.documentElement.buttonBox;

https://searchfox.org/mozilla-central/rev/8526066f548af9ec3ebb462ff73c47ccc183f533/toolkit/content/widgets/button.js#109

It could be updated to something like this if we want to keep the same semantics:

let dialog = window.top.document.querySelector("dialog");
if (dialog && dialog.buttonBox) {
...
}

But, I don't see any acceskey attribute set on the buttonBox in https://searchfox.org/mozilla-central/rev/9c6e7500c0015a2c60be7b1b888261d95095ce27/toolkit/content/widgets/dialog.js#101-119, so perhaps this code should just be removed (along with the buttonBox getter in dialog as this seems to be the only consumer). Or am I missing something about how this gets wired up and this is actually causing a bug?

fireAccessKeyButton looks for buttons with access keys within buttonBox, it doesn't expect buttonBox itself to have an access key:
https://searchfox.org/mozilla-central/rev/8526066f548af9ec3ebb462ff73c47ccc183f533/toolkit/content/widgets/button.js#210-230

Dialog button access keys are set here:

https://searchfox.org/mozilla-central/rev/9c6e7500c0015a2c60be7b1b888261d95095ce27/toolkit/content/widgets/dialog.js#369-380

https://searchfox.org/mozilla-central/search?q=buttonaccesskey%5Ba-z%5D&case=true&regexp=true

I might actually end up removing this code in bug 1626342...

(In reply to Dão Gottwald [::dao] from comment #3)

I might actually end up removing this code in bug 1626342...

That would be great if so, thanks.

2 years and 6 duplicates later, Thunderbird would love to see this fixed - I've attached a patch based on Brian's comment 1, which fixes the problem for me.

In terms of workflow, I guess we should have landed this one-liner much earlier regardless of future planned improvements (which haven't materialized yet), so that in the meantime, the problem is fixed and users benefit...

The severity field for this bug is relatively low, S3. However, the bug has 6 duplicates.
:thomas8, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

(In reply to Release mgmt bot [:suhaib / :marco/ :calixte] from comment #13)

The severity field for this bug is relatively low, S3. However, the bug has 6 duplicates.
:thomas8, could you consider increasing the bug severity?

Thanks bot, considered and still right at S3. As much as we'd like to see this fixed asap, as it affects all such dialogs, it doesn't quite fit the definition of S2: (Serious) Major functionality/product severely impaired or a high impact issue and a satisfactory workaround does not exist.

https://hg.mozilla.org/mozilla-central/rev/7a25187ada41

Awesome! Thanks Brian for landing my patch and adding the test!

https://hg.mozilla.org/mozilla-central/rev/8fca816e5d9f

Did you want to nominate this for ESR102 approval also?

Comment on attachment 9291391 [details]
Bug 1625632 - Fix dialog button access key handling for unmodified keypress. r=bgrins

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: See user impact
• User impact if declined: Breaks ages of muscle memory when pressing the unmodified access key of a dialog button unexpectedly fails. Also for Thunderbird where such dialogs may occur much more frequently.
• Fix Landed on Version: 106
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Near zero risk as we're just updating a single selector (as dialogs are no longer root elements).

Comment on attachment 9291391 [details]
Bug 1625632 - Fix dialog button access key handling for unmodified keypress. r=bgrins

Approved for 102.5esr.

https://hg.mozilla.org/releases/mozilla-esr102/rev/ea3e42d5bbff
https://hg.mozilla.org/releases/mozilla-esr102/rev/e38a4f59bd10