1910519 - Win11 Firefox Hangs when selecting too many texts or elements for seconds if not minutes

Status: RESOLVED DUPLICATE of bug 1907834

(Core :: Disability Access APIs, defect)

Description

[majoranaoedipus]

Attachment: Screenshot_20240730_084501.png

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0

Steps to reproduce:

Let me put the result from the Firefox profiler first:
https://share.firefox.dev/3yi6pkk

The results is created in the following steps:

C:\'Program Files'\'Mozilla Firefox'\firefox.exe --ProfileManager --no-remote

Create new profile

Prepare the profiler and open https://en.wikipedia.org/wiki/Unicode

Start the profiler

Ctrl + A

Click the profiler icon to stop profiling

Wait ~30s, the Firefox recovers from `no responds'

Exports the report

Actual results:

As you can see in the report https://share.firefox.dev/3yi6pkk , I had 35.6s of `jank' after selecting the whole page.

More Description of the issue:

I have been troubled by this for several months: when I select some elements on some website, even those plain HTML sites, the browser hangs (freezes? sorry for my poor English to find the correct word.) for seconds, if not tens of seconds, or even minutes.

The problems seems a little bit random, but today I finally get in consistently trigered.

Other websites that I find problematic includes e.g. https://www.w3.org/TR/clreq/ (when writing this post, I find clicking the bottun to switch the language also makes the browser hang), but I can not always reproduce the issue consistently in other cases.

More details:

This issue last for many versions of Firefox and updates of Windows.

Basically only happens in selecting texts or other elements on a webpage. The more you select, the longer the browser hangs; and the hang time does not grow linearly.

I have tried ``refresh Firefox'' in about:support with no luck; I tried uninstalling Firefox and reinstalling, no help.

No such performance issue in other browser is encountered, e.g. in Microsoft Edge.

The browser won't restore normal until the affected tab is closed.

Addons are not the cause (it can be reproduced in a new profile). Also, it does not matter how many tabs I have opened.

The system task manager reports no abnormal CPU usage or memory usage when hanging happens.

I have a desktop running Arch Linux + KDE desktop, no such issue observed.

An employee from Mozilla said that he cannot reproduce (https://www.reddit.com/r/firefox/comments/1eeuut2/comment/lfhg83x/ ), so the profiler report is the only clue I suppose.

Expected results:

Highlightingt texts should be instant

Comment 1

[majoranaoedipus]

Sorry for not including the enviroment info:

Environment:

• Windows 11 23H2

• 12th Gen Intel(R) Core(TM) i5-1235U 1.30 GHz (I think this is quite decent, right?)

• 16 GB of memory

Comment 2

[Justin Link]

That profile seems like it should be pretty useful. The immediate cause of the jank (completely unresponsive UI) is that 35s are being spent in IA2ProxyTextRange::GetSelectionRange(). I didn't know what that was and it didn't seem to be part of the Firefox codebase so I did a little looking around it seems to be something internal to uiautomationcore.dll, which is part of Windows UI Automation. I am not very familiar with that but, from what I can tell, that technology is often used for assistive technology like a screen reader. (I'm basing most of that on what I found here). Can you confirm if you are using a screen reader or something else that would use the UI automation?

Comment 3

[James Teh [:Jamie]]

Can you please provide the information from the Accessibility section of about:support?

This is likely a duplicate of bug 1907834.

Comment 4

[Mayank Bansal]

The time is all spent in a11y code and probably a dupe of bug 1876192.

@ majoranaoedipus: Can you do these please:

1. Type about:support in your browser and copy-paste its contents to this bug
2. Type about:config in your browser, and set accessibility.force_disabled =1 . Then restart the browser and try to reproduce this issue. Does the issue get fixed for you?

Comment 5

[James Teh [:Jamie]]

(In reply to Mayank Bansal from comment #4)

The time is all spent in a11y code and probably a dupe of bug 1876192.

Mid-air collision, but I do think this is more likely bug 1907834. They are related, but are likely caused by a different a11y client.

Comment 6

[Justin Link]

A few technical notes from looking at the profile:

• Looking at the stack chart, I see MsaaProxy() makes a call to mozilla::a11y::ia2AccessibleText::get_nSelections() (via AccUtils::get_nSelections()) and then spends the rest of its time (> 35s) in IA2ProxyTextRange::GetSelectionRange() which calls IA2ProxyTextRange::GetSelectionRangeEndpoints() followed by IA2ProxyTextRange::Endpoint::Normalize() many times. Without knowing any of the details of how those functions work, one possible explanation would be that get_nSelections() is reporting that there are a large number of selections and then IA2ProxyTextRange iterates over ... something ... many many times. The problem here seems to me to come foremost from the quantity of calls into our code rather than that the calls themselves are taking a long time.
• The page that I cited above says 'While a number of UI frameworks on Windows do implement the UIA provider API, there are some cases where this does not happen. For example, if the provider process is using an older type of UI where the UIA provider API has not been implemented, yet the old MSAA data is available, UIA itself will convert the MSAA data available into the equivalent UIA data. This is done through UIA’s “MSAA Proxy”.' I do see "MsaaProxy::Text_GetSelection()" in the callstack so are we getting into a fallback situation here and is that expected?

Comment 7

[James Teh [:Jamie]]

(In reply to Justin Link from comment #6)

• Looking at the stack chart, I see MsaaProxy() makes a call to mozilla::a11y::ia2AccessibleText::get_nSelections() (via AccUtils::get_nSelections()) and then spends the rest of its time (> 35s) in IA2ProxyTextRange::GetSelectionRange() which calls IA2ProxyTextRange::GetSelectionRangeEndpoints() followed by IA2ProxyTextRange::Endpoint::Normalize() many times.

Is it possible get_nSelections gets called many times too? The profiler is only somewhat accessible, so it's difficult for me to see that particular detail. My suspicion is that rather than reporting a lot of selections, the IA2 -> UIA proxy is calling get_nSelections on many objects, rather than calling it on a single object and getting a large value in return.

The problem here seems to me to come foremost from the quantity of calls into our code rather than that the calls themselves are taking a long time.

Agreed, and this is consistent with my prior understanding of problems like this.

so are we getting into a fallback situation here and is that expected?

We are indeed. It is expected... for now. Bug 762769 (and by extension bug 762817, which I have marked this bug as depending on) tracks work on a native UIA implementation. This will hopefully fix (or at least make it easier for us to control) problems like this, especially because the IA2 -> UIA proxy is really quite buggy and suboptimal (and largely unmaintained by Microsoft as far as I know). Unfortunately, the native UIA implementation is a multi-month effort and my work on it has been sidetracked by other priorities.

Comment 8

[majoranaoedipus]

Attachment: about:support raw data

Sorry for responding late.


Justin Link (Comment #2):
I am not using screen reader or UI automation, at least not consciously. I have checked my Windows 11 accessibility settings, no useful infos found. 


James Teh [:Jamie] (Comment #3) and  Mayank Bansal (Comment #4):
The raw data copied from `about:support`:

```

Comment 9

[majoranaoedipus]

Sorry for responding late.

Justin Link (Comment #2):
I am not using screen reader or UI automation, at least not consciously. I have checked my Windows 11 accessibility settings, no useful infos found.

James Teh [:Jamie] (Comment #3) and Mayank Bansal (Comment #4):
The raw data copied from about:support has been uploaded as the attachment.
In particular:
| Accessibility | |
|----------------------------|-------|
| Activated | false |
| Prevent Accessibility | 0 |
| Accessibility Instantiator | |

Mayank Bansal (Comment #4):
Here's the profiler result after I changing accessibility.force_disabled to 1: https://share.firefox.dev/4c5H0bs
But, even if I change the setting back to 0, no such issue is trigered...
The system has been through a reboot so I am not sure if anything changed. :(
Not sure if this is a good thing (the issue is gone) or a bad thing (a issue that is hard to reproduce but still very annoying when occured)

I would keep testing other sites until I find some way to reproduce.

Comment 10

[James Teh [:Jamie]]

Accessibility didn't get enabled when you captured that information, so unfortunately, we don't know what triggered this problem earlier. :( It could have been the Windows Suggested Actions feature (enabled by default depending on your locale but only rarely triggers this problem), in which case that's likely bug 1876192. I thought it might have been Windows Text Cursor Indicator (bug 1907834), but I'd say that's unlikely because you'd probably know if you enabled that.

Comment 11

[majoranaoedipus]

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

Accessibility didn't get enabled when you captured that information, so unfortunately, we don't know what triggered this problem earlier. :( It could have been the Windows Suggested Actions feature (enabled by default depending on your locale but only rarely triggers this problem), in which case that's likely bug 1876192. I thought it might have been Windows Text Cursor Indicator (bug 1907834), but I'd say that's unlikely because you'd probably know if you enabled that.

I would like to let you know that after some experimets I find that ``Windows Text Cursor Indicator (bug 1907834)'' is the problem, I didn't notice that it was on in my system (maybe I turn it on very long time ago and I forgot). I was just about to comment.

Turning accessibility.force_disabled = 1, the issue is resolved in the next launch effectively.

Yes, the issue is still there, it did not disappear magically :)

For me accessibility.force_disabled = 1 is the workaround, or turning the text cursor indicator is also a valid solution, since I do not use any accessibility feature (the text cursor indicator is not a necessary feature for me).

So... Thank you for your warm-hearted responds, advises of wisdom. Wish you all a good day.

Comment 12

[James Teh [:Jamie]]

Thanks for the follow-up. In that case, I'm going to close this as a duplicate of bug 1907834. Just so you know, we do intend to improve Firefox so that Windows Text Cursor Indicator works better, but that is going to take some time.