-
-
Notifications
You must be signed in to change notification settings - Fork 654
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
NVDA+f browseable message - pressing alt+c makes a ding #16996
Labels
bug/regression
p3
https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priority
triaged
Has been triaged, issue is waiting for implementation.
Milestone
Comments
@CyrilleB79 This is coming from MSHTML, because Alt+C is not a key sequence it knows, even if its contained javascript does. Nothing I know of can fix this, but if you know of something I'd be happy to implement it.
The alternative is to change the key to something that doesn't ding, which probably means a sequence without alt.
|
seanbudd
added
p3
https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priority
triaged
Has been triaged, issue is waiting for implementation.
labels
Aug 13, 2024
@XLTechie - can you open a PR to revert #16369 ? Please use the new revert template https://github.com/nvaccess/nvda/blob/master/.github/PULL_REQUEST_TEMPLATE/revert.md |
seanbudd
pushed a commit
that referenced
this issue
Aug 29, 2024
…after the message, and add buttons to some instances (2nd try) (#17018) Fixes #14641 Addresses #16995 Addresses #16996 Summary of the issue: In #14641 @Qchristensen reported that some users are confused by browseableMessages, and their lack of definite closure mechanisms. During the conversation, it was pointed out that in some cases, a user might also desire a copy button. During work on the PR (originally #16369), it was requested that the copy button be given an accelerator key. Description of user facing changes Added copy and close buttons to some browseableMessages, and the capability to add them to others. Description of development approach Thanks to @michaelDCurran's change in ui.browseableMessage--namely adding a Scripting.Dictionary to carry arbitrary query-string-equivalent style parameters to the mshtml instance behind browseableMessage, it is now possible to pass in values for two new buttons, and various translatable messages, without any contortions. Tried different methods in the JS and CSS of message.html, and eventually settled on one which displayed the two buttons side-by-side, under a separator. If neither button's label is supplied, the div containing the HR and buttons remains hidden. The "Copy" button can be activated with Ctrl+Shift+C, and the "Close" button by Escape. Alt+C is indicated to the user via an accessibility label. Fixed up some docstring parameter listings to match modern format. Per the issue, modified the Report Link Destination message, to have both a copy button and a close button. Per the issue, added buttons to the Report Character Information message. Per request in PR comments, used a live region to present a "Copy complete" or "copy failed" message to the user. This message remains on screen for five seconds. The AI suggested covering for more failures in the initialization and configuration of MSHTML. I used its suggested exception checking, but added a private function to display an error message to the user when one of the components fail, so at least some kind of user notice can be given. I based it on the already extant private function for messaging the user if a browseableMessage is called on a secure screen. Both of the warning functions for browseableMessage unavailable situations, are now self-contained, with respect to wx. Added an immediate return if the MSHTML window is opened without providing the dialog arguments (i.e. the message and title, at least). That situation should never actually occur, but in the unlikely event that a failure passes the error checking we have in browseableMessage, this will return immediately, instead of stranding the user in a blank window with no obvious close mechanism.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
bug/regression
p3
https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priority
triaged
Has been triaged, issue is waiting for implementation.
Follow-up of #16369; cc @XLTechie.
Steps to reproduce:
Actual behavior:
NVDA says "Text copied", a "ding" sound is heard and the text is actually in the clipboard.
Expected behavior:
NVDA says "Text copied" and the text is actually in the clipboard.
But no "ding" sound should be heard. This sound is quite unusual when pressing alt+letter to activate a button and this may let think that there has been an error.
NVDA logs, crash dumps and other attachments:
N/A
System configuration
NVDA installed/portable/running from source:
Source
NVDA version:
Version : source-master-c8a847b (2024.4.0.0)
Windows version:
10
Name and version of other software in use when reproducing the issue:
N/A
Other information about your system:
N/A
Other questions
Does the issue still occur after restarting your computer?
Not tested; probably yes.
Have you tried any other versions of NVDA? If so, please report their behaviors.
N/A
If NVDA add-ons are disabled, is your problem still occurring?
Yes
Does the issue still occur after you run the COM Registration Fixing Tool in NVDA's tools menu?
Not tested; probably unrelated.
The text was updated successfully, but these errors were encountered: