Fix some issues where an NVDAObject is used where a Window is expected#15400
Merged
Conversation
See test results for failed build of commit 24fab6bc3a |
LeonarddeR
suggested changes
Sep 8, 2023
Co-authored-by: Leonard de Ruijter <leonardder@users.noreply.github.com>
michaelDCurran
approved these changes
Sep 20, 2023
See test results for failed build of commit 102cf345c7 |
This was referenced Feb 1, 2024
seanbudd
pushed a commit
that referenced
this pull request
Feb 4, 2024
Fix #16120 Related to #15400. Summary of the issue: Sporadic errors still occur when locking/unlocking Windows session. As per #15400, this is due to the fact that api.getFocusObject returns an NVDAObjects.NVDAObject but we use it as it was an NVDAObjects.window.Window. But that's not the case when the focus is (or was) winAPI.secureDesktop._handleSecureDesktopChange._SecureDesktopNVDAObject. Description of user facing changes Probably none; these errors did not seem to have any visible impact. Description of development approach Check the class of the object returned by api.getFocusObject before using its properties.
Adriani90
pushed a commit
to Adriani90/nvda
that referenced
this pull request
Mar 13, 2024
) Fix nvaccess#16120 Related to nvaccess#15400. Summary of the issue: Sporadic errors still occur when locking/unlocking Windows session. As per nvaccess#15400, this is due to the fact that api.getFocusObject returns an NVDAObjects.NVDAObject but we use it as it was an NVDAObjects.window.Window. But that's not the case when the focus is (or was) winAPI.secureDesktop._handleSecureDesktopChange._SecureDesktopNVDAObject. Description of user facing changes Probably none; these errors did not seem to have any visible impact. Description of development approach Check the class of the object returned by api.getFocusObject before using its properties.
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
4 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.
Link to issue number:
Fixes #15395
Summary of the issue:
There are many instances in NVDA where we implicitly or explicitly (with typing) expect an
NVDAObjectbut code uses properties only available for aNVDAObjects.window.Window.This is because most objects are
Windows and usually these implicit expectations are safe.This PR attempts to catch some known instances where these expectations are not safe.
Description of user facing changes
Fix error when switching to the secure desktop
Description of development approach
Improve typing and catch some likely cases where a
Windowshould not be expectedTesting strategy:
Test using the secure desktop, check log for errors
Known issues with pull request:
There are other instances where this is the case.
Future work such as improved typing will help weed out these problems.
Change log entries:
None, unreleased regression
Code Review Checklist: