This came up in Fedora's most recent testing cycle, but the failure mode was not reliably reproducable, and so did not rise to the level of a blocker. I think I have some insight
It looks like there is a missing SELinux ruleset problem, causing the hang ups in Firefox, but not all of them, for reasons discussed below
https://bugzilla.redhat.com/show_bug.cgi?id=1473754
I see Adam in https://bugzilla.redhat.com/show_bug.cgi?id=1439282#c20
but sadly his conclusion that it is normal, is not true, after doing some tracing of stderr noise, and then looking for why ICP processes were failing ... Selinux ;)
------------
Adam mentions a need for fedora-qa testing through SSH tunnels and did so as root, which may have masked some of the noise -- I have a similar process for starting FF only through an ssh tunnel, daily, but it is pretty paranoid and ssh's over to a non-priv'd, and non container of information I would not want to have exfiltrated
https://bugzilla.redhat.com/show_bug.cgi?id=1439429
yeah -- I know -- paranoid
--------
anyway one culprit is the upstream cutover by FF to 'electrolysis' and its new Inter-Process Communication model. IPC is hard, and in this case SELinux is doing its job, as it has not been told about a need to accomodate electrolysis yet
In digging down into the Mozilla development process, it appears they are deploy A B testing, invisibly, and so this is why the changes to the firefox settings:
about:config
browser.tabs.remote.autostart = false browser.tabs.remote.autostart.2 = false
are NOT deterministically appearing -- FF developers have some back end, which is invisible in non-developer mode, which makes a selection process choosing if one is or is not in a test pool, AND silently upstreaming 'telemetry' ;( That sounds like exfiltration of data to me
perhaps I an not unjustifiably paranoid starting firefox in a unpriv'd and no content containing 'sandbox'
-- Russ herrold