Closed Bug 1726887 Opened 3 years ago Closed 7 months ago

Memory leak when accessibility is allowed but not activated

Categories

(Core :: Disability Access APIs, defect)

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

Tracking

()

Status:
RESOLVED WORKSFORME
Project Flags:
Performance Impact low
Tracking Flags:
Tracking Status
firefox91 --- affected
firefox92 --- affected
firefox93 --- affected

People

(Reporter: Nabil.tharwat, Unassigned)

References

Details

(Keywords: perf:resource-use)

Attachments

(2 files)

Fewer accessibility items in the accessibility section than expected — one
201.73 KB, image/png
Details
Fewer accessibility items in the accessibility section than expected — two
119.23 KB, image/png
Details

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

Steps to reproduce:

  1. Record Firefox's memory usage with 1 empty tab open
  2. Open any JS-heavy website
  3. Scroll infinitely to generate loads and loads of content
  4. Record Firefox's memory usage now
  5. Close the tab
  6. Compare memory usage.

Actual results:

Memory isn't completely released after closing a heavy tab. In fact, running multiple Reddit/Facebook tabs for a few minutes will cause Firefox's memory usage to spike so high it may use all available memory. Closing all tabs does NOT release that memory.

Expected results:

What should have happened is memory usage should climb down to a value close to the value recorded in step 1.

Setting the about:config accessibility.force_disabled flag to 1 fixed this problem for me and numerous other users. It also improved the browser's performance and rendering speed. Memory usage no longer goes higher than 1 GB for me.

This Reddit post has more details about the defect.

Why have it enabled by default without a GUI option to disable/enable it like it used to? I think a better way to do this is to detect whether an assistive technology tool is trying to read Firefox (on launch), and based on that determine whether the option should be enabled. It would also be neat to have an option in the GUI. And would be so much better to provide an "accessible" dialog on launch to allow existing users (and new users!) using assistive technology to enable on browser launch.

Or if it's possible, have the feature disabled by default and bring back the option to allow it. Then have the main program GUI accessible so users of assistive technology can navigate the GUI and turn on accessibility features. Improving/fixing the security and performance issues should be the priority though, I believe.

Extra reproduction info:

I reset accessibility.force_disabled, restarted the browser, opened 10 Reddit & Facebook tabs and used all the most complex features of the two websites. Memory usage jumped to 92%, at which point Windows started hard-limiting Firefox, causing it to jump to 2 million page faults, all in under 10 minutes.

When I closed the tabs the memory usage decreased only by a few hundred megabytes, down to about 84%. Before opening the tabs memory usage was 58%.

"Accessibility Instantiator" was still empty when I first opened the browser, when I was browsing, and after I closed the tabs.

Then I toggled the config switch on again. I did everything all over again. I actually loaded more tabs, memory usage didn't go over the 84% mark. Everything was 2x more responsive and smooth. I closed the tabs (but this one I'm typing this reply in) and memory usage is sitting at 64% with a few other tabs open as well.

I had checked before doing all of this, page faults were sitting at 200K.

"Accessibility Instantiator" was, again, still empty.

Also to note, "Accessible Handler Used" in about:support reports as true even when accessibility.force_disabled is active.

I confirm this Firefox 91.0.1 on Windows 10.

Operating system: Ubuntu Hirsute Hippo
Firefox version: Nightly 93.0a1 (2021-08-21)
Total usable system memory: Around 7.54GiB according to htop

The setup:
I have thirteen tabs pinned, all from certain video platforms — I can't even pay Crunchyroll to watch some content in Bosnia because geographical restrictions are nice like that — and additionally opened one Bugzilla tab and one Reddit tab.

The process:
Whilst glancing in regular intervals of five-or-so seconds at htop running in a terminal window in the workspace below the on in which the Firefox window was, I opened Firefox, opened the two tabs mentioned above after the thirteen pinned tabs finished loading, opened about:config, set accessibility.force_disabled to 1, closed Firefox, reopened Firefox, did the same procedure as outlined thus far with the exception of setting the aforementioned flag's value to 0, so on and so forth for ten to fifteen minutes.

The findings:
Regardless of the value of the flag, total system memory usage before opening the two tabs hovers at just below 4GiB, whereas it hovers at around 4.15GiB after the aforementioned tabs have been opened.

The caveats:

  1. I have done this test with my regular, everyday profile, not with a clean profile with next to no modifications, so these might not be very representative results.
  2. I did not conduct this test rigorously, which means that there is some room for error.
  1. It seems that about:support on my laptop shows less accessibility information than it appears to be showing others in this ticket and in the related Reddit post.
Component: Untriaged → Disability Access APIs
Product: Firefox → Core

(In reply to Nabil Tharwat from comment #1)

I think a better way to do this is to detect whether an assistive technology tool is trying to read Firefox (on launch), and based on that determine whether the option should be enabled.

That is actually what happens already. Accessibility doesn't get enabled unless a client explicitly requests it. Unfortunately, some tools other than assistive technologies (including Windows touch services and enterprise SSO tools) do request it. We have code to block some of those services (e.g. Windows touch), but I guess on affected systems there is some other tool at play here.

(In reply to Nabil Tharwat from comment #3)

"Accessibility Instantiator" was still empty when I first opened the browser, when I was browsing, and after I closed the tabs.

Just to double check, did you refresh about:support for each check? What's puzzling to me here is that if accessibility gets enabled by a client, even if we don't know what that client is, we should still show "UNKNOWN|" (not empty) for the instantiator. I'm not quite sure how accessibility could get enabled without that showing.

Did you open Dev Tools at any point during this reproduction?

(In reply to Nabil Tharwat from comment #4)

Also to note, "Accessible Handler Used" in about:support reports as true even when accessibility.force_disabled is active.

You can ignore this. The name is somewhat confusing, but it indicates whether the handler is available, not really whether it is in active use. That is only relevant on Windows, which is why it doesn't show up on Linux.

Flags: needinfo?(Nabil.tharwat)

I just verified that accessibility activated shows as false on my system if I start Firefox without an accessibility client running, so we haven't regressed here. That raises the question of what tool is causing accessibility to be activated on impacted systems.

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

I just verified that accessibility activated shows as false on my system if I start Firefox without an accessibility client running, so we haven't regressed here. That raises the question of what tool is causing accessibility to be activated on impacted systems.

I don't think this is the correct understanding of the problem.

"accessibility activated" shows as "false" on my system as well whether "accessibility.force_disabled" is set or not.
However, Firefox has performance issues as described when "accessibility.force_disabled" is not set.

(In reply to mkeroppi from comment #11)

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

I just verified that accessibility activated shows as false on my system if I start Firefox without an accessibility client running, so we haven't regressed here. That raises the question of what tool is causing accessibility to be activated on impacted systems.

I don't think this is the correct understanding of the problem.

"accessibility activated" shows as "false" on my system as well whether "accessibility.force_disabled" is set or not.
However, Firefox has performance issues as described when "accessibility.force_disabled" is not set.

Also, the performance issues have been consistently seen through many versions prior. It's only now corrected by setting "accessibility.force_disabled".

Intriguing. If accessibility activated shows as false, that means the a11y engine isn't running at all. In that case, I don't understand how performance gets degraded here.

Technical note: Look at whether LazyInstantiator is behaving incorrectly here.

(In reply to Nabil Tharwat from comment #1)

I think a better way to do this is to detect whether an assistive technology tool is trying to read Firefox (on launch), and based on that determine whether the option should be enabled.

That is actually what happens already. Accessibility doesn't get enabled unless a client explicitly requests it. Unfortunately, some tools other than assistive technologies (including Windows touch services and enterprise SSO tools) do request it. We have code to block some of those services (e.g. Windows touch), but I guess on affected systems there is some other tool at play here.

(In reply to Nabil Tharwat from comment #3)

"Accessibility Instantiator" was still empty when I first opened the browser, when I was browsing, and after I closed the tabs.

Just to double check, did you refresh about:support for each check? What's puzzling to me here is that if accessibility gets enabled by a client, even if we don't know what that client is, we should still show "UNKNOWN|" (not empty) for the instantiator. I'm not quite sure how accessibility could get enabled without that showing.

Did you open Dev Tools at any point during this reproduction?

(In reply to Nabil Tharwat from comment #4)

Also to note, "Accessible Handler Used" in about:support reports as true even when accessibility.force_disabled is active.

You can ignore this. The name is somewhat confusing, but it indicates whether the handler is available, not really whether it is in active use. That is only relevant on Windows, which is why it doesn't show up on Linux.

I didn't have Dev Tools open. And I refreshed about:support for each check. I even opened completely separate tabs for each check. In all cases, it didn't show anything, and the fix was effective.

I don't have any accessibility clients active on my machine, and my machine doesn't even have a touch display. I don't know what might be causing this, but I encountered the behavior on multiple different setups. I'm willing to provide more debug info since the bug exists on my machine, just tell me what to do.

Flags: needinfo?(Nabil.tharwat)

You can ignore this. The name is somewhat confusing, but it indicates whether the handler is available, not really whether it is in active use. That is only relevant on Windows, which is why it doesn't show up on Linux.

Oh. False alarm on my end then 😅

Also, for what it's worth, when triggering the accessibility service by checking the accessibility of some webpage in the developer tools, I only see a small difference in memory usage in htop, about 0.1GiB; I even checked if the service was being activated by reloading about:support every single time I opened and closed the developer tools. Amongst the pages that I tested on was Reddit, since that's one page that is explicitly mentioned in the description of this ticket.

The change will not be that noticeable on a short page. You need to activate it and then scroll, and scroll and scroll a bit more. The more you scroll, the more exponential the memory usage will get. Then you close the tab, and boom, Firefox won't free up all that memory.

If you force enable a11y (i.e. set accessibility.force_disabled to -1) and restart, what happens concerning memory leakage? Note that the performance and memory usage will be different, but what I'm curious about is whether the leaking stops; i.e. when you close a tab, does memory usage start to go down significantly.

Flags: needinfo?(Nabil.tharwat)

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

Accessibility doesn't get enabled unless a client explicitly requests it.

Would devtools.accessibility.auto-init.enabled (as mentioned on https://developer.mozilla.org/en-US/docs/Tools/Accessibility_inspector) set to false actually prevent a client to enable accessibility features unless the user explicitly accept the request?

(In reply to Misaki from comment #19)

Would devtools.accessibility.auto-init.enabled (as mentioned on https://developer.mozilla.org/en-US/docs/Tools/Accessibility_inspector) set to false actually prevent a client to enable accessibility features unless the user explicitly accept the request?

No. That pref only relates to the Accessibility panel in Firefox Dev Tools, not to external client usage of accessibility.

Whiteboard: [qf]

A reddit report says that disabling the Automatic Font Sizing setting improves scroll performance in fenix: we suspect this issue is the root cause so we added it to perf triage to find an owner. Here's the issue for fenix: https://github.com/mozilla-mobile/fenix/issues/21033

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

If you force enable a11y (i.e. set accessibility.force_disabled to -1) and restart, what happens concerning memory leakage? Note that the performance and memory usage will be different, but what I'm curious about is whether the leaking stops; i.e. when you close a tab, does memory usage start to go down significantly.

:mkeroppi, as you were also able to reproduce this, would you be willing to try this? We haven't had any response from Nabil Tharwat concerning this. Thanks.

I'm marking this as s2 because it seems pretty nasty, but note that no one working on the product has been able to confirm this yet.

Severity: -- → S2
Flags: needinfo?(mkeroppi)

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

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

If you force enable a11y (i.e. set accessibility.force_disabled to -1) and restart, what happens concerning memory leakage? Note that the performance and memory usage will be different, but what I'm curious about is whether the leaking stops; i.e. when you close a tab, does memory usage start to go down significantly.

:mkeroppi, as you were also able to reproduce this, would you be willing to try this? We haven't had any response from Nabil Tharwat concerning this. Thanks.

I'm marking this as s2 because it seems pretty nasty, but note that no one working on the product has been able to confirm this yet.

set accessibility.force_disabled to -1 seems fine (same as set accessibility.force_disabled to 1) from a quick comparison with set accessibility.force_disabled to 0, e.g., the "responsiveness" of Firefox improves and memory usage seems less (and seems proper memory unloading). I won't be able to tell definitively until I leave Firefox running for maybe a day (don't know which website Nabil Tharwat is loading), and sorry I can't run Firefox with this flag set to 0 anymore.

Flags: needinfo?(mkeroppi)

(In reply to mkeroppi from comment #23)

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

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

If you force enable a11y (i.e. set accessibility.force_disabled to -1) and restart, what happens concerning memory leakage? Note that the performance and memory usage will be different, but what I'm curious about is whether the leaking stops; i.e. when you close a tab, does memory usage start to go down significantly.

:mkeroppi, as you were also able to reproduce this, would you be willing to try this? We haven't had any response from Nabil Tharwat concerning this. Thanks.

I'm marking this as s2 because it seems pretty nasty, but note that no one working on the product has been able to confirm this yet.

set accessibility.force_disabled to -1 seems fine (same as set accessibility.force_disabled to 1) from a quick comparison with set accessibility.force_disabled to 0, e.g., the "responsiveness" of Firefox improves and memory usage seems less (and seems proper memory unloading). I won't be able to tell definitively until I leave Firefox running for maybe a day (don't know which website Nabil Tharwat is loading), and sorry I can't run Firefox with this flag set to 0 anymore.

I'll continue to run Firefox with this flag set to -1 and update if anything changes.

Ok

-1 forces accessibility, and accessibility activated - seems good
0 allows accessibility, but accessibility not activated - bug as described herein
1 disable accessiblity, and accessibility not activated - seems good

Investigation note: This sounds a bit like bug 1446280, though I don't see how that could have regressed.

Could somebody gather an about:memory dump during the state when Firefox has high memory usage, when accessibility is enabled?

Whiteboard: [qf] → [qf:p3:resource]

I was planning on providing all required information but got too busy.

If you force enable a11y (i.e. set accessibility.force_disabled to -1) and restart, what happens concerning memory leakage? Note that the performance and memory usage will be different, but what I'm curious about is whether the leaking stops; i.e. when you close a tab, does memory usage start to go down significantly.

I'll try this for the cases (-1, 0, 1) and report memory usage for each using process hacker and will provide memory dumps in all three cases ASAP.

Flags: needinfo?(Nabil.tharwat)

For what it's worth, this seems to be the problem on a family member's laptop.

The system is Lenovo Ideapad 100S; Xubuntu x86_64 (XFCE) and Firefox 92.0.

Browsing on the same hardware on Windows 10 32-bit (and possibly with older Firefox) was fine.

Since switching to Xubuntu (and 64-bit OS) I found 2Gb of RAM too slim -- and the system would start to swap after less than an hour browsing (shopping sites, Google Maps etc.)

Setting accessibility.force_disabled=1 and it's usable on this 2Gb RAM machine, no reported problems after a few days.

(In reply to Mark Hills from comment #29)

The system is Lenovo Ideapad 100S; Xubuntu x86_64 (XFCE) and Firefox 92.0.
...
Setting accessibility.force_disabled=1 and it's usable on this 2Gb RAM machine, no reported problems after a few days.

If you go to about:support, does Accessibility show as Activated: true or false? This bug is concerning the case that accessibility isn't activated (but isn't force disabled). If it's showing as activated, that's a different bug we'll need to investigate separately.

Flags: needinfo?(mark-mozilla)
Summary: Accessibility Service Memory Leak → Memory leak when accessibility is allowed but not activated

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

(In reply to Mark Hills from comment #29)

The system is Lenovo Ideapad 100S; Xubuntu x86_64 (XFCE) and Firefox 92.0.
...
Setting accessibility.force_disabled=1 and it's usable on this 2Gb RAM machine, no reported problems after a few days.

If you go to about:support, does Accessibility show as Activated: true or false? This bug is concerning the case that accessibility isn't activated (but isn't force disabled). If it's showing as activated, that's a different bug we'll need to investigate separately.

I'm afraid I no longer have access to the system, so that's all the information I can give for now.

Flags: needinfo?(mark-mozilla)
See Also: → 1736116

Could be fixed for me in 94.0

Is it possible to catch issues like this with automated testing?

Performance Impact: --- → P3
Keywords: perf:resource-use
Whiteboard: [qf:p3:resource]

The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.

Status: UNCONFIRMED → NEW
Ever confirmed: true

Can anyone still reproduce this?

I'm afraid it's still there for me (FF 111 on macOS).

I didn't use a scientific method so I cannot give you exact numbers, however I did disable accessibility a while ago (years) with force_disabled=1 because of the memory leak issue it was causing, then I forgot about it.

A few days ago I checked about:flags as I do routinely, found it and reset it because I was convinced this bug must have been fixed in all this time.

Since then, I had constanly FF main process (the one I was observing) occupy way more memory than usual.

Finally a couple of days ago, after researching for a bit, I found again this bug, set force_disabled to 1 again, and the memory leak is gone.

Unbelievable how this bug has survived all this time!

Found this bug by searching around for a bug I experienced when I switched to a Wayland session in Kubuntu 22.10, Firefox 111.0.1 - I noticed that after a little while of using it normally, middle-clicking on a link to open it in a new tab would cause Firefox to completely freeze up for several seconds, then open the new tab and resume operations.

So far, accessibility.force_disabled = 1 is working for me to mitigate, since I don't require the use of accessibility services, but I imagine it would be tough to work around if you do require those services?

(In reply to John Kizer from comment #38)

Found this bug by searching around for a bug I experienced when I switched to a Wayland session in Kubuntu 22.10, Firefox 111.0.1 - I noticed that after a little while of using it normally, middle-clicking on a link to open it in a new tab would cause Firefox to completely freeze up for several seconds, then open the new tab and resume operations.

It's possible accessibility was actually activated for you, in which case this would be a different bug. With accessibility.force_disabled removed, if about:support shows Activated true under the Accessibility section, that means accessibility is enabled for some reason. If that's the case and if you're willing, it'd be good to get a separate bug on file for that, ideally with a performance profile.

(In reply to Diego Caravana from comment #37)

I didn't use a scientific method so I cannot give you exact numbers, however I did disable accessibility a while ago (years) with force_disabled=1 because of the memory leak issue it was causing, then I forgot about it.

Diego, are you certain accessibility wasn't activated by something? That is, without force_disable, does about:support show Activated true under the Accessibility section, or does it show Activated false?

Flags: needinfo?(diego.caravana)

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

(In reply to John Kizer from comment #38)

Found this bug by searching around for a bug I experienced when I switched to a Wayland session in Kubuntu 22.10, Firefox 111.0.1 - I noticed that after a little while of using it normally, middle-clicking on a link to open it in a new tab would cause Firefox to completely freeze up for several seconds, then open the new tab and resume operations.

It's possible accessibility was actually activated for you, in which case this would be a different bug. With accessibility.force_disabled removed, if about:support shows Activated true under the Accessibility section, that means accessibility is enabled for some reason. If that's the case and if you're willing, it'd be good to get a separate bug on file for that, ideally with a performance profile.

Hi Jamie - I turned the force_disabled flag back to 0, restarted, and see this in the about:support section for Accessibility - so I don't think it's that Accessibility is actually being enabled? Is there anything else that would be helpful to view?

Accessibility
Activated false
Prevent Accessibility 0

Hi John,

You're quite correct: that shows accessibility is not enabled. That does make me wonder what could possibly be going on when you see the delay when trying to open a new tab, though. Is there any chance you could capture a profile of that delay?

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

Hi John,

You're quite correct: that shows accessibility is not enabled. That does make me wonder what could possibly be going on when you see the delay when trying to open a new tab, though. Is there any chance you could capture a profile of that delay?

I'd be happy to as soon as I can reproduce it again...of course, now that I'm explicitly trying to middle-click everything in sight, it won't happen! But yep, I'll try to snag a profile via that tool as soon as I see it crop up again.

Thanks!

(In reply to John Kizer from comment #38)

Found this bug by searching around for a bug I experienced when I switched to a Wayland session in Kubuntu 22.10, Firefox 111.0.1 - I noticed that after a little while of using it normally, middle-clicking on a link to open it in a new tab would cause Firefox to completely freeze up for several seconds, then open the new tab and resume operations.

So far, accessibility.force_disabled = 1 is working for me to mitigate, since I don't require the use of accessibility services, but I imagine it would be tough to work around if you do require those services?

I'm running accessibility.force_disabled = 1, but I've been hitting this regularly. When it happens, the freeze will also be triggered by middle-clicking to open-in-new-tab. I hadn't thought to attribute it to Wayland, but I am running a KDE Wayland session on Fedora 37 (with Firefox in xwayland because of Bug 1681018, aka Gnome-specific dupe at 1681029).

I am also using the Sidebery extension and have a very large number (hundreds) of tabs in one window. You too?

The problem comes and goes, but I will try to remember to record a profile the next time it happens.

Probably a separate issue, however. If anyone knows any bug numbers tracking it, please advise.

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

(In reply to Diego Caravana from comment #37)

I didn't use a scientific method so I cannot give you exact numbers, however I did disable accessibility a while ago (years) with force_disabled=1 because of the memory leak issue it was causing, then I forgot about it.

Diego, are you certain accessibility wasn't activated by something? That is, without force_disable, does about:support show Activated true under the Accessibility section, or does it show Activated false?

Hey James, I've just set force_disabled to the default value (0) and the troubleshooting information page shows accessibility has not been activated:

Accessibility
Activated false
Prevent Accessibility 0

I'm a bit confused now: can FF accessibility be activated by something else then? What else?

Flags: needinfo?(diego.caravana)

There are some non-obvious tools that use accessibility; e.g. voice control, enterprise SSO tools, etc. That said, based on the info you've provided, it does seem that accessibility definitely isn't activated on your system. Thanks for confirming that.

I still can't reproduce this, nor do I really have any idea what could be causing it. As far as I can tell, when accessibility isn't activated, accessibility code isn't called at all for the most part.

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

There are some non-obvious tools that use accessibility; e.g. voice control, enterprise SSO tools, etc. That said, based on the info you've provided, it does seem that accessibility definitely isn't activated on your system. Thanks for confirming that.

I still can't reproduce this, nor do I really have any idea what could be causing it. As far as I can tell, when accessibility isn't activated, accessibility code isn't called at all for the most part.

Just got a profile of this issue occurring - and it was while I had accessibility force-disabled, so apparently at least for me it isn't necessarily tied to that setting anyway!

Is this link the right way to share? https://share.firefox.dev/40CL1z9

I'm doing an assessment of all open S2 bugs as we head into Q4. I notice Diego was testing on Fx 111 on Mac, and Cache the World shipped in Fx 113.

Jamie -- Is it possible that Cache the World fixed this?

Diego -- Can I ask you to retest with the most recent Firefox version since the accessibility code has improved significantly since Fx 111?

Flags: needinfo?(jteh)
Flags: needinfo?(diego.caravana)

Hey Maire,

I've checked about:support in my Firefox instance and it says accessibility is not activated, with force_disabled==0 (I didn't change it since my last comment above 6 months ago).

However, I cannot find an obvious way to enable accessibility in Firefox so I cannot actually anything related to it - can you help with that please?

Apart from that, lately I didn't notice any huge misbehaviour in memory management by Firefox.

However, I cannot find an obvious way to enable accessibility in Firefox so I cannot actually anything related to it - can you help with that please?

You can set force_disabled = -1, and a11y will be force enabled :) Confusing, but it works!

Of course Morgan! :)

I've just activated it, I'll try for a few days and let you guys know.

This bug has become somewhat confusing. It is intended to cover cases where there are memory leaks when accessibility is allowed (i.e. not force disabled, which is the default), but not activated (about:support shows Activated: false in the Accessibility section). Users experiencing this were apparently seeing memory leaks when accessibility was not force disabled and not activated, but the memory leaks apparently went away when they force disabled accessibility. This would suggest this is somehow related to accessibility detection code and thus is not impacted by the Cache the World project.

Diego, if you have not been experiencing any issues with accessibility.force_disabled set to 0 (the default), you are not impacted by this bug. I guess something must have changed since your comment 37? However, I'm a little confused. In comment 37, you said you set force_disabled to 1, but in comment 49, you said it was set to 0. Has it been set to 0 or 1 for the last few months (presumably without any memory issues)?

Anyone who is experiencing a memory leak with accessibility.force_disabled set to 1 is not impacted by this bug. If such a bug exists, it is a bug somewhere else.

If anyone is experiencing a memory leak with accessibility activated (about:support shows Activated: true in the Accessibility section), that is not this bug and a new bug should be filed with details.

Flags: needinfo?(jteh)

Is anyone at all experiencing memory leaks when accessibility is not force disabled (so accessibility.force_disabled is set to the default 0, not 1), but about:support shows Activated: false in the Accessibility section? If not, I think we can close this bug.

Hi James, thanks for the explanation.

Put simply, in https://bugzilla.mozilla.org/show_bug.cgi?id=1726887#c37 played a bit with that flag and noticed that the bug was back if accessibility was not force disabled (=1).

Then, at some point 6 months ago, I reset that flag to its default value (=0) as per https://bugzilla.mozilla.org/show_bug.cgi?id=1726887#c45.

I am under the impression, though, that force_disabled=0 at the time was actually enabling accessibility (as shown in about:support), but now with that value it remains disabled.

With force_disabled=-1, as it is from yesterday, I'm not noticing any weird behaviour regarding memory, but again this is not really scientific.

Anyway, since I kept force_disabled=0 for months and I did not notice anything wrong, it looks like I've not been affected by this bug as you said in your comment.

Flags: needinfo?(diego.caravana)

(In reply to Diego Caravana from comment #54)

Then, at some point 6 months ago, I reset that flag to its default value (=0) as per https://bugzilla.mozilla.org/show_bug.cgi?id=1726887#c45.

My bad, I somehow missed this when re-digesting the comments here. Sorry.

I am under the impression, though, that force_disabled=0 at the time was actually enabling accessibility (as shown in about:support)

Comment 45 suggests that Accessibility Activated was reported as false, which means it wasn't activated, even though it was allowed to activate (not force disabled).

Anyway, since I kept force_disabled=0 for months and I did not notice anything wrong, it looks like I've not been affected by this bug as you said in your comment.

Thanks for confirming.

I'm going to close this. If anyone sees the problem I described in comment 53, we can reopen this:

Is anyone at all experiencing memory leaks when accessibility is not force disabled (so accessibility.force_disabled is set to the default 0, not 1), but about:support shows Activated: false in the Accessibility section?

Status: NEW → RESOLVED
Closed: 7 months ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: