Closed Bug 1736116 Opened 3 years ago Closed 3 years ago

Loading an enterprise site that has multiple subdomains (at times 20+tabs) causes slowness fixed by fission enabled and dom.ipc.processcount.webisolated turned up

Categories

(Core :: Disability Access APIs, defect)

Firefox 93
defect

Tracking

()

RESOLVED DUPLICATE of bug 1726887
Tracking Status
firefox93 --- affected

People

(Reporter: paul.stejskal, Unassigned)

References

Details

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

Steps to reproduce:

I have a bunch of tabs I open frequently for my work that are different subdomains. Some of the pages have lots of CSS and javascript, so they tend to lag. Or they may literally display logs that are thousands of lines long.

Well...I made some changes as mentioned on this Reddit thread:

  1. disable accessibility by accessibility.force_disabled to 1
  2. enable fission.autostart
  3. set dom.ipc.processcount.webisolated to 50 (really 20 was fine)

Actual results:

  1. Disabling the accessibility helped by just overall improving performance. This probably should be heavily looked into as it seems to be a common tweak on Reddit.
  2. Fission seems like it will be default soon enough, but this provided per-domain isolation, but *.domain.com was still on a single Firefox thread on a single core.
  3. Cranking up the webisolated threads really helped and it loaded faster than Edge doing the same test of loading about 10 of the same tabs at same time.

Expected results:

N/A

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

Component: Untriaged → DOM: Content Processes
Product: Firefox → Core

Paul, thanks for reporting this bug.

We are increasing dom.ipc.processCount.webIsolated from 1 to 4 in Firefox 94, which should help. But it sounds like some external program is activating accessibility. That can happen sometimes with touch screens or input editors.

Can you please restore accessibility.force_disabled to its default value, restart Firefox, and then copy and paste your Firefox's about:support text in this bug? Does the about:support have a "Accessibility Instantiator" value?

@ Jamie, how can a user determine why Firefox is activating accessibility? How should a user diagnose an accessibility performance problem?

Blocks: 1418290
Flags: needinfo?(jteh)

Chris,

Accessibility
Activated false
Prevent Accessibility 0
Accessible Handler Used true
Accessibility Instantiator

I think adding more threads definitely was helpful too. Maybe 4 is enough? I can try.

Given that you're seeing "Accessibility activated false" even with accessibility.force_disabled set to default, that indicates that the a11y engine is not actually being used. We have bug 1726887 tracking an issue where accessibility isn't activated but seems to be causing memory leaks and performance issues. I haven't been able to reproduce that, which makes it very difficult to diagnose, but I suspect we're dealing with the same issue here (at least the a11y part of it).

Flags: needinfo?(jteh)

Anything I can gather to help troubleshooting?

Severity: -- → S3
Priority: -- → P2

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

We have bug 1726887 tracking an issue where accessibility isn't activated but seems to be causing memory leaks and performance issues. I haven't been able to reproduce that, which makes it very difficult to diagnose, but I suspect we're dealing with the same issue here (at least the a11y part of it).

Is this a duplicate of bug 1726887 then?

Severity: S3 → --
Component: DOM: Content Processes → Disability Access APIs
Priority: P2 → --
See Also: → 1726887
Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.