New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: don't append Shift modifier text twice to accelerators (backport: 4-0-x) #15401
Conversation
@brenca Can you manually confirm what the |
@MarshallOfSound
|
@MarshallOfSound if I use |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The usual suspects appear to still work 👍 Nice
Would it be possible to encode @MarshallOfSound's intuition about what might have broken into a test? 🤞 |
@nornagon AFAIK what @MarshallOfSound asked about is how it gets displayed, which is not really testable from JS, but I might be wrong on that. |
Could you potentially expose the result of |
@nornagon Yeah, that could work, gonna add that tomorrow to the PR for master |
fa7949c
to
13b2c45
Compare
]) | ||
|
||
assert.strictEqual(menu.getAcceleratorTextAt(0), | ||
isDarwin() ? '⌘⇥\u0000' : 'Ctrl+Tab') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
where are these \u0000
coming from? that doesn't seem right...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's what CI returned when I ran a pass to determine the values for Mac.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that's where you got them from, but not where they came from :P
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nornagon my best guess would be that 0 at the end that we (apparently) keep during conversion from base::string16
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you could fix this by converting to a std::string
before returning the value? It's surprising to me that that wouldn't be done automatically by the conversion into JS though.
Release Notes Persisted
|
Description of Change
Backport of #15400 to 4-0-x
Checklist
npm test
passesRelease Notes
Notes: fixed some accelerators having
Shift
appended to them twice