Firefox native selection mode unsupported on msix version

[LeonarddeR]

Brief summary

Native selection mode is unavailable in FireFox, at least when using the MSIX package.

Steps to reproduce

1. Install FireFox with Winget: winget install Mozilla.Firefox.MSIX
2. Try to enable native app selection mode

Actual behavior

Native selection mode unsupported in this document

Expected behavior

Native selection mode enabled

NVDA logs, crash dumps and other attachments

updateAppSelection failed
Traceback (most recent call last):
  File "virtualBuffers\gecko_ia2.pyc", line 741, in clearAppSelection
  File "comtypes\_post_coinit\unknwn.pyc", line 404, in QueryInterface
  File "monkeyPatches\comtypesMonkeyPatches.pyc", line 33, in __call__
_ctypes.COMError: (-2147467262, 'No such interface supported', (None, None, None, 0, None))

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "browseMode.pyc", line 2649, in script_toggleNativeAppSelectionMode
  File "virtualBuffers\gecko_ia2.pyc", line 745, in clearAppSelection
NotImplementedError

NVDA type

installed copy

NVDA version

alpha-53648,b5c8569b (2026.1.0.53648)

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

Yes, also occurs on 2025.3.x

Windows version

Windows 11 25H2

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

Firefox 145.0.1 MSIX build. Not tested non-MSIX builds yet

Other information about your system

No response

Does the issue still occur after restarting your computer?

I have restarted my computer and the issue still occurs

If NVDA add-ons are disabled, is your problem still occurring?

I have restarted NVDA with add-ons disabled and the issue still occurs

Does the issue still occur after you run the COM Registration Fixing Tool in NVDA's tools menu?

I have run the COM Registration Fixing Tool and the issue still occurs

[LeonarddeR]

Just tried on the normal version of Firefox and there native selection mode works like a charm. @jcsteh I assume this is something I should report at Mozilla, but I'm not sure how. I guess this has to do with certain IAccessible2 interfaces not exposed correctly, notably the IAccessibleTextSelectionContainer interface? But is this something for the a11y or the msix folks?

[jcsteh]

It'll end up being me specifically that needs to deal with this. :)

These days, Firefox exposes IA2 interfaces without any COM proxy or marshaling stuff, just like other apps do. This means that as in other apps, NVDA relies on registering its own COM proxy in-process in order to facilitate cross-process COM.

That said, there seems to be something weird going on with this particular interface. Even in a normal (non-MSIX) Firefox install, I often see a bug where IAccessibleTextSelectionContainer just stops working and returns E_NOINTERFACE, as if the interface just doesn't exist. This is a different error to the one we see for IAccessibleTable and IAccessibleHyperlink and is not fixed by restarting NVDA.

I'll look into it more closely when I get some time. Perhaps this permanent failure in MSIX (rather than the occasional failure in non-MSIX) might actually make this problem easier to track down.

[bhavyashah]

Just had this same issue in Google Chrome version 142.0.7444.176 with NVDA 2025.3 as well: IO - inputCore.InputManager.executeGesture (13:58:01.653) - winInputHook (24624): Input: kb(laptop):NVDA+shift+f10 DEBUGWARNING - browseMode.BrowseModeDocumentTreeInterceptor.script_toggleNativeAppSelectionMode (13:58:01.658) - MainThread (27440): updateAppSelection failed Traceback (most recent call last): File "virtualBuffers\gecko_ia2.pyc", line 741, in clearAppSelection File "comtypes_post_coinit\unknwn.pyc", line 404, in QueryInterface File "monkeyPatches\comtypesMonkeyPatches.pyc", line 33, in call _ctypes.COMError: (-2147467262, 'No such interface supported', (None, None, None, 0, None))

The above exception was the direct cause of the following exception:

Traceback (most recent call last): File "browseMode.pyc", line 2649, in script_toggleNativeAppSelectionMode File "virtualBuffers\gecko_ia2.pyc", line 745, in clearAppSelection NotImplementedError IO - speech.speech.speak (13:58:01.659) - MainThread (27440): Speaking ['Native selection mode unsupported in this document']

[jcsteh]

I'm documenting an untested hypothesis here so I don't forget. This only applies to the permanent Firefox MSIX issue, not the intermittent issue in non-MSIX Firefox and Chrome.

1. NVDA is responsible for registering the IAccessible2 COM proxy in-process.
2. We know that NVDA can inject into MSIX apps. But MSIX apps have a virtualised file system. Is it possible that nvdaHelperRemote can't load the COM proxy dlls in this case?
3. In that case, NVDA wouldn't register the IAccessible2 COM proxy.
4. Windows is bundled with an IAccessible2 COM proxy, but it's old and does not include IAccessibleTextSelectionContainer. That means that everything else would work fine, but IAccessibleTextSelectionContainer would not, which is what we're seeing here.

[LeonarddeR]

The following is in the log with the msix build:

Thread 12256, build\x86_64\remote\ia2Support.cpp, IA2Support_inProcess_initialize, 177:
Not installing IA2 support as  process is suspendable

[jcsteh]

Ah, that tracks. For suspendable apps, nvdaHelper refuses to initialise IA2 support in-process, including loading COM proxies, because it can cause a deadlock in nvdaHelper when the process resumes. See https://github.com/nvaccess/nvda/issues/5417#issuecomment-155343964. Unfortunately, it assumes that any app that returns something from GetCurrentApplicationUserModelId is suspendable. That was true when all Windows Store apps were UWP apps, but it isn't true now that we have MSIX, which can also package Win32 apps. I'm not sure how to specifically detect whether an app is suspendable, but that's the fix.

[jcsteh]

This discussion thread might be useful, though how to detect this still isn't clear to me. Some comments there suggest that an app container process might imply that the process is suspendable... but you can also use an app container for other purposes and I suspect those might not be suspendable. RuntimeBehavior=windowsApp might be a better indicator, but I don't know if we can check for that.