Firefox doesn't read edit field correctly

[tspivey]

Steps to reproduce:

1. Go to https://github.com/nvaccess/nvda/issues/new
2. Press control+home
3. Press e

Actual behavior:

I hear main landmark d button

Expected behavior:

I should hear main landmark Title edit required invalid entry

System configuration:

NVDA Installed/portable/running from source:

Installed

NVDA version:

Version: alpha-16149,e713f614

Windows version:

Version 1809 (OS Build 17763.1)

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

Firefox 61.0.2

Other information about your system:

Other questions:

Does the issue still occur after restarting your PC?

Yes

Have you tried any other versions of NVDA?

No

[jcsteh]

This occurs because the offsets of the edit field in the buffer change after the field is focused, which means the offsets NVDA originally retrieved are now incorrect. Thus, when it reports the field, it reports the wrong information. I think we have an NVDA issue for this already somewhere, but I can't find it.

As to why the offsets change, it seems that the Skip to content link loses its spaces as soon as it loses focus. I guess that must be because it goes off-screen and there must be some CSS weirdness which causes Firefox layout to do this. However, this could (and does) happen for many different reasons. Here's a simple test case:
data:text/html,<button onblur="this.textContent = 'Short';">Longer</button><input type="text" aria-label="Input"><button>After</button>
if you press control+home, then e, you'll hear "A button", but you should hear "Input edit".

This is going to be tricky to fix because VirtualBufferQuickNavItem creates a TextInfo and passes it to the TextInfoQuickNavitem constructor. TextInfoQuickNavItem uses that thereafter. Two approaches:

1. Somehow re-fetch the TextInfo from the buffer node before TextInfoQuickNavItem.report is called.
2. Queue the setFocus call (called by _set_selection which is in turn called by TextInfoQuickNavItem.moveTo) so it happens after TextInfoQuickNavitem.report is called. That shouldn't be too hard, since _set_selection does get passed REASON_QUICKNAV, but I'm not sure if there are any problematic side effects of this.

CC @michaelDCurran Curran.

[tspivey]

I'm also running into this constantly in Chrome, mostly while playing incremental games. These are pages with a lot of updates.

[Adriani90]

cc: @LeonarddeR, @mltony this is related to all issues that are targeted by PR #9511. Disabling automatic set system focus on focusable elements solves this issue. Is that PR going to remain a sustainable option for users? Or are there any thoughts about alternative approaches?

[jcsteh]

Disabling automatic set system focus on focusable elements solves this issue. Is that PR going to remain a sustainable option for users? Or are there any thoughts about alternative approaches?

It's worth noting that disabling automatic setting of system focus prevents this issue from occurring, but it doesn't really "fix" it. Of course, if we do that, we may choose to close this as won't fix, since it effectively solves it for users. That said, possible solutions for this specific issue are outlined in my comment above.