fix: recognize ?Cancel/?No as default cancel buttons

[camilstaps]

Description of Change

This allows e.g. ?Cancel to be recognized automatically as the cancel button.

Checklist

• PR description included and stakeholders cc'd
• npm test passes
• PR release notes describe the change in a way relevant to app developers, and are capitalized, punctuated, and past tense.

Release Notes

Notes: none

[welcome]

💖 Thanks for opening this pull request! 💖

We use semantic commit messages to streamline the release process. Before your pull request can be merged, you should update your pull request title to start with a semantic prefix.

Examples of commit messages with semantic prefixes:

• fix: don't overwrite prevent_default if default wasn't prevented
• feat: add app.isPackaged() method
• docs: app.isDefaultProtocolClient is now available on Linux

Things that will help get your PR across the finish line:

• Follow the JavaScript, C++, and Python coding style.
• Run npm run lint locally to catch formatting errors earlier.
• Document any user-facing changes you've made following the documentation styleguide.
• Include tests when adding/changing behavior.
• Include screenshots and animated GIFs whenever possible.

We get a lot of pull requests on this repo, so please be patient and we will get back to you as soon as we can.

[ckerr]

@camilstaps I'm not sure that I understand what bug this PR fixes. Could you give some more information on what the goal of this PR is? For example, is ?Cancel a common use case that needs an easy path that can't be handled by options.cancelId?

[camilstaps]

@ckerr thanks for the review!

I agree that 'bug' fix may be too harsh, but didn't want to call it a feature either.

The documentation for cancelId says:

By default this is assigned to the first button with "cancel" or "no" as the label. If no such labeled buttons exist and this option is not set, 0 will be used as the return value.

It seems logical for me that if "Cancel" and "No" are recognized to determine the default, "&Cancel" and "&No" should be recognized as well. This is at least what I would expect reading the documentation, since I read it as if "cancel" and "no" refer to the label visible to the user, i.e., without access keys.

You asked:

For example, is ?Cancel a common use case that needs an easy path that can't be handled by options.cancelId?

Yes, I'd say that ?Cancel (and ?No) are common use cases. Of course they can be handled by cancelId as well, but the same goes for Cancel and No, for which the easy path is implemented.

I can imagine you're afraid of the added complexity(?). In that case maybe the documentation of cancelId can be updated to explicitly state that there should be no access keys for the default option resolution to work?

[ckerr]

No it's not the complexity I'm concerned about -- I think I may be missing some context about the problem this PR solves, and that's what's confusing to me.

When would one want to pass ?Cancel or ?No as button text? That's not text that I can recall seeing on a button -- is there something else going on here, e.g. is the prepended ? treated in a special way on some platform?

[camilstaps]

Oh, I see the confusion now. ? is used for access keys (see normalizeAccessKeys). It is not displayed, but the following character is used for a kind of shortcut key. ?Cancel lets you cancel with Alt+C for example.

[camilstaps]

@ckerr did I need to ping you? Apologies if you were already notified and it simply takes some time—that's fine!

[zcbenz]

Generally treating no/cancel as default cancel buttons has been proven a bad idea: it does not work for internationalization, it adds complexity for a very simple thing.

We are not going to remove this feature, but we are also not going to add more complexity for it, so I'm closing this PR.

[camilstaps]

@zcbenz OK, fair decision. Maybe it's a good idea to make this explicit in the documentation though.