Conversation
…ble, by allowing system variables in paths (#14681) Fixes #14680 Summary of the issue: While it is possible to use system variables (%appdata%, %userprofile%, %temp%, etc.) in the create portable dialog's "browse" sub-dialog, it was not possible to use them in the Create Portable dialog itself. Therefore, when using the installer or the tools menu portable option, one either had to enter full paths, or use the browse dialog to utilize system variables to minimize typing. For people who create many portables, that can be unnecessary overhead. Description of user facing changes It is now possible to use system variables (such as %tmp% or %homepath%) in the path specification while creating portable copies of NVDA. Additionally, it is no longer necessary to include a drive letter when entering the absolute path to a portable target. Description of development approach In gui.installerGUI, there is a method of PortableCreaterDialog class, called onCreatePortable: The path, as entered in the dialog (self.portableDirectoryEdit.Value), was used in this method three times. Created a local variable, expandedPortableDirectory, containing that value, processed through os.path.expandvars(). Used that local value throughout the remainder of the method. Added a note to the error which appears if the user doesn't specify an absolute path, stating that system variables may be used. Rephrased the messages asking for the path, and removed the mention of the required drive letter, per NV Access review comments. Replaced a % substitution with a .format() string formatter, in an error dialog. Edited, reformatted, and added missing translator comments. Miscellaneous linting. Additional: In gui.installerGUI.doCreatePortable(): Linting, spelling, added translation comments, replaced substitutions with calls to format A note regarding no longer checking for drive letter in entered absolute path: While creating a portable copy, we ask the user for an absolute path. In the os.path module's opinion, a path can be absolute without having a drive letter. Therefore, we previously checked and threw an error if the drive letter was missing. When @seanbudd suggested removing the drive letter notation from absolute path messages, testing without entering one revealed errors that occurred if there was no drive letter, even though it shouldn't technically matter. Instead, since os.path.isabs has already determined that the path is absolute, we can just add the drive letter if it's missing. We can do that by calling os.path.abspath, which absolutizes the (probably mostly) already absolute path, by adding a drive letter if it was missing, and any other path components necessary to have a fully qualified path. --- Commits: * Made portable creation through the installer or tools menu more flexible, by allowing system variables in paths. (#14681) In the method PortableCreaterDialog.onCreatePortable: The path, as entered in the dialog (`self.portableDirectoryEdit.Value`), was used in this method three times. - Created a local variable, `expandedPortableDirectory`, containing that value, processed through `os.path.expandvars()`. - Used that local value throughout the remainder of the method. - Removed the mention of drive letter in absolute path messages, per NV Access suggestion. - Added a note to the error which appears if the user doesn't specify an absolute path, stating that system variables may be used, and giving examples. - Reformatted a translation comment for the title of that error dialog. - Replaced a % substitution with a .format() string formatter, in an error dialog. - Miscellaneous linting. - Added a few missing translator comments. * gui.installerGUI.doCreatePortable(): Linting, spelling, added translation comments, replaced substitutions with calls to format * Stop trying to check for drive letter in entered absolute path. When creating a portable copy, we ask the user for an absolute path. Since technically a path can be absolute without having a drive letter, we previously checked and threw an error if the drive letter was missing, even though Windows doesn't require one to be absolute about the path. Instead, since os.path.isabs has already determined that the path is absolute, all that remains is to add the drive letter if it's missing. We can do that by calling os.path.abspath, which absolutizes the (probably mostly) already absolute path, by adding a drive letter if it was missing, and any other path components necessary to have a pedantically correct path. * Added a blank line (linting) * Incomplete review suggestion Co-authored-by: Sean Budd <seanbudd123@gmail.com> * Explain where the os.path.abspath drive letter comes from. * update changes * update changes --------- Co-authored-by: Luke Davis <XLTechie+github@newanswertech.com> Co-authored-by: Sean Budd <seanbudd123@gmail.com> Co-authored-by: Sean Budd <sean@nvaccess.org>
…s are safe (#14627) Follow up of #14312 Summary of the issue: In #14312, we decoupled the background I/O thread from the braille module. However, the thread was still bound to IoBase in it's _initialRead method unless you'd override it. While I hoped the changes in #14312 would decrease crashing of braille, this was indeed the cause. However, crashes are still occurring here and there. I'm pretty sure I know the cause lies in the IO done completion routines that are still executed on the IO thread without ensuring that the instances of the routines still exist. I've seen this causing several access violation errors. Furthermore, #14312 saved bound methods in a dictionary on the iOThread. While this shouldn't be a big problem, this could cause potential issues with garbage collection (i.e. instances being kept alife forever because the APC of an instance was never called and it would be stuck in the cached apc dictionary). Description of user facing changes Hopefully, more stability. Description of development approach Added the ioThread as a constructor method to IoBase and derivatives as an optional argument. If not provided (default), the default IoThread is used. It will be added as a weak reference on the IoBase instance. Thereby it is no longer necessary to subclass IoBase or a derivative to override _initialRead to use another thread. Added IoThread.setWaitableTimer and IoThread.getCompletionRoutine, also ensuring that the function pointers are available when the background thread tries to call them. The function wrapper keeps a weak reference to the method it wraps. Thereby it ensures that a method of a died instance is no longer executed. IoThread.queueAsApc still stores a strong reference to the wrapped method on its APC, to keep backwards compatibility. This will be changed to weak references starting in NVDA 2024.1. API deprecation logic is in place. Removed the pre_IoThreadStop extension point. It was added in 2023.1 but never implemented and announced, so I think it is safe to do so.
…essageDialog` (#14607) Summary of the issue: When a message containing ampersand has to be displayed in nvdaControls.MessageDialog, the ampersand character is interpreted as an indication for accelerator key. Thus the ampersand character is not displayed and the following character is underlined. Putting here an accelerator key does not make sense here since the wx.StaticText used in this dialog is not the label of a focusable element. The real-life situation where this issue occurs is when installing NVDA Dev & Test Toolbox. The dialog indicates "Extension : NVDA Dev Test Toolbox 3.0" (without ampersand) instead of "Extension : NVDA Dev & Test Toolbox 3.0" (with ampersand). Description of user facing changes Messages displayed in nvdaControls.MessageDialog will be displayed correctly when the message contains ampersand character. E.g. add-on install dialog and add-on install errror dialogs will display correctly the name of add-ons containing ampersand character in their name. Description of development approach Doubled the ampersand character when present in the message.
Merge beta to master
Closes #14587 Summary of the issue: In recent notepad releases on windows 11 insider, notepad has gained the ability to open multiple files in the same window with tabs. When switching between tabs with control tab, NVDA does not the speak the currently selected tab or it has changed at all. Description of user facing changes When CTRL tab is pressed, the new tab name will be spoken, similar to web browsers. Description of development approach Implement behavior for UIA_elementSelected, if the object is a tab and is selected, speak it.
partial fix for #11829 Summary of the issue: ARIA 1.3 adds a aria-brailleroledescription attribute, which allows the web author to specify a string representation for an element's role, specific to Braille. For example: <button aria-roledescription="planet" aria-brailleroledescription="plnt">Saturn</button> A button whos spoken role description will be "planet" but in Braille it will be shown as the abreviated "plnt". Description of user facing changes NVDA will honor the aria-brailleroledescription attribute if set by the web author, when presenting web content on a braille display. Description of development approach The internal work to support custom braille role text had already been added to NVDAObjects and controlFields to allow for Braille abbreviations for landmarks. this PR: Implements roleTextBraille on the IA2Web NVDAObject, exposing the content of the brailleroledescription IAccessible2 attribute if available In the Gecko ia2 virtualBuffer, normalizes the brailleroledescription IAccessible2 attribute to the roleTextBraille NvDA attribute on controlFields.
…(22H2) (#14770) Closes #14388 Summary of the issue: Later revisions of Windows 11 22H2 (2022 Update) introduced tabbed File Explorer. At the moment NVDA does not announce tab names when switching to different tabs. Description of user facing changes NVDA will announce the name of the tab being switched to in Windows 11 2022 Update File Explorer. Description of development approach Similar to tabbed Notepad (#14588), use UIA element selected event handler to announce tab names. Unlike Notepad, speech should not be cut off to let NVDA announce focused item when File Explorer opens. Commits: * appModules/explorer: announce tab switches in Windows 11 2022 Update (22H2). Re #14388. Later revisions of Windows 11 2022 Update (22H2) introduces tabs to File Explorer, allowing users to press Control+Tab and Control+Shift+Tab to switch betwen tabs. Just like Notepad for Windows 11, UIA element selected event is fired when tab switching happens. Unlike Notepad implementation, speech will not be canceled (cut off) because doing so prevents announcement of list view items.
Fixes #14746 Fixes #13335 Partially replaces 7366dee Summary of the issue: NVDA doesn't recover when a call to oleacc.AccessibleObjectFromEvent. takes a long time. It instead freezes until the call completes, and the watchdog doesn't cancel it. See technical discussion in #14746. In short, oleacc and UIAutomationCore don't call SendMessageW and SendMessageTimeoutW in user32 directly so we can't hook the import table of these libraries. Description of user facing changes The str in #14746 should no longer be reproducible. Description of development approach Import table hooks have been changed to use detours. It was actually pretty trivial to do this. As a bonus, I moved the clipboard hook from the remote to the local library as suggested by @jcsteh I left the import table hooking mechanism in place, though it is not used by core, it is still available to add-ons.
Commonly tested components of NVDA should have standard test plans. This gives contributors a base manual testing plan when creating PRs that touch these NVDA components. This also gives alpha/beta testers a base test plan for NVDA. Description of user facing changes None Description of development approach A directory has been created, ./tests/manual, which contains markdown files group by the NVDA component, e.g. "addon store", "start up / shutdown", "speech dictionaries", "settings", etc. The goal is to document manual test plans for commonly tested NVDA components.
Fixes #12424 Summary of the issue: JABTextInfo can return rectLTRB which is then used in the boudingRects property. this can be an issue for functions that expect rectLTWH types to be returned. Description of user facing changes None Description of development approach walked through where JABTextInfo could return a rectLTRB instance. found it
Fixes #5866, fixes #7396, fixes #12101 Summary of the issue: In these years, Microsoft Word users working without UIA had no feedback about background and highlighting colors, often used by colleagues, teachers and students. UIA has provided a partial solution when available, but its support for these features is far from perfect (see later). Description of user facing changes Assuming UIA is not available/forcibly enabled: when color reporting is enabled in formatting preferences, users will hear background colors too; when marked/highlighted text reporting is enabled in formatting preferences, users will hear highlighting colors ("highlighted in {color}" and "no highlighting"), regardless of color reporting. Description of development approach It was very difficult to find a way, so I'll add some details. Initially, I used VBA objects approach, querying Paragraph.Shading.BackgroundPatternColor and Range.HighlightColorIndex over a winwordDocument.Range to calculate each time, so it was very slow. Then I found this document and, after having understood what I needed and how to find the required wdDISPID_ constants, I was able to move all work on the C++ component of nvdaHelperRemote related to winword, that appears very much faster. In window/winword.py, to take advantage of winwordColorToNVDAColor work, I added also a dict that collects indexes from wdColorIndex and decimal values from wdColor. About speech, I had to introduce a new format field, highlight-color. Now, UIA: sure, it already covers background and highlight colors, but expose them as the same attribute, via UIA_BackgroundColorAttributeId (and no, I asked, even visually they are distinct). There is an AnnotationType_Highlighted identifier, but it seems to not be used in this scenario. Locally I have a possible workaround, based on the fact that, as you see in Word Home menu, highlighting color is applied to characters, background color to paragraphs; so, if textRange has a background-color, I compare it to that retrieved from paragraph and, if I receive IUnknown/MixedAttributeValue, I assume the initial one is an highlighting color and try to get the real background color from "\r" EOL. But I'm not totally convinced, so I not included it in this PR for now.
…alog (#14782) Closes #14768 Summary of the issue: NVDA menu and NVDA settings dialogs cannot be accessed when modal message dialogs are displayed. When using gestures to open the NVDA menu and settings dialogs, users should be warned their action cannot be completed when a modal dialog is open. Description of user facing changes Added warning message to opening GUI windows/menus, when a modal dialog is open Description of development approach Added warning message to opening GUI windows/menus, when a modal dialog is open
Closes #14726 Summary of the issue: When the AC is connected, reporting "Charging battery" may be misleading, e.g. when the battery is fully charged. It is more accurate to state "AC connected" Description of user facing changes "AC connected" is reported instead of "charging battery" when reporting battery status
Closes #14773 Summary of the issue: In #14773, the user wanted to document when the code is loaded from the scratchpad directory. Description of user facing changes As discussed in the issue, it is hard to add more details in the GUI. Thus, the User Guide's paragraph describing this option has been updated. Not that it is easily reachable from the GUI thanks to context help. The following updates have been made: Added a sentence to indicate when all the modules from the scratchpad are loaded Added visual enhancement providers to the list of the modules that can be loaded from the scratchpad. Removed the sentence comparing the current situation with older versions of NVDA when the scratchpad did not exist and test modules were directly loaded from appModule, globalPlugins, etc. subfolders. Indeed, the scratchpad has been introduced in NVDA 2019.1, which is now quite old.
Closes #14779 Summary of the issue: destination of graphic links are not reported in chrome/edge Description of user facing changes Destination of graphic links now should be reported in chrome/edge browsers Description of development approach NVDA lands its focus to graphic elemeng "img" which does not have href value, but an element which is parent of that element is link. So one more check was introduced to ensure han if we are focusing a graphic element and its parent is a link, we are now replacing an object by its parent object
… enabled (#14703) Fixes #14689 Summary of the issue: Due to a bug in API Level 0 and 1 consoles (see microsoft/terminal/#5243), sometimes NVDA freezes during dictionary processing of console text, containing a huge amount of blank lines. Description of user facing changes None. Description of development approach If current focus object has apiLevel 0 or 1, and difference between regular text and text with rightside blank lines stripped is greater than 100, we use cleaned text for dictionary processing.
Revert "Avoid freeze in Windows API Level 0 and 1 console when UIA support is enabled"
…les (#14811) Summary of the issue: While working on #14810, I found several places where comments about the core extensionPoints could be made clearer, or had typos/capitalization errors/questionable grammar. Description of user facing changes None. Description of development approach I fixed them as I went along, and scooped them all into their own branch. Here is the result. I changed no code in this, and nothing structural has been altered. That is, where #: style comments were used in some places, and docstring style comments in others, I left them that way. I'm not actually sure what we prefer now. I wasn't trying to lint anything, just fix language.
Closes #13036 Summary of the issue: In #13036, the reporter needs an input gesture to quickly change the language of Windows OCR. More generally, if a user has to modify frequently a setting for their activity, a specific command to modify this setting is more handy than always opening the settings dialog. Description of user facing changes A new unbound command has been added to cycle through available languages for Windows OCR. It is in the Misc category, the same as the one of the already existing command to recognize the navigator object with Windows OCR. Description of development approach Made the script based on what was in the settings OCR panel Made the assumption that at least one language (probably English) is installed on all systems supporting UwpOCR; this assumption is already done if you read the code of the OCR settings panel and we have not had people complaining of issues. While at it, moved 3 isolated class variables related to screen curtain next to the related script.
…comes from external code or not. (#14812) Discussion in #14806 Summary of the issue: When logging NVDA tries to determine if the logged message comes from its own code or from an add-on. In some cases it does so incorrectly. Case 1: Directory prepended to sys.path by an add-on Some add-ons have to modify sys.path to import additional libraries. NVDA's logHandler relied on the fact that the first entry in path represents the location of NVDA's source code. While add-on developers should really clean-up after themselves i.e. modify path only for as long as necessary to import additional libraries this is not something we can enforce. Initially observed by @CyrilleB79 for an add-on for ChatGPT. Case 2: Messages logged from add-ons installed in the default config for source copies By default configuration folder for source copies is placed next to NVDA sources, i.e. in the source folder. When determining if the path belongs to NVDA or not we used to check if the given path starts with NVDA's source folder which was true for the plugins in the user config even though the code was not a part of NVDA. Description of user facing changes This should affect only developers who inspect the log. Description of development approach When checking if the path is external or not we no longer rely on sys.path - rather the location of the logHandler is used to determine the true location of NVDA's source code. In addition if the path is beneath the current NVDA's config it is always marked as external.
Follow up of #14759 Fixes #14784 Partially reverts 9b97de0 Summary of the issue: At least one custom IME is reported to no longer work in editable controls within NVDA. Description of user facing changes Fix the regression Description of development approach We no longer use the background thread to handle cancellable messages, as it seems using the background thread causes IME messages to be discareded. This means a partial revert of 9b97de0. In fact, this pr removes the background thread but keeps the event based approach to cancel calls from NVDA's watchdog.
Summary of the issue: The add-on datastore has certain expectations of an add-on manifest. These expectations are not required to work with NVDA, but require manifests to be updated to be hosted on the add-on datastore. We may want to make these changes in a future API breaking release, and add validation to enforce them. Description of user facing changes None Description of development approach Updates the add-on manifest spec to match the requirements of the add-on store better. We may want to add validation for these requirements in a future API breaking release.
Fix-up of #14350. Summary of the issue: Running NVDA 2023.1 (and older), with add-ons and/or scratchpad enabled: I get the following deprecation warnings: When opening start menu: WARNING - appModuleHandler._warnDeprecatedAliasAppModule (15:49:46.531) - MainThread (19688): Importing appModules.searchapp is deprecated, instead import appModules.searchui. When switching to Notepad++: WARNING - appModuleHandler._warnDeprecatedAliasAppModule (15:50:26.621) - MainThread (19688): Importing appModules.notepad++ is deprecated, instead import appModules.notepadPlusPlus. And if I force errors on deprecated code by modifying NVDAState._allowDeprecatedAPI to return False, I get errors instead. This is not expected since these warnings/errors come from NVDA's core code which should not (and actually does not) contain deprecated code. Description of user facing changes No more wrong deprecation warnings/errors due to NVDA's core appModules when opening start menu or switching to Notepad++ Description of development approach appModules.__path__ contains the paths where NVDA has to search appModules. It contains first the folder in the scratchpad, then the folders in add-on containing appModules and finally the core appModule folder. Thus we need to look at the last element of appModules.__path__, not the first as it was done.
…14816) Fixes #14725 Summary of the issue: Under Windows 11, attempting to open the NVDA Help menu items "Contributors" or "License", results in Notepad trying to open nonsense filenames while using installed, normal user level, copies of NVDA Through testing, this has been narrowed to a bug in os.startfile in Python 3.7 as invoked on Windows 11, though the actual bug may be in a lower level library. The bug does not seem to occur when using the commandline "start" command. It also does not occur in portable or admin level copies of NVDA. Description of user facing changes Restores the ability to open the Contributors List or License file from the NVDA Help menu. Description of development approach Through testing, I and @britechguy were able to narrow the source of the errors, and determine that attempting to open the file for editing, rather than by trusting the Windows open file association for .txt files, would open these files in Notepad correctly. Taken from the text of the commit: Added the _displayTextFileWorkaround function to the systemUtils module. Called it wherever os.startfile was opening a .txt file in gui/__init__.py. The function uses os.startfile's "edit" operation to open the text file, which still uses Notepad, at least on most systems. Additionally: gui.MainFrame was importing systemUtils late, in init, and onRunCOMRegistrationFixesCommand. Moved to a single import in top section. Testing strategy: Manual testing with 2023.1's Python console, that calling os.startfile as described, opens these files correctly under Windows 11. While calling it the standard way from the Python console, results in nonsense filenames being delivered to Notepad, and the subsequent failure of the task. Using a try build of this PR, tested opening these help menu items on Windows 10, with expected success. Tested that installing a try build of this PR on Windows 11, could open the files from the menu, and could open a copy of copying.txt at the root of the system drive, using the Python console. A portable copy generated from this PR, placed in the root directory of a USB stick, could open its included text files from the Help menu, and could open a copy of copying.txt placed at the root of the USB drive. Additionally, to confirm that consolidating and moving the imports of systemUtils didn't break anything, I tested that NVDA launched, and the COM Registration Fixing Tool still works, under Windows 10, which is sufficient. Tested on: Windows 11: 22H2, build 22621.1555 Windows 10: 22H2, build 19045.2846 Known issues with pull request: It is not necessary to use operation="edit" under Windows 10. Since this seemed (1) rather harmless, and (2) a low impact bug, I didn't think it was necessary to test for Windows version before deciding which call structure to use for the new function. It is conceivable, that opening for editing will have side effects on some systems. However, since it seems reasonable to presume that a user who has made editing text files open in some other program than Notepad is quite experienced, I thought the negative potential here was rather low to non-existent. When we migrate to a newer Python version, the necessity of this workaround should be reevaluated, as hopefully this will be fixed by a newer library.
… consoles (#14822) Fixes #14689 Summary of the issue: IMPROVED (apiLevel 1) and END_INCLUSIVE (apiLevel 0) UIA consoles produce a lot of blank lines (more than 17000) in some output, causing a NVDA freeze during speech dictionary processing. Description of user facing changes None. Description of development approach I added a _get_text method to ConsoleUIATextInfo class (for apiLevel 1 consoles), stripping all \r\n on the rightside of output from _get_text of superclass (implicitly used previously). For apiLevel 0 consoles (ConsoleUIATextInfoWorkaroundEndInclusive class), I simply considered that the _get_text already present calls _get_text from superclass, that is, ConsoleUIATextInfo, so text is already cleaned.
Closes #14509 Summary of the issue: NVDA does not recognize Windows 11 IME interface, or if it does, announces candidate items multiple times. Description of user facing changes NVDA will recognize and announce Windows 11 IME candidate items used when entering text in languages such as Chinese, Japanese, Korean, and other languages through use of input method editors (IME). Description of development approach Three changes to modern keyboard app module: Recognize IME candidate UI and candidate items found in Windows 11. Unlike Windows 10, Windows 11 adds an extra element to IME candidate window, therefore descend one more level when locating IME candidate items in app module version of UIA element selected event handler. Veto UIA element selected event for IME candidate item in Windows 11 until a solution that allows focus and element selected events to cooperate when announcing IME candidate items. For the third change, feedback from people speaking and typing Chinese, Japanese, and Korean would be helpful (this PR was based on Korean nput but could be expanded to cover Chinese, Japanese, and perhaps other languages in the future, either part of this pull request (unlikely) or in future PR's). Commits: * appModules/modern keyboard: recognize Windows 11 IME candidate items. Re #14509. Windows 11 IME candiate's parent window has AutomationId of 'TEMPLATE_PART_CandidatePanel' and items underneath it wil be reocnigzed as IME candidate items. * Modern keyboard/Windows 11 IME: recognize IME UI in Windows 11. Re #14509. If UI Automation Id is 'TEMPLATE_PART_CandidatePanel' or 'IME_Prediction_Window' and role is either a list or a pop-up menu, reocgnize this as Windows 11 IME user interface. * IME candidate item: do not allow UIA elemnet selected event in Windows 11. Windows 11 raises focus event when IME candidate receives system focus, and without turning off element selected event, it will result in NVDA announcing candidate items twice. Therefore return early if IME candidate item raises element selected event while running Windows 11. * IME/element selected: descend one more level when handling IME candidate item in Windows 11. Unlike Windows 10, Windows 11 IME window adds an extra element when descending IME window hierarchy, therefore descend one more level to handle IME candidate item and UIA eement selected event coming from it.
…ints (#14810) Closes #14648 Summary of the issue: There is currently no definitive list of all available extension points. Since these seem to be the preferred future direction for add-ons and other code to interoperate with NVDA internals, it would be valuable to include a list of them in the Developer Guide. It would also be valuable to include various examples and further documentation there, but that can come in a later PR. Description of user facing changes None. Description of development approach Created a new chapter in the Developer Guide, describing very briefly what extension points are, mainly as a concept introduction. This could stand to be expanded significantly. Used grep to find all occurrences of "extensionPoint" in the source. For each one, determined why the module was being imported, and if it was actually used to create an extension point, added appropriate entries to the dev guide describing that extensionPoint.
Fixes #14826 Summary of the issue: When pressing 3 times numpad2, the character number is reported by speech (both in decimal form and hexadecimal form). However, for braille users it would be useful to have this information. Description of user facing changes When pressing three times numpad2 to call the script "Report current character in review", the reported information (character number in decimal and hexadecimal) is also reported in braille, not only by speech. First press and second press of this script remain unchanged since: First press only report the current character which is already available at the review cursor's position on the braille display, provided that the braille follows automatically (default settings) or review. Second press is a feature dedicated to speech users, when they cannot hear correctly the character name. Description of development approach Added a braille update as done in ui.message. We do not use directly ui.message since the hex value has to be spelt.
…d above (#14839) Found when investigating #5221 Fixes #6871 Fixes #11512 Though both of these issues had already been avoided in Outlook 2016+ by #14280 Summary of the issue: When arrowing through a password in the password field in the Protect Sheet dialog in Microsoft Excel (alt h o p), NVDA produces an error and says nothing. Similarly, when tabbing to that control and the cursor is already on a password character, NVDA produces an error and the focus is not announced at all. Description of user facing changes NVDA no longer fails to announce the focus when tabbing to the password field in Excel's Protect sheet dialog. Description of development approach 1. In the ITextDocument TextInfo's text property: catch COMError when calling range.text. This can occur when the edit control is protected. Just log a debugWarning and return the empty string - there is nothing else we can do about this error. This allows NVDA to announce the focus without an error. And when arrowing through the characters, 'blank' will be spoken rather than an error, which is better than nothing. 2. In the appModule for Excel: treat RICHEDIT60W windows as having a good UI automation implementation if on Windows 10 or higher and Office 2016 or higher. Office 2016 on Win 10+ has a very good UI automation implementation for RICHEDIT60W, which includes being able to fetch 'circle' characters when arrowing through a password. So in summary, on Office 2016 win10+ the error is gone and NvDA can announce 'circle' when arrowing through password characters in the Protect sheet dialog. On older versions of Office / Windows, the error is gone, though NVDA will announce 'blank' when arrowing through password characters.
Summary of the issue: Added some gestures. Do not try to open port if it is not present. Description of user facing changes Added following gestures: | Shows braille settings | f1+home1, f9+home2 | | Reads status bar and moves navigator object into it | f1+end1, f9+end2 | | Cycle the braille cursor shape | f1+eCursor1, f9+eCursor2 | | Toggle the braille cursor | f1+cursor1, f9+cursor2 | If there is working connection, and I/O error occurs, port presence is checked before trying to open it again. USB serial port disappears when cable is plugged out or device is powered off, thus efforts to open port are then useless. Debug level log entries are also more readable telling that port is not present instead of exception info. Description of development approach Added boolean function _portPresent to class ReadThread in _threading.py.
Fixes #14820 Summary of the issue: The checkPot script used to check translation comments also checks the subfolder userConfig. This is not correct since the code in userConfig is not NVDA's code but code from add-ons or from the scratchpad. Description of user facing changes The checkPot script does not check the userConfig subfolder anymore. Description of development approach In addition to COM interface folder, the userConfig folder is also excluded from the check. Also the exclusion of these two folders is made in the folders' list rather than in the Glob expression since scons' Glob does not support filtering recursively subvolders; this is also probably more efficient to filter the folders than using Glob for each file.
Merge beta to master
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
13 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.