Skip to content
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's visual highlight does not correctly track the system focus in Windows+X menu if system DPI is set to more than 100% #12070

Closed
k-kolev1985 opened this issue Feb 13, 2021 · 12 comments · Fixed by #13254
Milestone

Comments

@k-kolev1985
Copy link

Steps to reproduce:

  1. Start NVDA.
  2. Open NVDA's settings from the "Vision" category, enable the visual highlight feature, making sure that the sub-option to highlight the system focus is enabled. Then press OK to apply the changes.
  3. Open System Settings (Windows+I) -> Ease of access -> Display.
  4. With TAB go to the combo-box under the heading "Make everything bigger". That is the one to select the display's DPI.
  5. Open the combo-box with Alt+Down Arrow and from it select a value bigger than 100% (I've selected 150%) and than confirm and apply your choice with ENTER. The change should be applied immediately, without the need for log off or restart of the system.
  6. Just in case, restart NVDA.
  7. Press Windows+X to invoke the Start button's context menu (I don't know what is the official name of that menu). Actually, I think the issue applies to all context menus in the system - not just the one for the Start button.
  8. Use the Up/Down arrow keys to navigate in the menu.
  9. Observe where the system focus really is and where the NVDA's visual highlight indicates that the system focus is.

Actual behavior:

NVDA's visual highlight does not correctly indicate where the system focus is in this menu.

Expected behavior:

NVDA's visual highlight should correctly indicate where the system focus is in this menu.

System configuration

  • Operating system: Windows 10 Pro version 20H2 (build 19042.804), 64-bit, in Bulgarian with all locale settings set to "Bulgarian".
  • NVDA version: alpha-21753,e5d62e32, installed, in bulgarian; 2020.3, installed, in bulgarian.
  • Processor: Intel Core i5-9400F at 2.90GHz.
  • RAM Memory: 16.00GB.
  • Graphics: MSI GeForce GTX-1050TI Gaming X 4G, 4096MB dedicated memory, desktop resolution set to 1920x1080.
  • Sound Card: Realtek ALC892 at Intel Cannon Point PCH.

Other questions

Does the issue still occur after restarting your computer?

Yes, it does.

Have you tried any other versions of NVDA? If so, please report their behaviors.

Yes - v2020.3 - the behavior is the same.

If addons are disabled, is your problem still occurring?

Yes - it is.

Did you try to run the COM registry fixing tool in NVDA menu / tools?

No, because I don't think it has anything to do with this issue.

@grahamarmfield
Copy link

I'm having a similar issue with my setup on my laptop. NVDA Focus Highlight does not show in the correct place when I have the Text size in Windows settings set to anything other than 100%.

I'm using a value larger than 100% as my eyesight is not perfect and I can't easily read text when it's set to 100%.

Here are the settings I'm using:
image

And this is what the Focus Highlight looks like in Firefox. The red focus ring is some way above and to the left of where focus really is (on the PM promises... link)
image

The situation is still the same when I restart NVDA, restart my machine, and upgrade to latest version of NVDA - currently on 2020.4

@ivnc
Copy link
Contributor

ivnc commented Jun 4, 2021

A Spanish-speaking user with low vision, able to use the mouse, has reported a similar problema with NVDA's mouse tracking. If he moves the mouse with a higher DPI for examle in Notepad, NVDA reports a different menu item from which the mouse is over. I think it's probably related to this.

Regards.

@mrazzari
Copy link

I confirm this is related to the "Screen > Scale" setting, also found as "Make everything bigger" in the Accessibility menu. As seen on @grahamarmfield's screenshot, the red outline is tracking the "original" position and size of the focused element, as if it wasn't enlarged by Windows.

But here's a twist: this only happens to me when using a portable copy of NVDA.

If I use the "installed" version, the one I've just used to create the portable one, the focus outline works just fine, regardless of the screen scale setting.

@mrazzari
Copy link

More info: this only happens when I use 2 monitors, and one of them is on a different scale factor.

The below output is from the NVDA Python console, exact same hardware and Windows configuration. The only thing that changes is whether I'm running the installed NVDA or the portable one.

Installed NVDA:

>>> [wx.Display(i).GetGeometry() for i in range(wx.Display.GetCount())]
[wx.Rect(0, 0, 1920, 1080), wx.Rect(-1820, -1080, 1920, 1080)]

Portable NVDA:

>>> [wx.Display(i).GetGeometry() for i in range(wx.Display.GetCount())]
[wx.Rect(0, 0, 1920, 1080), wx.Rect(-2730, -1620, 2880, 1620)]

@Adriani90
Copy link
Collaborator

cc: @LeonarddeR

@LeonarddeR
Copy link
Collaborator

Higher DPI is just disastrous for these things in general, I would recommend against it if not strictly necessary.
it is likely that Windows just returns the wrong coordinates when getting the location for the menu items. There's likely nothing we can do about this.

@k-kolev1985
Copy link
Author

Well, I guess we could report it to Microsoft (?). I have to check if it occurs with Narrator as well and if it does, it could get more attention from Microsoft that way.

@k-kolev1985
Copy link
Author

The Narrator cursor correctly follows the system cursor/focus in the Windows+X menu and the context menus of Windows Explorer, where NVDA focus highlight does not with DPI scale set to for example 150%. Probably Narrator uses other methods to get those coordinates. That will make it more difficult to make a valid report for Microsoft, I think. What do you say?

@mrazzari
Copy link

@k-kolev1985 Questions on your repro to compare with mine:

  • were you able to repro using a single monitor?
  • did you compare portable vs installed NVDA?

Before reporting to MS, I'd make sure it's not a wx bug.

@k-kolev1985
Copy link
Author

@mrazzari in answer to your questions:

  • A single monitor setup is all I have.
  • I haven't tested with a portable copy of NVDA - only with an installed one.

@mrazzari
Copy link

@k-kolev1985 that's really odd. I can only repro with portable + second monitor.

@grahamarmfield
Copy link

Responding to others...

I'm seeing this on my setup which does have two monitors - where one is set to display text at 125% and the other is set to 100%. The monitor I'm experiencing the misalignment on is my laptop one where the text is set to 125%.

If I unplug the extra monitor, the NVDA visual alignment is immediately in the right place on the 125% text size laptop screen. So yes, it's only when the extra monitor is plugged in that the misalignment occurs - even if I'm primarily working with the laptop screen.

As I mentioned before, I use this setting as I find text too small to read comfortably.

I'm also using an installed copy of NVDA, not the portable version.

Additionally, I tested with Narrator with both monitors active, and with just the 125% laptop screen active. In all cases the Narrator focus highlight is in the right place.

I hope that helps.

seanbudd pushed a commit that referenced this issue Aug 30, 2022
Fixes #13370
Fixes #6722
Fixes #3875
Fixes #12070
Fixes #7083
Fixes #7915
Likely fixes #9531, otherwise close as stale/can't reproduce

### Summary of the issue:
When DPI for a monitor is not set to 100%, or when using multiple monitors with different DPI settings,
NVDA would:

- misplace highlight frames
- have inaccurate mouse tracking
- have inaccurate touch screen interaction

NVDA currently sets the DPI awareness via a Windows API call introduced in Windows Vista.
It is recommended to set DPI through the app manifest, rather than Windows API calls where possible.

Newer settings for DPI awareness have been introduced since Windows Vista.
Windows 8 introduced multiple monitor DPI awareness.
Windows 10 introduced a richer version of multiple monitor DPI awareness.

### Description of how this pull request fixes the issue:
Background docs: https://docs.microsoft.com/en-us/windows/win32/hidpi/high-dpi-desktop-application-development-on-windows#per-monitor-and-per-monitor-v2-dpi-awareness

When running as an executable, NVDA sets DPI awareness via the app manifest.
When running through source, NVDA sets DPI awareness via Windows API calls.
The most modern method available is used to set DPI awareness.

- For Windows 7, DPI awareness is unlikely to improve. There may be fixes from setting it via the app manifest instead of via Windows API calls.
- For Windows 8 and newer, NVDA has per monitor DPI awareness
- For Windows 10 1703 and newer, NVDA has [advanced per monitor DPI awareness](https://docs.microsoft.com/en-us/windows/win32/hidpi/dpi-awareness-context), including:
  - Child window DPI change notifications
  - Scaling of non-client area - All windows will automatically have their non-client area drawn in a DPI sensitive fashion. Calls to [EnableNonClientDpiScaling](https://docs.microsoft.com/en-us/windows/desktop/api/Winuser/nf-winuser-enablenonclientdpiscaling) are unnecessary.
  - Scaling of Win32 menus - All NTUSER menus created in Per Monitor v2 contexts will be scaling in a per-monitor fashion.
  - Dialog Scaling - Win32 dialogs created in Per Monitor v2 contexts will automatically respond to DPI changes.
  - Improved scaling of comctl32 controls - Various comctl32 controls have improved DPI scaling behavior in Per Monitor v2 contexts.
  - Improved theming behavior - UxTheme handles opened in the context of a Per Monitor v2 window will operate in terms of the DPI associated with that window.
@nvaccessAuto nvaccessAuto modified the milestone: 2022.4 Aug 30, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants