[Bug] After closing Fenix, security.enterprise_roots.enabled resets to FALSE by itself

[sharbet]

Steps to reproduce

1. In about:config, turn on security.enterprise_roots.enabled to TRUE
2. Close Firefox Fenix Nightly from Recent Apps.
3. Observe security.enterprise_roots.enabled reset to FALSE

Expected behavior

security.enterprise_roots.enabled stays TRUE

Actual behavior

security.enterprise_roots.enabled resets to FALSE

Device information

Device vendor / model and Android version: Android 11, Galaxy S20+

Firefox for Android version: ? (go to Settings -> About Firefox)
Nightly 210407 17:03 (Build #2015803275)
AC: 75.0.20210407143059, 54395a6fa
GV: 89.0a1-20210407094544
AS: 74.0.1

Comments

I need this feature to stay TRUE, as many others do.

https://www.reddit.com/r/Adguard/comments/mm01bh/firefox_mobile_nightly_reset_a_security_setting/

#18871 (comment)

I'm going to close the previous issue #18871 , due to not cluttering up the issues board.

Devs, it would be nice if you could fix this issue.

This began happening to me after 4/6 update, although others mentioned it occurred earlier.

┆Issue is synchronized with this Jira Task

[kbrosnan]

This is a dupe of #3728 and fallout from bz-1678191

[virgoparna]

How is this dupe of #3728? #3728 wants this preference to default to true and/or to have interface for changing this preference.
This bug is about the fact, that the preference value is reset to false every time browser is closed.

[cadeyrn]

As written it's a fallout from bz-1678191 and #3728 is about proper implementing support for this option. And in #3728 you can read that it's planned to work on this very soon.

[AjvarXX]

As written it's a fallout from bz-1678191 and #3728 is about proper implementing support for this option. And in #3728 you can read that it's planned to work on this very soon.

So after it's "fixed" (hopefully) and someone decides that he wants settings to be false while encountering a bug of roots.enterprise.enabled always reset to default true - that also will be called a duplicate of bug #3738 and called no-fix??!
Maybe it's just better to keep 2 separate bugs separate and discussing the default state in one topic and the bug of resetting that state every few hours in another topic?