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

Steps to reproduce:

1. Using a clean/new profile on Win11 Pro, using Firefox >= 100 (tried 100, 100.0.1, 101, 102)
2. Open a window and load something in a tab -- anything with sufficiently complex DOM seems to work. I used about:config
3. Attempt to scroll the DOM
4. Attempt to interact with non-DOM UI elements (browser tabs, search/location bar, toolbar buttons, etc.)

This did not require loading any remote content over the network. See Firefox profile run at: https://share.firefox.dev/3AmdQWa

Actual results:

UI responsiveness is excessively slow, to the point of not being usable. Scrolling does not happen, or only after a long delay. Opening or switching tabs or hovering over UI elements outside the DOM (browser tabs, search bar, toolbar buttons, etc.) are slow to respond to hover/clicks -- on the order of multiple seconds. Sometimes Windows indicates that the application is "not responding".

Coinciding with this, the CPU fan on my laptop spins up and task manager shows increased CPU usage from Firefox. Minimizing the window will (eventually) cause the CPU to return to idle.

Expected results:

Little to no CPU load when opening/scrolling things like about:config.
UI should remain responsive at all times.

The Bugbug bot thinks this bug should belong to the 'Core::Networking' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Reporter, I see some a11y calls in your profile. Does responsiveness improve when you set accessibility.force_disabled to 1 in about:config and restart Firefox?

@Gregory Pa(In reply to Gregory Pappas from comment #2)

Does responsiveness improve when you set accessibility.force_disabled to 1 in about:config and restart Firefox?

In fact, responsiveness improves dramatically!

There seems to be an accessibility client on your system making heavy use of UI Automation. Do you know what this might be? Are you using any assistive technology tools, enterprise SSO tools, etc.?

Can you please go to Firefox menu -> Help -> More troubleshooting information, press Copy text to clipboard, then paste the text here?

Attaching requested "More troubleshooting information".

In response to the previous questions, this is a Lenovo Thinkpad X1 Yoga G6. I don't use any accessibility features directly. It's a personal machine, with no corporate/IT management software other than what might be found in Lenovo's OEM preload.

Your question did get me looking and I'm pretty certain that I've found the culprit. At first I thought maybe this had something to do w/ Human Presence Detection, which is always active. But this model also has a built-in electronic privacy filter on the screen. In addition to manually toggling on/off with a Fn-key combo, there's an option in the Lenovo settings app to automatically engage this filter when a password input box is detected on the screen -- an obvious use of the same APIs that would be required for, say, screen readers to detect the same. I'll attach a screenshot of that setting a bit later. But I confirmed that toggling that option on triggers the issue in Firefox and turning it off (once the jankiness clears) restores normal behavior.

Based on this, you might want to mark WONTFIX however Chromium Edge (which was my fallback while trying to solve this) doesn't seem to have this issue -- at least not to a very noticeable degree -- nor did any other software I've run on the machine. So the bad user experience is a combination of whatever this Lenovo software is doing AND something special about how Firefox is interacting with these events and/or system APIs.

Attached Lenovo setting that seemed to be root cause. Problem occurred when circled checkbox was checked, does not occur when checkbox is cleared. Still, Firefox was the only noticeably affected application on the system.

Thanks so much for your efforts in tracking this down. They are extremely helpful.

It looks like you might have provided the troubleshooting info with accessibility force disabled. Would you mind re-enabling accessibility, restarting Firefox and providing the troubleshooting info again?

Does the option to automatically engage the filter work as expected in Edge? That is, I understand that it doesn't cause a performance problem, but does it correctly engage the privacy filter when a password box appears? I'm wondering whether Edge is explicitly blocking this software, which might explain why it isn't impacted.

I noticed that bug 1774285 was linked to this one. Following some instructions there, I used Edge to determine which process was the UIA client when the aforementioned Lenovo option is set. Screenshot attached.

Let me get back to you w/ the other info you requested in the meantime.

Ah. Thank you very much. If you could see this info in Edge, that would suggest Edge is not blocking it. That does raise the question of why this negatively impacts Firefox but not Edge. I'll probably need to get hold of a machine with this software installed in order to figure that out.

Technical speculation: Perhaps the UIA -> IA2 proxy makes things worse for us here? It's entirely possible that it is not particularly efficient when tree diving. In contrast, Edge has a native UIA implementation.

We could consider blocking this tool in the short term, though that would obviously mean this feature wouldn't work. Still, I think that might be better than the performance issues it is currently causing.

Updated troubleshooting info attached.

Yes, loading the password prompt from Gmail triggered the privacy filter from Edge. Notably, when I closed the tab the filter was not automatically disengaged. It disengaged when I minimized the Edge window, for what it's worth.

Again, thanks so much for your help. Hopefully, we can do a bit more investigation and find a scalable solution here.

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

Technical speculation: Perhaps the UIA -> IA2 proxy makes things worse for us here?

It does appear that way. The profile shows that the proxy queries whether an element is a control element, and for some reason, that wants to get the LiveSetting property (live region). Why should whether an element is a live region impact whether it is a control element? Anyway, in IA2, that means fetching object attributes, which isn't super fast if called on every node (3 sec in the profile)... plus the way the proxy processes the attributes seems very slow (11 sec of the profile) involving regexp parsing and other stuff. The IA2 proxy is unlikely to get any attention from Microsoft in future, so a native UIA implementation is probably the only sustainable path forward here.

We could consider blocking this tool in the short term,

Our UIA instantiator detection fails to detect this as per the support info in comment 10. Edge seems to be able to detect it, though. I reached out to Microsoft last week to ask how we can properly detect UIA clients. If that proves fruitful, blocking seems like a possible short term solution.

William, does this problem still persist for you with the "Enable this feature when typing passwords" option of Lenovo Privacy Guard enabled?
If so, would you be willing to take a look at about:support in Firefox Nightly to see if the "Accessibility instantiator" now shows up correctly?
I realise it's been a year, so I totally understand if you aren't able to check this. Thanks.

This might be less of a problem once we have a native UIA implementation, but while we're relying on the UIA -> IA2 proxy, this is quite problematic.

James, the Accessibility Instantiator still shows as: UIAUTOMATION|

Build: 118.0a1 (2023-08-07) (64-bit) 20230807215239

The privacy guard is still engaged by a password field appearing in Nightly, so if you expected it to be blocked then that's not the case. The responsiveness of Nightly is significantly better than the latest stable release. but I'll have to play with it some more to get a better feel for it. Initial impression after 2 minutes is that it's at least usable whereas stable (better now than a year ago) is still pretty janky.

(In reply to William Price from comment #15)

James, the Accessibility Instantiator still shows as: UIAUTOMATION|

That's really unfortunate. I recently added code to fix UIA client detection in Windows 11, but it seems it isn't working in this case. :( That means we can't block Privacy Guard from poking at Firefox.

Would you mind trying this try build (zip archive or installer as you prefer) and doing the same thing? I'm guessing this won't be any better, but it's worth a shot. Thanks.

Used the Zip archive. No difference as far as I can tell, sorry.

Just a thought... since you're trying to identify another process, I did a little digging and SHTCTKY.EXE is running as NT AUTHORITY\SYSTEM and not my (non-admin) user account. I had to open ProcessExplorer as Administrator to be able to determine that, as from my account (where Firefox is running) I was getting an "access denied" message when trying to get info such as the process owner.

FWIW, running Nightly as the local Administrator account didn't yield any change on the Accessibility Instantiator; it remained: UIAUTOMATION|

Thanks for all your efforts. I don't know why this isn't working. Running as the system account might have something to do with it; I'm not sure. Edge did seem to be able to detect it though, which is interesting. I guess I'll keep pondering.