NVDA problem on start with Firefox in focus

[JamaicanUser]

When I exit a copy of NVDA and/or start a new one (I've seen this in NVDA 2015.4 and NVDA 2016.1rc1) with the latest Firefox (44.0.2 on my current check) in focus, I get the following error:
ERROR - virtualBuffers.Gecko_ia2.loadBuffer (22:20:07):
Traceback (most recent call last):
File "virtualBuffers__init_.pyo", line 369, in _loadBuffer
WindowsError: [Error 1702] The binding handle is invalid
This results in only the Tab key being the only working key. No navigation quick keys, no arrow keys work. To avoid the trouble, I sometimes have to press Windows+D so Firefox's not in focus, then close up and/or start up NVDA. I'm using Windows 10 64-bit build 10586

[jcsteh]

You say "When I exit a copy of NVDA and/or start a new one". Do you mean then that this also occurs if you exit but don't start a new one? Perhaps you could provide exact steps and what happens along the way so we can get a better idea of when things occur. Also, are you starting the same copy of NVDA as you were using before or a different copy?

[JamaicanUser]

I meant if I choose to restart my copy of NVDA, or choose to exit one version of NVDA like a portable version and start an installed copy. It can also be avoided after I start NVDA I and refresh the page or go to a new page, but staying on the same page when NVDA is started causes it to behave like this.
So STR:

1. Open Firefox (latest, haven't tried with an older version)
2. Restart/start NVDA, the shortcut Ctrl+Alt+N method will ensure you're still in Firefox.
3. Bam! It only gives the title of the window, the page title and that's it, you have to press tab, switch tabs, refresh or load a new page

[jcsteh]

What version of Windows? For me, when I press control+alt+n, Windows focuses the taskbar, not the last application that had focus.

[JamaicanUser]

Turns out it only happens with the NVDA+Q method.

[jcsteh]

This has been confirmed by several users. STR:

1. Open a document in a web browser.
2. Press NVDA+q, select Restart and press enter.
   • Expected: When NVDA restarts, the document should get focus and behave normally.
   • Actual: "The binding handle is invalid" exception and browse mode doesn't work.

Technical: This occurs because there's no foreground/focus event in the browser after nvdaHelper is initialised, so nvdaHelper never gets injected (it gets injected with one of these events). The worst part about this is that alt+tabbing away and back doesn't fix this because the buffer is still treated as being alive.

I would have thought this was always an issue, but it does seem we're getting more reports of this lately. A couple of things should be investigated:

1. Can it be reproduced in earlier versions of NVDA?
2. Can it be reproduced in all versions of Windows?

[govsta1981]

I have something of a similar issue when starting Firefox for the first
time after booting up my machine. I'm running the latest Next snapshot.

When I start it, the Firefox window sits there, and no matter what I do,
browse mode doesn't start. Alt+tab doesn't do anything either.

Sometimes, I've had to restart NVDA several times before all works
right. I run Firefox Nightly. I"m running Windows 8.1 64 bit.

---

On 9/15/2016 10:02 PM, James Teh wrote:

This has been confirmed by several users. STR:

1. Open a document in a web browser.
2. Press NVDA+q, select Restart and press enter.
   • Expected: When NVDA restarts, the document should get focus
     and behave normally.
   • Actual: "The binding handle is invalid" exception and browse
     mode doesn't work.

Technical: This occurs because there's no foreground/focus event in
the browser after nvdaHelper is initialised, so nvdaHelper never gets
injected (it gets injected with one of these events). The worst part
about this is that alt+tabbing away and back doesn't fix this because
the buffer is still treated as being alive.

I would have thought this was always an issue, but it does seem we're
getting more reports of this lately. A couple of things should be
investigated:

1. Can it be reproduced in earlier versions of NVDA?
2. Can it be reproduced in all versions of Windows?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#5758 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/APFDMRL9T_sUMdLnyHjG9JHivZpHKoiAks5qqfifgaJpZM4HcuuQ.

[jcsteh]

I don't think that is related to this particular issue. What does NVDA report if you press NVDA+tab? Also, it'd be good to get a log file with log level set to debug which shows this problem.

[govsta1981]

I have my log level set to debug. Here is the info I have from it. This
is with the latest, or next to latest version of Firefox Nightly. I'm
using the latest Next snapshot as of this morning. Log text follows:

INFO - globalCommands.GlobalCommands.script_navigatorObject_devInfo
(10:46:28):
Developer info for navigator object:
name: u'Nightly Start Page - Nightly'
role: ROLE_FRAME
states: STATE_READONLY, STATE_FOCUSABLE
isFocusable: True
hasFocus: False
Python object: <NVDAObjects.IAccessible.mozilla.Mozilla object at
0x04BAAB10>
Python class mro: (<class 'NVDAObjects.IAccessible.mozilla.Mozilla'>,
<class 'NVDAObjects.IAccessible.ia2Web.Ia2Web'>, <class
'NVDAObjects.IAccessible.IAccessible'>, <class
'NVDAObjects.window.Window'>, <class 'NVDAObjects.NVDAObject'>, <class
'baseObject.ScriptableObject'>, <class 'baseObject.AutoPropertyObject'>,
<type 'object'>)
description: u''
location: (0, -8, 1366, 736)
value: None
appModule: <'firefox' (appName u'firefox', process ID 3664) at address
4baafb0>
appModule.productName: u'Nightly'
appModule.productVersion: u'51.0a1'
TextInfo: <class 'NVDAObjects.IAccessible.IA2TextTextInfo'>
windowHandle: 590306L
windowClassName: u'MozillaWindowClass'
windowControlID: 0
windowStyle: 399441920
windowThreadID: 3204
windowText: u'Nightly Start Page - Nightly'
displayText: u''
IAccessibleObject: <POINTER(IAccessible2) ptr=0x75ba40c at 4bbfda0>
IAccessibleChildID: 0
IAccessible event parameters: windowHandle=590306, objectID=-4, childID=0
IAccessible accName: u'Nightly Start Page - Nightly'
IAccessible accRole: ROLE_SYSTEM_APPLICATION
IAccessible accState: STATE_SYSTEM_MOVEABLE, STATE_SYSTEM_READONLY,
STATE_SYSTEM_FOCUSABLE, STATE_SYSTEM_SIZEABLE, STATE_SYSTEM_VALID (1441856)
IAccessible accDescription: u''
IAccessible accValue: None
IAccessible2 windowHandle: 590306
IAccessible2 uniqueID: -286274816
IAccessible2 role: IA2_ROLE_FRAME
IAccessible2 states: IA2_STATE_OPAQUE, IA2_STATE_ACTIVE (1025)
IAccessible2 attributes:
u'margin-left:0px;text-align:start;text-indent:0px;id:main-window;tag:window;margin-right:0px;margin-top:0px;margin-bottom:0px;display:block;explicit-name:true;'

---

On 9/15/2016 10:42 PM, James Teh wrote:

I don't think that is related to this particular issue. What does NVDA
report if you press NVDA+tab? Also, it'd be good to get a log file with
log level set to debug which shows this problem.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#5758 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/APFDMZYEeuMnPaL11uPMnh8OgQBmnXh0ks5qqgIZgaJpZM4HcuuQ.

[govsta1981]

When i do nvda+tab, it says "nightly start page nightly frame, read only".

---

On 9/15/2016 10:42 PM, James Teh wrote:

I don't think that is related to this particular issue. What does NVDA
report if you press NVDA+tab? Also, it'd be good to get a log file with
log level set to debug which shows this problem.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#5758 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/APFDMZYEeuMnPaL11uPMnh8OgQBmnXh0ks5qqgIZgaJpZM4HcuuQ.

[jcsteh]

Regarding starting NVDA with a browser in focus, it seems this regressed in NVDA 2015.4. It works most of the time in 2015.3, though it still fails on occasion. In contrast, it fails every time in 2015.4. That makes me think there is some timing issue at play here.

[jcsteh]

P2 because this seems to be affecting (and bothering) quite a few users.

I've tracked this down to #308 (75d5ddf). There are actually two changes that impact this:

1. We notify Ease of Access very early in our startup process (where previously we didn't support EoA at all). That does involve pressing Windows+u to start the EoA Center, so I'm guessing that messes with (or delays) focus events somehow.
2. "When NVDA has uiAccess, don't show and hide our window on startup, as this messes with the focus and causes focus to be moved out of the Start Screen in Windows 8/8.1." That "messing with the focus" also probably caused the focused application to fire focus events, which allowed us to inject.

We can't undo either of these changes now without losing functionality or breaking other things. There are a few avenues to investigate:

1. Check if the app perhaps does fire focus/foreground events when we start, but we're missing them. In that case, we might be able to juggle things in the startup process so that we don't miss them.
2. Is there some way to force the app to fire focus/foreground events so we get injected? I highly doubt it.
3. Otherwise, we'll need to find some way to inject without events.

[jcsteh]

Check if the app perhaps does fire focus/foreground events when we start, but we're missing them. In that case, we might be able to juggle things in the startup process so that we don't miss them.

As I suspected, the app unfortunately does not fire events. Ug. I tested this by:

1. Monitoring for focus/foreground with AccProbe.
2. Using the Python console to make NVDA restart in 5 seconds from a background thread. (wx.CallLater with restart causes a crash for some reason.)
3. Focusing the address bar in Firefox.
4. Waiting for NVDA to restart.

Checking AccProbe revealed that there were no additional focus and foreground events except for the ones fired when focusing Firefox in step 3.

[zahra21]

hi.
today i tested firefox 51 with nvda 2017.1 with firefox 51 and did not observe this problem in this release of nvda with firefox 51 on windows xp.
previously, i had such issues with firefox using nvda previous versions, but today i realized that its seems to be resolved for me.
i dont have newer version of windows to test.
thanks extremely for your help and God bless you all.
i pray divine infinite mercy for you.

[michaelDCurran]

Some work in progress on wip_i5758

[Adriani90]

So this is a duplicate of #7442 which has been closed.
Is this issue still reproducible after the implementation of #7535?

[ehollig]

#7535 indicates this is a partial fix for this issue. However, restarting NVDA when Firefox is in focus places my focus on the desktop and I have to alt tab back to the Firefox window to read information. I am going to close this issue for now. Please reopen if you do not agree.

[zahra21]

jcsteh,
please remove
#6505
because i discovered the cause for my problem in nvda 2016.3 and i realized it has not relationship with issues 5758 and 7269.
the problem was uninstalling openoffice.
i had openoffice and uninstalled it and i observed the issue which i mentioned in
#6505
as i said in issue 7269, i did not observe brows mode not available after restarting nvda in firefox single process mode.
(i could not test multiprocess in firefox before quantum because brows mode did not work for me at all).