Errors when focussing embedded Gecko browser in .Net application

[jscholes]

I'm trialing the use of an embedded Gecko browser in a .Net application. When I attempt to focus the browser control, NVDA generates many of the errors seen in the log fragment below.

Windows 7 Pro X64, latest Next snapshot, UIA enabled. The application executable and Xulrunner DLLs are 32-bit.

Input: kb(laptop):enter
IO - speech.speak (18:05:45):
Speaking [u'Gecko Test']
IO - speech.speak (18:05:45):
Speaking [u'Exit  button  Alt+x']
IO - inputCore.InputManager.executeGesture (18:05:49):
Input: kb(laptop):tab
ERROR - core.Notify (18:05:49):
errors in this core pump cycle
Traceback (most recent call last):
  File "core.pyc", line 351, in Notify
  File "IAccessibleHandler.pyc", line 887, in pumpAll
  File "IAccessibleHandler.pyc", line 654, in processFocusWinEvent
  File "IAccessibleHandler.pyc", line 529, in winEventToNVDAEvent
  File "NVDAObjects\IAccessible\__init__.pyc", line 43, in getNVDAObjectFromEvent
  File "NVDAObjects\__init__.pyc", line 76, in __call__
  File "NVDAObjects\IAccessible\__init__.pyc", line 449, in findOverlayClasses
  File "NVDAObjects\IAccessible\mozilla.pyc", line 229, in findExtraOverlayClasses
  File "NVDAObjects\IAccessible\mozilla.pyc", line 124, in getGeckoVersion
AttributeError: 'NoneType' object has no attribute 'split'

[LeonarddeR]

What Gecko version is this control based on? Seems like NVDA is unable to retrieve the version of it. May be we should use a default assumption in this case.

[jscholes]

What Gecko version is this control based on?

I used XULRunner 33.0 (built on 2014-10-11 according to the included platform.ini).  The GeckoFX .Net bindings seem to have been updated recently, but I haven't looked at this since filing the original ticket.

[Adriani90]

@jscholes is this issue still reproducible?

[jscholes]

The issue still occurs with the test application I put together in 2016, so no changes to NVDA have fixed it. That application is using an older version of Chromium though, and I don't currently have an appropriate development environment up and running to test this with a newer one.

[jscholes]

Apologies, I'm getting my issue reports mixed up. This is an application using an embedded Gecko browser control via XULRunner, not Chromium. As far as I know XULRunner has been deprecated, and Chromium is now accessible enough that it should probably be used as the embedded browser control of choice anyway.

[ehollig]

This is an application using an embedded Gecko browser control via XULRunner, not Chromium. As far as I know XULRunner has been deprecated, and Chromium is now accessible enough that it should probably be used as the embedded browser control of choice anyway.

Are you suggesting that this issue should be closed as a newer alternative of an embedded browser is available and should be used instead?

[jscholes]

Are you suggesting that this issue should be closed as a newer alternative of an embedded browser is available and should be used instead?

Yes, that's fine. I originally filed the issue hoping to get some feedback from people more knowledgeable than myself about Gecko as to what the problem might be, but that didn't happen.

[Adriani90]

I suggest to let this issue open for a while, maybe @LeonarddeR can write some thoughts. If I am right @LeonarddeR was involved in a gecko specific Topic. Discussing about such Problems is very important in my view because it might help in solving future Problems.

[jscholes]

My feeling is that the issue I experienced was specific to the .Net Framework bindings for the Gecko browser component, possibly even limited only to the WinForms integration but I didn't try WPF. I have, however, used libraries like wxWebConnect in the past and didn't experience this issue. If there are any WinForms applications still using a Gecko browser component which exhibit this behaviour, I would leave it up to users to file a separate, app-specific issue personally. Especially given the deprecated status of Gecko and XulRunner.

[Adriani90]

I agree with @jscholes in this regard. Closing it in favor of possible app specific issues reported by users. @LeonarddeR if you have any further suggestions, we can reopen it.