Open Bug 1907834 Opened 2 months ago Updated 1 month ago

Code selection causes the browser to hang at 100% CPU load with Windows Text Cursor Indicator enabled

Categories

(Core :: Disability Access APIs, defect)

Product:
Core
Component:
Disability Access APIs
Version:
Firefox 128
Type:
defect

Tracking

()

Status:
UNCONFIRMED

People

(Reporter: fuzzlebang2, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

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

Steps to reproduce:

Ctrl+A to select all code on sites like Pastebin and GitHub Gist

Actual results:

The browser window stops responding and results in 100% CPU utilization.
Here is a link to the profile data: https://share.firefox.dev/4cDEvxX

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

Component: Untriaged → Widget: Win32
Product: Firefox → Core

Looks like it's spending time in accessibility code. Do you expect to have accessibility enabled?

(In reply to Timothy Nikkel (:tnikkel) from comment #2)

Looks like it's spending time in accessibility code. Do you expect to have accessibility enabled?

To be honest I've been experiencing accessibility issues in Firefox for over a year now. A year ago I already made a report about freezes related to mouse cursor a11y settings in Windows: https://bugzilla.mozilla.org/show_bug.cgi?id=1841665. To this day I still have the setting ("Text cursor indicator") turned on – could it be related? I also have the font size increased.

Recategorizing per comment 2.

Component: Widget: Win32 → Disability Access APIs

Thanks for the report and the profile. We're currently in the middle of a major project to implement UI Automation, which is what Windows Text Cursor Indicator uses to access Firefox. Currently, Firefox doesn't support UI Automation, so Windows uses a rather slow and buggy "proxy" instead. Once we have a native implementation of UIA, things like this should be a lot faster.

Blocks: a11yperf
Severity: -- → S3
Depends on: uiatext
See Also: → 1841665
Summary: Code selection causes the browser to hang at 100% CPU load → Code selection causes the browser to hang at 100% CPU load with Windows Text Cursor Indicator enabled

(In reply to fuzzlebang2 from comment #0)

Ctrl+A to select all code on sites like Pastebin and GitHub Gist

  1. How much code was on the page? Does this happen even with small amounts of code or only large amounts?
  2. Was a code editor text box focused when you pressed control+a or were you effectively selecting the entire web page?

The browser window stops responding and results in 100% CPU utilization.

For how long did the browser hang?

Flags: needinfo?(fuzzlebang2)

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

Good to see you again James!

  1. How much code was on the page? Does this happen even with small amounts of code or only large amounts?
  2. Was a code editor text box focused when you pressed control+a or were you effectively selecting the entire web page?

  1. Some observations I've made:
    1.1. I managed to reproduce with small (100 lines) and large (5k+) code fragments.
    1.2. I also managed to reproduce both with Ctrl+A and just selecting lines of code with mouse.
    1.3. Ctrl+A is always reproducible in both Pastebin and GitHub Gist, but mouse selection is harder to reproduce.
    1.4. I can't reproduce the problem if I open code in Raw mode.

  2. I consistently manage to reproduce with Ctrl+A selecting the entire web page. Now I tried selecting just the code and scrolling down the page; after about 30-40 lines were selected, the browser started to slow down (big delay on actions like tab switching and scrolling) a lot for 10-15 seconds, but the ghost "not responding" window didn't appear.

For how long did the browser hang?

From my observations, it actually depends on the amount of code. With 200 lines of code about 5-10 seconds, and with 5k lines, I just select "Close the program" in the Windows dialog and reopen Firefox, because waiting even for a few minutes doesn't give anything.

Flags: needinfo?(fuzzlebang2)

If you're willing to test with Firefox Nightly, you could try going to about:config in the address bar and setting accessibility.uia.enable to true. However, this code is still heavily under development, so it's entirely possible it will crash and you won't be able to see whether it improves things. Failing that, I'll let you know when things are more stable and ready for wider testing.

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

If you're willing to test with Firefox Nightly, you could try going to about:config in the address bar and setting accessibility.uia.enable to true. However, this code is still heavily under development, so it's entirely possible it will crash and you won't be able to see whether it improves things. Failing that, I'll let you know when things are more stable and ready for wider testing.

Will this flag work in regular Firefox (as far as I understand Firefox Nightly needs to be installed separately)? If not now, will it someday (when?) become at least a preview feature in regular Firefox?

(In reply to fuzzlebang2 from comment #9)

Will this flag work in regular Firefox

In theory, but the code is under heavy development, so regular Firefox likely doesn't have the latest code and that could mean it is more unstable, less reliable, less likely to fix your issue, etc.

(as far as I understand Firefox Nightly needs to be installed separately)?

Correct.

If not now, will it someday (when?) become at least a preview feature in regular Firefox?

I think this is months away at least, but the intention is to eventually have it enabled by default.

I totally understand if you're not able or willing to test in Nightly, though, and that is totally fine.

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

(In reply to fuzzlebang2 from comment #9)

Will this flag work in regular Firefox

In theory, but the code is under heavy development, so regular Firefox likely doesn't have the latest code and that could mean it is more unstable, less reliable, less likely to fix your issue, etc.

Good news, enabling this flag fixed the problem on the regular version of Firefox (128.0.3) as well!

It is probably too early to celebrate yet. I just checked and the code to retrieve text selection landed for Firefox 129. So, what's happening in 128 is that Text Cursor Indicator is asking for the selection and Firefox is just saying there isn't one. I guess that isn't breaking anything for you, but it is definitely a problem for many use cases. The real test will be what happens when Firefox does correctly report the selection.

Edit: But thank you for testing this nevertheless.

Duplicate of this bug: 1910519
You need to log in before you can comment on or make changes to this bug.