User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:88.0) Gecko/20100101 Firefox/88.0

Steps to reproduce:

I installed the Firefox 89 update. I went to my GMail, all text reads "unknown". It happens no matter which website I'm on. I note that if I go to the profile manager & choose a profile first, that doesn't happen. But then, if I start that same profile automatically, it reverts to reading "unknown", so it's not a corrupted profile. I'm using Windows 10 20H2, OS build 19042.985. This happens w/NVDA, Jaws, and Narrator. So Firefox is basically unusable at this point unless I run it using profile manager first. Others are confirming this problem on the NVDA list at groups.io.

Actual results:

The text of all websites is not read, screen reader only says "unknown".

Expected results:

The website text should've been read.

The Bugbug bot thinks this bug should belong to the 'Core::Disability Access APIs' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

I haven't been able to reproduce this yet, but I received a report of this on Twitter and another via email (as well as the reporter's comment that others have flagged this issue on the NVDA users group), which suggests it's not isolated to one system.

Jamie, I surely wish I knew why this occurs w/some systems & not others, specifically, I surely wish I knew why my system is affected. I'll work w/you in whatever way you require to get this resolved.

Jackie, do you have Thunderbird installed?

Also, could you please do the following:

1. Start Firefox and ensure that it is misbehaving as you describe.
2. Press alt+h then t to open the Troubleshooting page. This should hopefully read even though other pages don't (because it's a special internal browser page).
3. Find the Accessibility heading.
4. Copy the information below that heading and paste it into your reply.

Thanks!

I've just tried various combinations of installing 89, updating from 88 to 89, etc. and I still can't reproduce this myself. :(

Jackie, on the same troubleshooting page, can you also search for the word Fission and tell me what the column next to that says?

Wanna remote in & see for yourself? Happy to allow that.

I don't use TBird, so no, it's not installed. Here's the accessibility info:
Accessibility
Activated
true
Prevent Accessibility
0
Accessible Handler Used
true
Accessibility Instantiator
NVDA,UIAUTOMATION|

Fission Windows: 0/1 Disabled by safe mode
Fission (Site Isolation) (fission.autostart): false
fission.autostart.session: false

I did go into troubleshooting mode yesterday--a lot. As in, we got very familiar. Lol.

I'm getting this on one of my PCs as well. It's not happening on my other PC, and I've been unable to reproduce it in a VM.

On the affected PC it's happening with NVDA 2020.4 and 2021.1 beta, and with Firefox 89.0 and 90.0b2.

If I back up and remove AppData\Local\Mozilla and AppData\Remote\Mozilla, effectively simulating a clean install, the screen reader works the first time Firefox is launched. When I exit and re-launch Firefox, it is able to read parts of the browser UI but not the contents of web pages or context menus.

I have been able to get it to work again, either with a clean profile or with my usual one, by removing the AppData\Local\Mozilla\Firefox folder before launching Firefox. Removing AppData\Local\Mozilla\Firefox\Profiles does not work, even though it is the only thing inside AppData\Local\Mozilla\Firefox. This workaround has to be repeated every time I restart FF.

Whoops, I meant AppData\Roaming, not AppData\Remote.

I've run a diff on the troubleshooting data when the screen reader is working and when it isn't, and the only changes are
dom.push.userAgentID: changed, which is expected behaviour on browser restart
foundDiskCacheOnInit: false -> true, which is also expected since my method for getting the screen reader to work involves deleting the disk cache
instantiator: sometimes changes from "NVDA,UIAUTOMATION|" to "NVDA,UIAUTOMATION|C:\Program Files (x86)\NVDA\nvda.exe"

I've restarted FF a couple dozen times to check about:support on both my affected and unaffected PCs. On the affected one, instantiator is inconsistent but the screen reader doesn't work properly in either case. On the unaffected PC, instantiator is consistently "NVDA,UIAUTOMATION|".

My firefox homepage is the default one, except the only thing I have on it is the web search box. I also have set FF not to be my default browser for now because of the problems I'm having.

So I did the following:

1. I turned off NVDA;
2. I activated the firefox icon on my desktop;
3. I tabbed once & activated the 'Not Now' button to prevent FF from becoming my default browser.
4. I then pressed ctrl u, ctrl+a, then ctrl c.
5. I ran notepad from the run dialog box & pressed ctrl v to paste the results. They were:
   jar:file:///C:/Program%20Files/Mozilla%20Firefox/browser/omni.ja!/chrome/browser/res/activity-stream/prerendered/activity-stream-noscripts.html — Mozilla Firefox

Not exactly what I would've expected. When I copy my homepage from the portable version, I get a FF homepage.

I also tried a nightly build, as in 91 alpha, & it worked just fine.

Thanks so much to Jackie for letting me remote in to investigate this. While I don't quite know what's going on yet, I do have more technical info at least.

1. This is definitely not related to COM registry issues. We know this because it sometimes works. If this were due to COM registry issues, content document access would be broken always for that system for all builds of Firefox.
2. Disabling AccessibleHandler does not help.
3. accChild for an accessible in a content document returns E_INVALIDARG, even if you call accChild(1) on an OuterDocAccessible.
4. Aside from content documents being broken, other Firefox windows such as the About dialog and the Library window are completely inaccessible, though the UI of full browser windows seems to work. I didn't test this myself, but comment 8 suggests that context menus are also broken, which is consistent because they have a different HWND.
5. Sending WM_GETOBJECT to these broken windows returns E_FAIL.
6. These broken windows still show up in the children of the ApplicationAccessible. If you query them via the ApplicationAccessible, everything seems to work as expected.
7. Starting Firefox with the -p option, even if you explicitly specify the profile (so the profile manager doesn't appear), seems to "fix" the problem for that session.
8. Setting browser.startup.preXulSkeletonUI to false in about:config seems to "fix" the problem, at least most of the time.

I'm wondering whether there is some startup timing issue here where we initialise something at the wrong time, don't initialise something, etc. I don't yet know what that could be, though.

[Tracking Requested - why for this release]: Browser completely unusable for some screen reader users. Including this bug, we've had 4 separate direct reports of this and apparently others are reporting it on the NVDA screen reader user group as well.

Michael, would you mind trying the following to see if it works around the issue for you?

1. Start Firefox.
2. Enter the address about:config in the address bar.
3. Accept the warning.
4. In the search box, enter the word skeleton
5. In the table below, browser.startup.preXulSkeletonUI should appear and it will have a value of true. Press the Toggle button to set it to false.
6. Restart Firefox.

Yes, disabling preXulSkeletonUI seems to work around the issue. I've restarted Firefox about 15 times and NVDA is now working consistently, and the accessibility instantiator is now always reported without the path to nvda.exe.

I should clarify regarding context menus not working that it's specifically the right-click menu of pages, including special ones like about:home and about:support, that were not being read. The right-click menu for the location bar did work, and menus from the main menu bar worked inconsistently.

Jamie, would it be possible to disable the skeleton UI if we detect that an assistive technology like NVDA is activated? That looks like a pref flip, can it be a remote setting change?

NI_ing Doung here for help to determine if SkeletonUI can indeed be the source of the issue here

I managed to reproduce this issue using NVDA 2020.4.

Notes:

• This issue is not reproducible with browser.startup.preXulSkeletonUI set to false.
• This issue goes way back to Firefox 84.0a1 (Build: 20201107100127) which is the first build that contained the above mentioned pref. Bug 1674221 made the skeleton UI pref visible to windows users. After enabling the pref (and restarting Firefox), this issue is encountered.
• I think that release users may have encountered this issue as a consequence of Bug 1705470 which flipped the pref to true (by default) on 89

Oof. This is a real doozie. I don't seem to be able to reproduce this locally with NVDA 2020.4. Emil, did this reproduce for you right away? Do you have any more details on the system you were able to see it on?

I haven't been able to reproduce this bug on my computer, but I think that we can remove the regression flags since Emil stablished it on comment #18. Is that ok?

(In reply to Pascal Chevrel:pascalc from comment #16)

Jamie, would it be possible to disable the skeleton UI if we detect that an assistive technology like NVDA is activated? That looks like a pref flip, can it be a remote setting change?

That seems reasonable. However, I don't really know how the remote settings stuff works. How does the remote settings framework make conditional decisions; what data sources can it use? We do have telemetry for accessibility being enabled, but I don't know if remote settings can use that.

I've tried this on 3 physical machines locally and 1 virtual machine and still can't reproduce it. That's making this awfully difficult to debug.

That said, if I run with a debug build with NVDA or Narrator running, I get this assertion:

Assertion failure: (((HRESULT)(mInitResult)) >= 0), at c:/Users/jamie/src/gecko2/ipc/mscom/ProcessRuntime.cpp:161
#01: mozilla::mscom::ProcessRuntime::InitInsideApartment (c:\Users\jamie\src\gecko2\ipc\mscom\ProcessRuntime.cpp:161)
#02: mozilla::mscom::ProcessRuntime::ProcessRuntime (c:\Users\jamie\src\gecko2\ipc\mscom\ProcessRuntime.cpp:134)
#03: XREMain::XRE_main (c:\Users\jamie\src\gecko2\toolkit\xre\nsAppRunner.cpp:5415)
#04: XRE_main (c:\Users\jamie\src\gecko2\toolkit\xre\nsAppRunner.cpp:5501)
#05: NS_internal_main (c:\Users\jamie\src\gecko2\browser\app\nsBrowserApp.cpp:351)
#06: wmain (c:\Users\jamie\src\gecko2\toolkit\xre\nsWindowsWMain.cpp:131)
#07: __scrt_common_main_seh (D:\a01\_work\26\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288)
#08: BaseThreadInitThunk[C:\WINDOWS\System32\KERNEL32.DLL +0x17034]
#09: RtlUserThreadStart[C:\WINDOWS\SYSTEM32\ntdll.dll +0x52651]

That means we couldn't initialise our COM security settings, which is not great. This also confirms my suspicion that something is messing with COM before we expect it to.

I originally wondered whether this might be related to the use of SHGetKnownFolderPath, since that uses CoTaskMemAlloc/Free (which are COM functions). However, if I run without NVDA or Narrator, I don't get the assertion, suggesting this isn't the issue.

What I think is happening here is that the skeleton window gets shown and Windows fires win events for that. That means clients (both in-process and out-of-process) might try to retrieve an accessible object in response. This window doesn't answer to WM_GETOBJECT, so oleacc will create a proxy for it on the client side. So, I don't understand why COM gets used here... but this is likely the entry point. The key point is that whenever a window is shown, Windows will fire win events, which might cause a11y stuff to happen, including in-process injection, calls to oleacc functions, UIAutomationCore injection/calls, etc.

Probably the only way to solve this is to make sure mscom::ProcessRuntime gets initialised before the skeleton UI appears. That would mean moving it out of XRE_main and into main() in browser/app/nsBrowserApp.cpp. I'm not sure how feasible that is or what issues it might cause. For a start, I think mscom::ProcessRuntime is in xul.dll and I'm guessing we don't want to load that yet. (My knowledge of Firefox startup is very limited.)

As to whether this is actually the cause of the problem on affected systems (or if it is, why it doesn't affect other systems), I can't say. One thought I had, though: do affected systems have touch screens (and non-affected systems not)? We know that Windows does a11y stuff internally when touch screens are involved.

Provided the system details to Doug on slack.

• For me this issue has a 100% reproducible rate.
• Also, as requested, tried to simulate 100% CPU usage using CpuStres and see the results. Unfortunately the issue still occurs.
• My affected system doesn't have touch screen.

Please let me know how can I help!

My affected system also does not have a touch screen.

(In reply to James Teh [:Jamie] from comment #22)

Probably the only way to solve this is to make sure mscom::ProcessRuntime gets initialised before the skeleton UI appears. That would mean moving it out of XRE_main and into main() in browser/app/nsBrowserApp.cpp. I'm not sure how feasible that is or what issues it might cause. For a start, I think mscom::ProcessRuntime is in xul.dll and I'm guessing we don't want to load that yet. (My knowledge of Firefox startup is very limited.)

It gets included in the launcher process, so I believe it's available. It looks plausible to me that we could bring that (and I think this) in. What you're saying sounds reasonable, but I'm having a little bit of trouble following it all the way through. Are you suggesting that just initializing mscom::ProcessRuntime might be enough for this, or do we need to specifically handle WM_GETOBJECT in the skeleton UI's early window proc?

Let me know in broad terms what you suspect may resolve this and maybe we can get a test build of this to someone who has a machine able to reproduce it?

(In reply to Doug Thayer [:dthayer] (he/him) from comment #25)

It gets included in the launcher process, so I believe it's available.

Eh. It's looking a little more annoying than I thought to get it working. I still think it's likely workable? In any case my questions still stand.

The only concern I have regarding testing for the presence of a screen reader is that sometimes those w/low vision use a screen reader intermittently. So it would seem like the optimum configuration then would be to run that test every time the browser is started. I'm not quite sure that's what yall want.

(In reply to Doug Thayer [:dthayer] (he/him) from comment #25)

What you're saying sounds reasonable, but I'm having a little bit of trouble following it all the way through. Are you suggesting that just initializing mscom::ProcessRuntime might be enough for this, or do we need to specifically handle WM_GETOBJECT in the skeleton UI's early window proc?

I'm sorry for the lack of clarity. Honestly, this is mostly guesswork (albeit a little educated); I really don't know whether any of this is going to fix anything. I just don't have enough solid data to make a good judgement. :( That disclaimer aside:

1. I'm hoping initialising mscom::ProcessRuntime before the skeleton is shown will fix the issue.
2. However, it might also be worth creating a build which does this and also returns E_FAIL for WM_GETOBJECT in PreXULSkeletonUIProc. This might stop oleacc/UIAutomationCore from proceeding with certain things, though it didn't prevent the assertion when I tested it here. I'd prefer this in a separate try build so we can validate whether the E_FAIL change is necessary, as returning a COM error code like this from WM_GETOBJECT isn't really documented, so I'd prefer not to land that unless it is actually necessary.

Doug, Jamie, should we set browser.startup.preXulSkeletonUI to false in a dot release until a more persistent solution is found to this problem?

I can't speak as to the importance of this feature for (non-a11y) user retention, etc. However, it is very severe for a11y users. It's currently unclear how many users are impacted, but I continue to see new reports of this daily.

Do we need a dot release or can we remote flip (without the a11y check, since I don't think we can check that)?

I marked this bug as blocking for 89 as this is in my opinion a driver to do a dot release rapidly.
If the only short term solution to make screenreaders work again reliably in Firefox is to disable the UI skeleton, then I think that this is also a product decision. Romain do you know who would own this decision on the product side?

If we can have a solution that only impacts users with a client connected to the A11Y API (i.e disable skeleton UI under this condition, even if a client was ever connected) it seems preferable though time is of the essence.
Jamie can probably confirm regarding clients impacted, my understanding is that this is around 100k MAU though clearly very high impact.

We have 3 options it seems:
1 Disable skeleton UI for all (no dev needed, just a pref flip)
2 Disable skeleton UI for A11Y users
3 Fix skeleton UI for A11Y users

Do we have rough estimates for "2" and "3" in terms of delivering a patch with a goal to deliver a dot release early next week?

I am putting a build through try right now to see if we can test James's proposed fix. We'll need someone who can reproduce this to check the fix, of course. If it's as simple as what James proposes, I think landing this by early next week is doable. However I'm not so confident on the safety of it. I would prefer dot releasing either option 1 or option 2, and then letting 3 ride the trains.

Emil (or anyone who is able to reproduce this), could you try reproducing on these builds?

Note, for anyone attempting to reproduce. It should in theory only reproduce on your second run of the build, since the skeleton UI should not show on the first run. So make sure to run firefox.exe, close the window that opens, and then run firefox.exe again.

Should be broken (validate that the problem is reproducible on opt try builds): https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/IgXrXVoIQmCjXoTCWcuGrQ/runs/0/artifacts/public/build/target.zip
Should be fixed (hopefully, though it's entirely possible that this fix does nothing): https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/f-DsVhxURDumWy7ydE1xnw/runs/1/artifacts/public/build/target.zip

As expected, the following try build is broken: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/IgXrXVoIQmCjXoTCWcuGrQ/runs/0/artifacts/public/build/target.zip

The second try build (https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/f-DsVhxURDumWy7ydE1xnw/runs/1/artifacts/public/build/target.zip) seems to fix this issue partially. NVDA doesn't read "unknown" on startup (when skeleton UI is displayed) & the context menu options are being successfully read by NVDA. However, page content still remains affected (tried to navigate through different buttons,links,etc inside a wikipedia article but NVDA still reads "unknown" for them).

It just occurred to me that trying to disable skeleton just for a11y users is going to be a lot harder than I thought. Because skeleton runs so early, a11y isn't even initialised yet (and a client won't have poked us yet because no UI has appeared). And once the window appears, it's too late to mitigate.

That means to do this in an a11y specific way, we're going to have to save the state of a11y from the last session and use this for the skeleton on next start. But that's far from ideal. It doesn't cover the case where a user is a part time assistive tech user. If they start Firefox without their AT, close Firefox, then later start their AT and start Firefox, things will break.

Emil, can you please confirm that web content a11y works as expected with NVDA in a normal nightly build? I just want to be extra sure you're not seeing another bug that occasionally occurs on some systems.

Confirmed, i can not reproduce the bug on the latest nightly, only on the test builds as Emil.

Interesting....Web Content a11y doesn't work as expected in a normal nightly build 91.0a1 (BuildId:20210608091819) for me. It just reads unknown for every page element as long as skeleton UI is enabled.

But this behavior (on normal builds) was also reported by others and I've also encountered this when I started to investigate this issue.

(In reply to Jackie McBride from comment #0)

I installed the Firefox 89 update. I went to my GMail, all text reads "unknown". It happens no matter which website I'm on.

Lukáš, you are not able to reproduce the web content problem on the latest nightly build? did you open the latest nightly build via the profile manager? (For double checking: in order to successfully reproduce this issue you have to launch it without the profile manager..also, maybe try to close Firefox & open it again after the first try).

Sorry, Emil; my bad. I should have asked whether content a11y definitely works for you in a normal nightly with skeleton disabled.

Doug, I have a hypothesis. If ProcessRuntime is being compiled into mozglue, I'm wondering whether that means MOZILLA_INTERNAL_API won't be defined. In that case, I think ProcessRuntime doesn't register certain things needed for e10s a11y to work. I'll verify this later today.

(In reply to James Teh [:Jamie] from comment #42)

If ProcessRuntime is being compiled into mozglue, I'm wondering whether that means MOZILLA_INTERNAL_API won't be defined. In that case, I think ProcessRuntime doesn't register certain things needed for e10s a11y to work.

I confirmed my suspicion, though it still doesn't reproduce the problem for me. When ProcessRuntime is initialised from mozglue, this code path doesn't run. That means a11y stuff needed for e10s (on some systems?) doesn't get registered.

I'm not sure how we can fix this:

1. We probably don't want that code running in other processes (e.g. the launcher). Are there checks we can use to only run this in the browser parent process?
2. We need to call an a11y utility function to get the resource id for the manifest. I guess we could move that function into mozglue.
3. The manifests are embedded in xul.dll. We'd have to move those to mozglue too.

Okay. I think I've figured out why this breaks on some systems and not others.

MSAA (oleacc) can be handled by one of two COM proxy dlls:

1. oleacc.dll itself, clsid {03022430-ABC4-11D0-BDE2-00AA001A1953}.
2. The universal typelib marshaler, clsid {00020424-0000-0000-C000-000000000046}.

Which is registered depends on a number of factors, including 32/64 bit, Windows version, probably whether the system was updated from an earlier version of Windows... and just to make things more fun, app installers that decide to screw with the registry (even things like Adobe Reader).

Firefox uses manifests to specify a marshaler. It chooses oleacc.dll for 64 bit builds. For 32 bit builds, it chooses based on the version of Windows and what's registered on the system. Even if Firefox's choice is not the marshaler used by the rest of the system, it doesn't seem to matter. What does matter is that Firefox processes are consistent in which marshaler they use. And here's where we hit the problem.

1. When the skeleton UI appears, COM gets initialised in the parent process (but not by us); see comment 22 for discussion.
2. That means we can't initialise COM correctly, including setting up the marshaler we want (via the manifest).
3. On systems where the marshaler registered on the system is the same as the marshaler Firefox uses, everything is fine.
4. However, on systems where those differ (e.g. on 64 bit systems which use the typelib marshaler), we end up with one marshaler in the content process (the one Firefox chooses, since we explicitly initialise COM there) and a different marshaler in the parent process (the system chosen marshaler, since we failed to explicitly init COM there).
5. Everything blows up.

NVDA has a COM registration fixing tool which is supposed to correct the system marshaler, but this doesn't seem to be working, which explains why users who have reported they tried that tool are still seeing this problem.

So, to reliably reproduce this problem with a 64 bit build of Firefox and NVDA:

1. Exit Firefox.
2. Press Windows+r, type regedit, press enter.
3. In the address bar, enter:
   Computer\HKEY_CLASSES_ROOT\Interface\{618736E0-3C3D-11CF-810C-00AA00389B71}\ProxyStubClsid32
4. Change the (Default) value to:
   {00020424-0000-0000-C000-000000000046}
5. Restart NVDA.
6. Start Firefox so that the skeleton appears.
7. Observe breakage.

If you run without the skeleton, everything works as expected.

Putting all of this together, here's what I think needs to be done to fix this:

1. Move a11y::Compatibility::GetActCtxResourceId and supporting functions into mozglue.
2. Move accessible/ipc/win/IAccessible*.manifest into mozglue. This will also require us to move the manifests out of xulrunner.rc and into a new .rc file for mozglue.
3. Change mscom::ProcessRuntime to really differentiate between the parent and launcher processes instead of treating them the same.
4. Change mscom::ProcessRuntime so that the decision to initialise ActivationContext isn't based on MOZILLA_INTERNAL_API. Instead, it should only run if in the parent process (ProcessRuntime::GeckoBrowserParent). We also need to make sure that the ACCESSIBILITY define exists in mozglue; I'm not sure if it does or not.

Note that aklotz is tweaking ProcessRuntime's constructors over in bug 1707954. We should think about how these two things cross over.

That's some fantastic detective work Jamie. My affected PC has the Universal Typelib Marshaler CLSID registered for IAccessible, and my unaffected one has the oleacc CLSID.

I've also been able to figure out using a VM that the marshaler was changed for me by the 64-bit Acrobat Reader installer. The 32-bit Reader installer only changes the CLSID for IAccessible under WOW6432Node so x64 apps like Firefox weren't affected.

Jamie, are the steps you are proposing something upliftable to beta and release? It sounds more like ground work that would ride the trains when ready to me so I am wondering if we have an option on the table for a fix we could ship for our users on the release channel and users currently on the beta channel.

I agree what I'm proposing would be too risky to uplift. Unfortunately, it's the only "fix" I can fathom for the issue. Unless someone has another idea, the only option I see for 89 is to disable the skeleton UI for all users. I don't think disabling it for a11y users only is feasible as explained in comment 37.

Romain, can you confirm from the product side that we should disable the skeleton UI for all users on beta 90 and release 89 since this bug is a P1/S1? Thanks

(In reply to James Teh [:Jamie] from comment #44)

Firefox uses manifests to specify a marshaler. It chooses oleacc.dll for 64 bit builds. For 32 bit builds, it chooses based on the version of Windows and what's registered on the system. Even if Firefox's choice is not the marshaler used by the rest of the system, it doesn't seem to matter. What does matter is that Firefox processes are consistent in which marshaler they use. And here's where we hit the problem.

I've spent a little more time playing around with VMs and have only been able to duplicate this bug with the 64-bit version of Firefox. On either x86 or x64 versions of Windows 10 21H1, the 32-bit Firefox seems to work correctly with NVDA regardless of which marshaler is registered.

(In reply to Michael Burton from comment #50)

I've spent a little more time playing around with VMs and have only been able to duplicate this bug with the 64-bit version of Firefox. On either x86 or x64 versions of Windows 10 21H1, the 32-bit Firefox seems to work correctly with NVDA regardless of which marshaler is registered.

Yeah, that's just from bug 1710691.

89 fixed by backout of bug bug 1705470
https://hg.mozilla.org/releases/mozilla-release/rev/6d2a8e90cac5c94ab4ec82d59b65c3b78aed4812

Thanks Jamie. Putting the skeleton in the closet (setting skeleton ui to false) worked around the issue on my two machines.

I am going to say something, though. Although setting the option to false helps, there is something really wrong w/the interaction between FF & NVDA now, as in, periodically my NVDA key stops working & I have to reload it. Links sometimes also act weirdly, as in when enter is pressed on 1, it doesn't react, sometimes I can use object navigation to get that to happen. That happened occasionally in earlier versions as well, but it's becoming quite prominent now.

Hi Jackie. Thanks for your continued support and for your patience as we sort this out. While I'm not ruling out some new problem, the other issues you're reporting are very unlikely to be related to this one. Firefox has no control at all over the NVDA key, so I'd suggest reporting that to the NVDA project. As for not being able to activate links, I'd encourage you to file a separate bug about this one if you can pin down a site or scenario where this happens with at least some degreeof reliability. Thanks again.

Well, I know what you're saying, Jamie, except that my NVDA key quits only when I'm in FF. It does not do it anywhere else.

I can confirm that this issue is fixed (via the backout of Bug 1705470) on Firefox 89.0.1 (BuildId:20210614221319).

Regressing bug backed out of beta for 90:
https://hg.mozilla.org/releases/mozilla-beta/rev/cefc1f54bc2a

Backed out changeset 11d1710e481f (bug 1714212) for Browser-chrome failures in toolkit/xre/test/browser_checkdllblockliststate.js. CLOSED TREE

Log:
https://treeherder.mozilla.org/logviewer?job_id=343920519&repo=autoland&lineNumber=7670

Push with failures:
https://treeherder.mozilla.org/jobs?repo=autoland&group_state=expanded&revision=11d1710e481f13102757d194524392f9d8930fe9

Backout:
https://hg.mozilla.org/integration/autoland/rev/0ebc33eb14368a96f0edf8f38094dce9f2baa709

See the comment in Ole32Glue.h for an explanation of what problem this is
trying to solve. We don't necessarily need to export these functions - we
could also just #define them to the real symbols if we're in xul or winlauncher.
However, this felt cleaner somehow? Open to objections.

Depends on D117663

Fixing up some bug fields.

Backed out for SM bustages on NativeNt.h

Backout link: https://hg.mozilla.org/integration/autoland/rev/9f440f63e50958845a6aaee83d4e54372abbccc9
Log link: https://treeherder.mozilla.org/logviewer?job_id=344614287&repo=autoland&lineNumber=1439

https://hg.mozilla.org/mozilla-central/rev/365ef0c671a4

Since the code fix wasn't backported, and the issue would still affect Nightly 89, Nightly 90, and anyone who had the preference enabled, I think disabled is the more appropriate status.