Re: Possible NVDA Bug - click fired at wrong element in firefox

Rich Caloggero

I still get this error in 2020.2RC1

Here is a better test program:

Usage instructions and description of the issue:

-- Rich

On 7/19/2020 3:29 PM, Bill Dengler wrote:
Can you please repeat your testing with the 2020.2 RC?
On Jul 19, 2020, at 10:54, Rich Caloggero <richcaloggero@...> wrote:

I'm using 2020.1

-- Rich

-- Rich

On 7/18/2020 10:08 PM, Bill Dengler wrote:
Which version of NVDA are you using?
On Jul 18, 2020, at 21:20, Rich Caloggero <richcaloggero@...> wrote:
Tried again with fast browsing set to off, and I get same behavior as initially described.

The reason I thought that turning fast browsing off did nothing is because it seems that if your virtual cursor is on the first character of an item (for example the link hello), then nothing happens. However, if you move to the "e" and press enter, then the link gets a click.

I guess this is definately "slow browse mode"! <smile>

-- Rich

-- Rich

On 7/18/2020 7:35 PM, Bill Dengler wrote:
Is this fixed when disabling fast browse mode (NVDA+8)? When fast browse is
off NVDA will say "automatically set focus to focusable elements on".
-----Original Message-----
From: <> On Behalf Of Rich
Sent: Saturday, 18 July 2020 16:39
Subject: [nvda-devel] Possible NVDA Bug - click fired at wrong element in
Briefly, when an element has focus, either a natively focused element, or
one made focusable via tabindex, NVDA fires a click at it when enter is
pressed. This happens even if a keydown handler is attached.
When focused on a natively focusable element like button and enter is
pressed, focus goes to the button.
When focused on a div with tabindex="0", the click is not fired at the div
with focus; instead it is sent to the first node encountered by a depth
first search of the tree, rooted at the focused item.
See more explanation and a test at this URL:
Has anyone else encountered this behavior?
-- Rich

Join to automatically receive all group messages.