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

Steps to reproduce:

Create a DIV containing e.g. 100,000 smaller DIVs. Then hide the container DIV. In Firefox, it takes a LONG time (like a minute on my laptop) but in Chrome it takes a few milliseconds!

Actual results:

Firefox was VERY slow. It hid the DIV eventually, but took a long time doing so.

Expected results:

The DIV should have disappeared pretty much instantly like it does on Chrome.

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

Can you take a profile? See https://firefox-source-docs.mozilla.org/performance/reporting_a_performance_problem.html for instructions.

I can't reproduce it locally, takes a few milliseconds here (faster than Chromium in fact).

(In reply to Emilio Cobos Álvarez (:emilio) from comment #2)

Can you take a profile? See https://firefox-source-docs.mozilla.org/performance/reporting_a_performance_problem.html for instructions.

I can't reproduce it locally, takes a few milliseconds here (faster than Chromium in fact).

I took a profile but can't see how to share it. I've taken a screen grab of it, which shows the >40s it took to hide the container. But I don't seem to be able to attach that to this response!

I also tried using Troubleshoot mode to see how long that would take and that was the same. 42s that time.

Is there a way I can share the profiling information?

Please take a profile and click "Upload local profile" at the top right. That should give you a link that you can paste here.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #4)

Please take a profile and click "Upload local profile" at the top right. That should give you a link that you can paste here.

Thanks :-)

Here's my (surprisingly short) link: https://share.firefox.dev/3D9jtrV

Thanks, so that seems to be spending a lot of time in mozilla::a11y::LocalAccessible::Shutdown, which is only supposed to be enabled if you're using assistive technology like a screen reader or so.

Two questions:

• Can you attach your about:support information here?
• Can you confirm that going to about:config, searching for accessibility.force_disabled and changing it to 1 fixes it?

Jamie, is there a way to diagnose this? Also maybe this is improved by the a11y caching work? I'm not really familiar with accessibility activation on Linux to know why we might unexpectedly activate a11y.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #6)

Thanks, so that seems to be spending a lot of time in mozilla::a11y::LocalAccessible::Shutdown, which is only supposed to be enabled if you're using assistive technology like a screen reader or so.

Two questions:

• Can you attach your about:support information here?
• Can you confirm that going to about:config, searching for accessibility.force_disabled and changing it to 1 fixes it?

Wow! Thanks so much, Emilio.

Now that I've set accessibility.force_disabled to 1, it's lovely and fast! :-)

I've attached the output of about:support. (Clever the way Bugzilla offered to attach it rather than paste it in here.)

(Sorry, I don't know why my reply is there twice, once before attaching the support info and once after!)

Can you attach about:support before disabling accessibility please? Otherwise the info I'm looking for isn't there :)

  "accessibility": {
    "isActive": false,
    "forceDisabled": 0,
    "handlerUsed": false,
    "instantiator": ""
  },

Huh, that doesn't make a lot of sense, I expected at least an "isActive": true,...

(In reply to Emilio Cobos Álvarez (:emilio) from comment #7)

Jamie, is there a way to diagnose this?

Yuck! It looks like we're spending a bunch of time removing children as we shut down individual LocalAccessibles, which I guess we could probably optimise away somehow given that we're throwing away the whole subtree. We do need to clean up, but perhaps we can avoid the child removal and just clear the array. I thought we already did this somewhere, but clearly we don't in this case.

Also maybe this is improved by the a11y caching work?

I don't think this one will improve with the caching work. The performance problem is entirely within the content a11y tree.

I'm not really familiar with accessibility activation on Linux to know why we might unexpectedly activate a11y.

I'm not super familiar with Linux a11y activation either, but from the code, i see there are a few ways a11y can be activated on Linux: the GNOME_ACCESSIBILITY=1 environment variable, a DBus query and a GSettings key. It's possible the particular distribution sets this up by default.

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

I'm not super familiar with Linux a11y activation either, but from the code, i see there are a few ways a11y can be activated on Linux: the GNOME_ACCESSIBILITY=1 environment variable, a DBus query and a GSettings key. It's possible the particular distribution sets this up by default.

Thanks for looking into this.

It doesn't look like the GNOME_ACCESSIBILITY environment variable is set. I'm happy to check the DBus or GSettings ones but don't know how.

If it's any help, I'm using Mint 21, which is based upon Ubuntu 22.04.