Block level links not triggered with 'automatically set system focus to focussable elements' off

[hills001]

Edit:
Description has been updated with information from comments:

• Block level links not triggered with 'automatically set system focus to focussable elements' off #8528 (comment)
• Block level links not triggered with 'automatically set system focus to focussable elements' off #8528 (comment)
• Block level links not triggered with 'automatically set system focus to focussable elements' off #8528 (comment)
• Block level links not triggered with 'automatically set system focus to focussable elements' off #8528 (comment)

Steps to reproduce:

Using the example page at: https://nvda-firefox-block-level-links-8528.netlify.app/.

In browse mode, tab to each of the example links and press 'Enter' key to activate. With 'automatically set system focus to focussable elements' set it to off some don't activate.

Settings:

• 'Enable browse mode on page load'
• 'Automatic focus mode on focus changes' enabled
• 'Automatic focus mode for caret movement' disabled.
• Use NVDA+ 8 to turn toggle 'automatically set system focus to focussable elements'. Set it to off.

Steps:

• Open the demo page
• Ensure focus is not on a link on the page already: press shift+tab to land on the address bar
  • You now have to press F6 to get back to the document, but we can be confident focus is not on a link.
• Confirm virtual cursor is on first heading: press numpad+8 to hear "heading level 1 Example block level links"
• Press NVDA+space to once or twice to confirm browse mode is enabled.
• Press Tab to any of the three links and press enter, new page does not open
• Confirm that the virtual cursor follows focus: press numpad+8 to hear the link "visited link heading level 3 Example 1"
• Press enter to activate.

Actual behavior:

Firefox

With 'automatically set system focus to focussable elements' off (NVDA+ 8)
The first and second example links are not triggered by pressing Enter.

Chrome

With 'automatically set system focus to focussable elements' off (NVDA+ 8)
The first and second example links are not triggered by pressing Enter.

Expected behavior:

Enter should activate the link.

System configuration:

NVDA Installed/portable/running from source:

Installed

NVDA version:

2018.1.1

Windows version:

10.0.15063 Build 15063

Name and version of other software in use when reproducing the issue:

Firefox 61.0.1

Does the issue still occur after restarting your PC?

Yes

Have you tried any other versions of NVDA?

No

Other notes:

Looking at the NVDA logs, I can see these differences:

--IE11---
name: u'A third level heading\r\nSome sub text'
role: ROLE_LINK
states: STATE_FOCUSABLE, STATE_LINKED, STATE_FOCUSED
isFocusable: True
hasFocus: True

--FIREFOX---
name: u'A third level heading'
role: ROLE_HEADING
states:
isFocusable: False
hasFocus: False

[Adriani90]

@hills001 this is not occuring in Firefox 66.0.4 with NVDA 2019.1.1. At least I cannot reproduce it. Do you still see this issue?

[hills001]

Hi,
Thanks for the reply. I have updated to NVDA 2019.1.1 and still have the problem in Firefox 66.0.5.

The problem occurs when using the tab key to navigate between the three example links/boxes in the above Codepen, and then using the Enter key to trigger.

If I exit NVDA, I'm able to tab/enter on all three boxes. I'm able to tab/enter on all three boxes in Chrome and IE when NVDA is running.

[Adriani90]

hmm, I am not sure if I can reproduce this issue on firefox 72.0.1. I think maybe @MarcoZehe has more helpful elaboration on this. Actually I don't know exactly what should happen when the links are triggered. Maybe there is a highlight or so but it is difficult to assess it without sighted assistance :-)

[hills001]

Hi, thanks for the reply, I'm still experiencing this issue, using NVDA 2019.1.1 and Firefox 72.0.1.

I have created a new demo page at: https://cdpn.io/DemoBrand/debug/QWwVZPq/xnMabZJGPpdr

The three links on the demo page should open Google, NV Access and Github in new tabs. When using the enter key to trigger the links, only the third link works for me in Firefox when NVDA is running.

When NVDA is not running all three links work correctly. As per the logs in my initial post, I suspect focus is being shifted to the inner block level elements when NVDA is running, so the links are no longer selected.

[hills001]

@Adriani90 Hi, I've just updated the demo page for this issue: https://nvda-firefox-block-level-links-8528.netlify.app/ - I am still having this problem with NVDA 2019.1.1 and Firefox 75.0

[feerrenrut]

@hills001 I can't reproduce this issue with the latest NVDA alpha or NVDA 2019.1.1 with Firefox 75
I tried in both focus mode and browse mode, pressing enter always activated the link.

There are a few things we can do to work out if we have differences in our configuration that maybe the reason for different behavior.

• Confirm that you get the same behavior after restarting with addons disabled.
• Try NVDA with a blank config.
• Perform the test quickly with debug logging enabled, attach it to this issue so we can see if we are doing anything differently, or perhaps there is an error in the log.

[hills001]

@feerrenrut thanks for the reply. I tried using a different computer and also wasn't able to replicate the issue. After enabling logging I noticed the following line in Firefox:
DEBUGWARNING - virtualBuffers.gecko_ia2.Gecko_ia2._activateNVDAObject
which lead me to this issue: #9886. It seems pressing nvda + 8 toggles 'Automatically set system focus to focusable elements'. When turned off the block level links are not clickable and when turned on all three of the links work correctly.

As the other issue is still open, would you recommend I close this issue?

[feerrenrut]

Yep, thanks for letting us know. I'll close this issue.

[feerrenrut]

I actually still cant reproduce this in Firefox. @hills001 Could you clarify the exact key presses you use to reproduce this? Please also clarify if you start in browse mode or focus mode.

It would be helpful to know if this reproduces in Chrome also.

[hills001]

@feerrenrut thanks for the reply, hopefully it's not a common issue, however I was able to replicate the issue in Chrome and IE11 on a couple of different machines when browse mode was enabled.

I have 'Enable browse mode on page load' and 'Automatic focus mode on focus changes' enabled and 'Automatic focus mode for caret movement' disabled in settings.

Here's the steps and key presses I used:

• Open the demo page https://nvda-firefox-block-level-links-8528.netlify.app/

• Check browse mode is enabled by pressing the H key - can hear 'Example level 1 visited link'

• Turn off 'automatically set system focus to focussable elements' by pressing nvda (insert) + 8

• Tab to any of the three links and press enter, new page does not open

• Switch to focus mode by pressing insert + space, test by pressing H key, only hear 'h'

• Tab to any of the three links and press enter, new pages open

• Re-enable 'automatically set system focus to focussable elements' by pressing insert + 8

• Switch to browse mode by pressing insert + space

• All three links correctly open when pressing enter

Let me know if you need any further info.

[feerrenrut]

Tab to any of the three links and press enter, new page does not open

I think this is intentional, though to be honest I don't know the history behind it. Perhaps @michaelDCurran or @jcsteh could fill us in?

My understanding: the virtual cursor (browse mode pointer for where you are) doesn't follow focus (moved by tab). When in browse mode, enter triggers the action for the item at the virtual cursor, in focus mode it triggers the action for the item with focus. This would explain what you are seeing. Instead if you press 'k' to move the virtual cursor to the link, the element will not get focus (because "automatically set system focus to focussable elements" is off), then pressing enter will work. I think this could be simplified by moving the virtual cursor to follow focus, though as I said I don't know the history and I may be missing important use-cases.

[jcsteh]

I think this is intentional, though to be honest I don't know the history behind it.

No, it isn't. It's a known bug when "Automatically set system focus to focusable elements" is disabled. See #9511 (comment), #10884.

My understanding: the virtual cursor (browse mode pointer for where you are) doesn't follow focus (moved by tab).

I confirmed that the browse mode cursor always follows tab, even with this setting disabled. However, for some reason, when the setting is disabled, pressing enter doesn't work in this case. I don't know why.

[feerrenrut]

I confirmed that the browse mode cursor always follows tab, even with this setting disabled.

Yep, can confirm with the example page

• In browse mode, virtual cursor on "heading level 1 Example block level links"
• Press Tab
• Press numpad 8 to confirm current virtual cursor location, hear "visited link heading level 3 Example 1"

I think this issue contains the clearest explanation of the problem, I'll reopen it. Note issue #9886 also looks related.