Description of problem: I detected a "loop of death" inside firefox+DE, which can OOM firefox with a possible crash in the end. Of course this is a level 8 problem, as the user selects this. The real bug is, that ff offers itself as the app to handle this. This should not happen. Additionally, FF does not seem to detect, that it is inside this loop of opening files via the DEs Default App function. I suggest to add one, as this leeds to OOM (takes a while), crash&db-corruption(due to oom) and waste of diskspace (partfile entries). In my test, i stopped it at 453 tabs + partfiles :) Version-Release number of selected component (if applicable): ALL How reproducible: easy. Opening an MD file, like Readme.md, with firefox. Steps to Reproduce: 1. Find a Markdown file 2. open it with firefox 3. Firefox offers to download that md file ( pre-selected ) or to open it in an App. Select firefox. Loop closed. Now we have a loop of opening tabs on our hands, which produces PART Files in the userhome: -rw-------. 1 username username 0 3. Feb 11:10 WFNDAxzY.part -rw-------. 1 username username 0 3. Feb 11:10 wjf954Ez.part -rw-------. 1 username username 0 3. Feb 11:10 wKlezHso.part -rw-------. 1 username username 0 3. Feb 11:11 wMpPLySE.part -rw-------. 1 username username 0 3. Feb 11:10 WpxVeW8E.part -rw-------. 1 username username 0 3. Feb 11:10 wQOo8Du2.part -rw-------. 1 username username 0 3. Feb 11:10 wtPT_gBB.part -rw-------. 1 username username 0 3. Feb 11:10 WvxNyIlJ.part -rw-------. 1 username username 0 3. Feb 11:10 wVXwqzS9.part -rw-------. 1 username username 0 3. Feb 11:10 WxinqAhW.part -rw-------. 1 username username 0 3. Feb 11:10 -wXmm0fo.part -rw-------. 1 username username 0 3. Feb 11:10 wZsHjXgz.part -rw-------. 1 username username 0 3. Feb 11:10 X8uzLaFy.part -rw-------. 1 username username 0 3. Feb 11:10 xczNf5T_.part -rw-------. 1 username username 0 3. Feb 11:10 Xd8d8zjF.part -rw-------. 1 username username 0 3. Feb 11:10 xd-rAjTh.part -rw-------. 1 username username 0 3. Feb 11:10 xHA9FPof.part -rw-------. 1 username username 0 3. Feb 11:11 XiwxZ6Lr.part -rw-------. 1 username username 0 3. Feb 11:10 xIY7YT6p.part -rw-------. 1 username username 0 3. Feb 11:10 XOjfitdK.part -rw-------. 1 username username 0 3. Feb 11:10 XOLeojyL.part -rw-------. 1 username username 0 3. Feb 11:10 xoxbEngL.part -rw-------. 1 username username 0 3. Feb 11:10 XpFmDscK.part -rw-------. 1 username username 0 3. Feb 11:10 xPqzoCDy.part -rw-------. 1 username username 0 3. Feb 11:10 XsqD-MxM.part -rw-------. 1 username username 0 3. Feb 11:10 Xt_EQNsx.part -rw-------. 1 username username 0 3. Feb 11:10 XyHDZfcv.part -rw-------. 1 username username 0 3. Feb 11:10 xYlPzOcg.part -rw-------. 1 username username 0 3. Feb 11:10 Xyz8MFoB.part -rw-------. 1 username username 0 3. Feb 11:10 Y0793--B.part -rw-------. 1 username username 0 3. Feb 11:11 Y33prt5r.part -rw-------. 1 username username 0 3. Feb 11:10 Y3n4Jlao.part -rw-------. 1 username username 0 3. Feb 11:10 y5gqxvp-.part -rw-------. 1 username username 0 3. Feb 11:10 y7BJ7rr3.part -rw-------. 1 username username 0 3. Feb 11:10 Y7D6kAdU.part -rw-------. 1 username username 0 3. Feb 11:10 y7QlpRyx.part -rw-------. 1 username username 0 3. Feb 11:11 YclFs4fm.part -rw-------. 1 username username 0 3. Feb 11:11 ygSiiVET.part -rw-------. 1 username username 0 3. Feb 11:10 yiWa5DWq.part -rw-------. 1 username username 0 3. Feb 11:11 YM7AnK4R.part -rw-------. 1 username username 0 3. Feb 11:10 yMS61vWE.part -rw-------. 1 username username 0 3. Feb 11:10 _Yprvz6d.part -rw-------. 1 username username 0 3. Feb 11:11 YPSOm_ZN.part -rw-------. 1 username username 0 3. Feb 11:10 Y-sao3NZ.part -rw-------. 1 username username 0 3. Feb 11:10 ysW8XkfW.part -rw-------. 1 username username 0 3. Feb 11:10 yuFleI0H.part -rw-------. 1 username username 0 3. Feb 11:10 yUSdxFSK.part -rw-------. 1 username username 0 3. Feb 11:10 yXyvb-rp.part -rw-------. 1 username username 0 3. Feb 11:11 yzrvwC1B.part -rw-------. 1 username username 0 3. Feb 11:10 z9vRmjrj.part -rw-------. 1 username username 0 3. Feb 11:10 ZehVT_gf.part -rw-------. 1 username username 0 3. Feb 11:10 ZfILuE4u.part -rw-------. 1 username username 0 3. Feb 11:10 zgyhWqXf.part -rw-------. 1 username username 0 3. Feb 11:10 ZHUcPSoX.part -rw-------. 1 username username 0 3. Feb 11:10 zlexJF1a.part -rw-------. 1 username username 0 3. Feb 11:10 z_NFNQjP.part -rw-------. 1 username username 0 3. Feb 11:10 zuAd-gQ4.part -rw-------. 1 username username 0 3. Feb 11:10 ZvkM9XCi.part -rw-------. 1 username username 0 3. Feb 11:10 zvvUbOD_.part -rw-------. 1 username username 0 3. Feb 11:11 zVXxj9Tz.part -rw-------. 1 username username 0 3. Feb 11:11 zxmOuI3i.part -rw-------. 1 username username 0 3. Feb 11:10 zY8ReQS4.part -rw-------. 1 username username 0 3. Feb 11:11 _ZzGApIf.part
sidenote: it was not possible to use any other app, as any new tab focused firefox. The window context menu was the only way to end FF.
This bug appears to have been reported against 'rawhide' during the Fedora Linux 38 development cycle. Changing version to 38.
6 months and no reaction at all :(
(In reply to customercare from comment #3) > 6 months and no reaction at all :( Sorry, I have no idea how to handle it.
This message is a reminder that Fedora Linux 38 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 38 on 2024-05-21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '38'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 38 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Martin, has this been fixed in the latest FFs? A way would be to remove ff from the select box to open the content with.
or ... is there a way to check the pid of the "sending" ff when "receiving" ff gets the request to open the "file"/"Content" and see, if it's in the pids of ff?
for the md fileformat this was fixed. working in ff 126.
workaround: about:preferences#general -> apps -> switch to "save files" from "ask if ..."
A final test showed, you can't trick ff into the looping. I think we can close it.