Inconsistencies in Tabbing at the start and end of a document in web browsers

[bhavyashah]

Steps to reproduce:

1 Open any webpage in your web browser.
2 Press Ctrl+Home, and then Shift+Tab once or twice.
3 Navigate back to the web document.
4 Press Ctrl+End, and then press Tab once or twice.

Actual behavior:

Varies with browser and webpage. On this ticket composition (New Issue) page in Firefox, Ctrl+Home and then Shift+Tab moves me to the Composition toolbar and the Write tab. On m.facebook.com in Firefox, Ctrl+Home then Shift+Tab moves me to some random links in the middle of the page. Shift+Tab sometimes moved me to the Bookmarks toolbar in Firefox even. On google.com in Brave, Ctrl+End and then Tab takes me to "View Site Information menu button." On en.wikipedia.org in Brave, Ctrl+End then Tab takes me to "Wikipedia link" at the top of the page.

Expected behavior:

One of the following:

• Tab at the end of a page should move to the first control in Tab order at the top, and Shift+Tab at the top of the page should move to the same but at the bottom. I would argue against this because NVDA has intentionally excluded a wrapping to top/bottom feature and such a behaviour would conflict with that active choice.
• Tab at the top and Shift+Tab at the bottom should move out of the document and to some component of the browser interface.

Note

• The crucial bit is that the behaviour should be consistent across all webpages and both at the top and bottom of the page in a given browser. It would be preferable, but not essential, if this consistent behaviour was uniform across different browsers too.

Impact

• Usually, the reason why I am trying to Tab and Shift+Tab out of the web document is because I want to reach buttons like Allow, Don't Allow, Restore, Save, etc. that show up when a site asks for permission, or the browser offers to restore pages, or a login can be saved, etc. I would admit that I am able to access those through alternative means such as pressing F6 and then Tabbing around, or just pressing the shortcuts of those buttons which NVDA does report when that dialog appears. This buggy behaviour is more confusing and inconsistent than anything else.

System configulration

NVDA installed/portable/running from source:

Installed

NVDA version:

2020.2 Beta 1

Windows version:

8.1

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

Firefox 78.0.1, Brave 83.1.10.97

Other information about your system:

Other questions

Does the issue still occur after restarting your computer?

Yes

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

No

If addons are disabled, is your problem still occuring?

Yes

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

No

[Adriani90]

cc: @feerrenrut what do you think?

[Adriani90]

Could also be related to #6687 and #3575.

[Adriani90]

Ok after a discussion on another issue, Jamie pointed out this is expected behavior.

1. The system focus does not sync automatically with virtual cursor, so when you press ctrl+home and ctrl+end or ctrl+ page up and down, the virtual cursor moves but not the system focus.
2. When you press tab or shift+tab, the tab key is passed to the browser and the system focus is moved to a focussable element, but this is independent of the position of your virtual cursor in browse mode.

So if you want to reach the expected result:

1. Press ctrl+home
2. Press nvda+space bar to sync system focus to virtual cursor
3. Press shift+tab
4. Same procedure with ctrl+end and tab

In that case, shift+tab at the top and Tab at the bottom moves out of the document and to some component of the browser interface as expected.

Closing as works for me.

[jcsteh]

2. When you press tab or shift+tab, the tab key is passed to the browser and the system focus is moved to a focussable element, but this is independent of the position of your virtual cursor in browse mode.

This doesn't impact the assessment of this bug, but for absolute clarity, this statement isn't quite correct:

1. If your browse mode cursor is inside the element with focus, tab and shift+tab are passed through to the browser, since browse mode and focus are in sync and the browser has the greatest chance of accuracy.
2. If the browse mode cursor isn't inside the focused element, tab and shift+tab will attempt to move focus relative to the browse mode cursor. For tab, NVDA will search for the next focusable element after the browse mode cursor and focus that if found. Vice versa for shift+tab. We do this because the browse mode cursor may be a long way away from the focus, so tab and shift+tab should be relative to the user's point of interest (the browse mode cursor).
3. If the browse mode cursor isn't inside the focused element but NVDA can't find a focusable element after or before the cursor (depending on whether this is tab or shift+tab), tab/shift+tab is passed through to the browser. This is why moving the browse mode cursor to the bottom of the document and pressing tab, or moving the browse mode cursor to the top of the document and pressing shift+tab, behaves as if there were no awareness of browse mode: there is no focusable element in that direction.