Description of problem: Firefox-21 locks up Version-Release number of selected component (if applicable): firefox-21.0-3.fc18.x86_64 How reproducible: every time Steps to Reproduce: 1. yum update 2. firefox-21 installed 3. open firefox, even in safe mode 4. home page come up, but that's the last thing that works. 5. Even stop does not work. Force close required to exit. Actual results: Completely useless firefox. Expected results: Normally-functioning firefox. Additional info: Machine has upgraded firefox many times in the past, without issues. This uypdate is broken. This is a fully up-to-date Fedora-18-x64 before update. Running "yum update" upgrades firefox and xulrunner, along with a couple of other unassociated updates. Running firefox brings up the home page and the congratulations page on separate tabs as per normal. However, nothing can be clicked on. Exit can only be performed by clicking the close button, waiting for the notice of a non-responding app, and forcing close. Overnight, another minor firefox update was released (update firefox.x86_64 0:21.0-2.fc18 to firefox.x86_64 0:21.0-3.fc18) which does not correct the primary problem. Running "yum downgrade" is the only workable recovery identified. Firefox-17 works normally. Conclusion: Firefox-21 as-built is broken and unusable on Fedora. Side-note 1: Yum db problem: Running "yum downgrade firefox xulrunner" downgrades to firefox-17 for some reason, even though firefox-20 works well. Side note 2: Bugzilla db problem: Firefox-20 is not listed in the releases in Bugzilla, even though it is released.
Thanks for you bug report. Please try to run Firefox in safemode, ie. firefox -safe-mode with fresh profile firefox -ProfileManager. and with upstream binaries: ftp://ftp.mozilla.org/pub/firefox/releases/21.0/linux-x86_64/ Please let us know what is working and what's not from above.
Sorry, I've missed you've already tried safe mode. Please try other suggestions.
By creating a new profile, I reset my home page. The culprit appears to be an inability to render slashdot.org. Visiting slashdot.org locks up Firefox.
Hm, can you replicate this issue with upstream binaries, ie. from: ftp://ftp.mozilla.org/pub/firefox/releases/21.0/linux-x86_64/
The Fedora 20 component was created in error. We only create new Fedora versions when we branch a new release. These bugs are all being moved to rawhide. Please retarget them to 19 if they also apply to the Fedora 19 branched release. Thanks.
I am seeing this behaviour in Firefox 21 update to Fedora 18. It is freezing on multiple websites and if you wait long enough before killing it, Firefox will pop-up numerous Script Unresponsive dialogs listing swf and js files both external and internal (components:). One internal error was something along the lines of nsBlocklist ... could not get/remember more since the dialog wouldn't allow cut and paste.
It might be a flash plugin vs. SELinux issue. I am getting a lot of SELinux denials in /var/log/messages even when I start Firefox in safe-mode. May 21 14:51:45 localhost kernel: [ 6919.749884] type=1400 audit(1369162305.272:41): avc: denied { execute } for pid=6352 comm="plugin-containe" path="/usr/lib64/mozilla/plugins-wrapped/nswrapper_32_64.libflashplayer.so" dev="sda3" ino=1966220 scontext=unconfined_u:unconfined_r:mozilla_plugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:mozilla_plugin_rw_t:s0 tclass=file May 21 14:51:45 localhost kernel: [ 6919.749947] type=1400 audit(1369162305.272:42): avc: denied { execute } for pid=6352 comm="plugin-containe" path="/usr/lib64/mozilla/plugins-wrapped/nswrapper_32_64.libflashplayer.so" dev="sda3" ino=1966220 scontext=unconfined_u:unconfined_r:mozilla_plugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:mozilla_plugin_rw_t:s0 tclass=file May 21 14:52:30 localhost kernel: [ 6964.774283] type=1400 audit(1369162350.319:43): avc: denied { execute } for pid=6355 comm="plugin-containe" path="/usr/lib64/mozilla/plugins-wrapped/nswrapper_32_64.libflashplayer.so" dev="sda3" ino=1966220 scontext=unconfined_u:unconfined_r:mozilla_plugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:mozilla_plugin_rw_t:s0 tclass=file May 21 14:52:30 localhost kernel: [ 6964.774346] type=1400 audit(1369162350.319:44): avc: denied { execute } for pid=6355 comm="plugin-containe" path="/usr/lib64/mozilla/plugins-wrapped/nswrapper_32_64.libflashplayer.so" dev="sda3" ino=1966220 scontext=unconfined_u:unconfined_r:mozilla_plugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:mozilla_plugin_rw_t:s0 tclass=file May 21 14:53:15 localhost kernel: [ 7009.799789] type=1400 audit(1369162395.366:45): avc: denied { execute } for pid=6364 comm="plugin-containe" path="/usr/lib64/mozilla/plugins-wrapped/nswrapper_32_64.libflashplayer.so" dev="sda3" ino=1966220 scontext=unconfined_u:unconfined_r:mozilla_plugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:mozilla_plugin_rw_t:s0 tclass=file May 21 14:53:15 localhost kernel: [ 7009.799853] type=1400 audit(1369162395.366:46): avc: denied { execute } for pid=6364 comm="plugin-containe" path="/usr/lib64/mozilla/plugins-wrapped/nswrapper_32_64.libflashplayer.so" dev="sda3" ino=1966220 scontext=unconfined_u:unconfined_r:mozilla_plugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:mozilla_plugin_rw_t:s0 tclass=file May 21 14:54:00 localhost kernel: [ 7054.814098] type=1400 audit(1369162440.403:47): avc: denied { execute } for pid=6373 comm="plugin-containe" path="/usr/lib64/mozilla/plugins-wrapped/nswrapper_32_64.libflashplayer.so" dev="sda3" ino=1966220 scontext=unconfined_u:unconfined_r:mozilla_plugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:mozilla_plugin_rw_t:s0 tclass=file May 21 14:54:00 localhost kernel: [ 7054.814160] type=1400 audit(1369162440.403:48): avc: denied { execute } for pid=6373 comm="plugin-containe" path="/usr/lib64/mozilla/plugins-wrapped/nswrapper_32_64.libflashplayer.so" dev="sda3" ino=1966220 scontext=unconfined_u:unconfined_r:mozilla_plugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:mozilla_plugin_rw_t:s0 tclass=file
Forcing a relabel did *not* clear things up. Switching SELinux into permissive mode instantly cleared up the issue. Doing some investigation leads to: [root@desktop ~]# tail /var/log/messages |audit2why May 21 15:25:19 localhost kernel: [ 316.249038] type=1400 audit(1369164319.404:9): avc: denied { execute } for pid=2671 comm="plugin-containe" path="/usr/lib64/mozilla/plugins-wrapped/nswrapper_32_64.libflashplayer.so" dev="sda3" ino=1966220 scontext=unconfined_u:unconfined_r:mozilla_plugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:mozilla_plugin_rw_t:s0 tclass=file Was caused by: Missing type enforcement (TE) allow rule. You can use audit2allow to generate a loadable module to allow this access. [root@desktop ~]# tail /var/log/messages |audit2allow #============= mozilla_plugin_t ============== allow mozilla_plugin_t mozilla_plugin_rw_t:file execute; Is this something that should be allowed or is the flash plug-in incorrectly labelled? Also, why did this show up with Firefox 21 and not the previous version. IIRC, the latest flash plugin update recent but was a lot longer ago than my last reboot/browser restart.
IMHO there's some SELinux boolean which should be turned on for flash/pluginwrapper.
If that is the case, I am wondering if some update turned it off since Firefox 20 and below worked fine. There was an old "chcon -t textrel_shlib_t /usr/lib/flash-plugin/libflashplayer.so" fix but that looked like it caused something similar but I cannot find a boolean to tweak that seems relevant.
Downgrading firefox and xulrunner to firefox-20.0-5.fc18/xulrunner-20.0-4.fc18 from Koji seems to have resolved the issue for me on an up to date Fedora 18 x86_64.
Try to uninstall nspluginwrapper (if you don't need wrapped plugins) first. I'm getting similar Selinux reports too, like: SELinux is preventing /usr/lib64/xulrunner/plugin-container from write access on the file cert9.db. However I don't experience UI lockups.
Downgrading to firefox-20.0-5.fc18.x86_64.rpm and xulrunner-20.0-4.fc18.x86_64.rpm from Koji worked for me as well. No more complaints from SELinux and no more freezing with no other changes other than a yum downgrade and a reboot. SELinux is set to "enforcing" again. One thing that I did notice before downgrading was the flash player was not loading properly in that some videos on Youtube would indicate that the flash player was not found but the WebM/HTML5-ized ones would play fine. So Firefox 21 is not playing nicely with the flash plugin and/or plugin wrapper ... on my x86_64 system at least. Now that I know I can work around the issue, I will see if removing nspluginwrapper will more ... however, I am under the impression that the flash plugin needs this glue, no?
rpm -e nspluginwrapper-1.4.4-16.fc18.x86_64 removes the 64 bit portion of the nspluginwrapper (i have both the 64 bit and 32 bit version installed) and that causes the flash plugin not to be loaded (confirmed by about:plugins) and the problem goes away ... except that there are fewer Youtube videos to be seen. When I reinstall it, the flash plugin is loaded and everything locks up as soon as it is used for anything. This only happens in Firefox 21 for me ... Firefox 20 loads the uses the plugin properly. I am not sure how Firefox 21 is using the same plugin and plugin-wrapper differently that causes SELinux to be unhappy. It is consistently spitting out the error: May 29 19:11:02 localhost kernel: [ 3294.127190] type=1400 audit(1369869062.520:13): avc: denied { execute } for pid=4938 comm="plugin-containe" path="/usr/lib64/mozilla/plugins-wrapped/nswrapper_32_64.libflashplayer.so" dev="sda3" ino=1972558 scontext=unconfined_u:unconfined_r:mozilla_plugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:mozilla_plugin_rw_t:s0 tclass=file and that causes Firefox 21 to lock up for me. I am uncertain why this is not more wide-spread unless no one uses enforcing mode :[.
I had this problem, too. The problem is that selinux is preventing nspluginwrapper from doing whatever magic it does. (I personally think that selinux-policy's objection to allowing write and execute to the same thing is pointless, but that's neither here nor there.) The fix is straightforward, though: if you have flash-plugin.i386 and adobe-release-i386 installed, remove them and install the 64-bit versions from: http://get.adobe.com/flashplayer/completion/?installer=Flash_Player_11.2_for_other_Linux_(YUM)_64-bit This works better than the 32-bit wrapped version ever did.
Nspluginwrapper and plugin-container should not run in the same time - both do the same thing, run flash-plugin out of the main firefox process. Which key/values (in about:config) do you have for "dom.ipc.plugins.enabled.nswrapper_32_64.libflashplayer.so" and other dom.ipc.plugins.* ones?
The only dom.ipc.plugins.* keys that I have are: dom.ipc.plugins.enabled;true dom.ipc.plugins.flash.subprocess.crashreporter.enabled;true dom.ipc.plugins.parentTimeoutSecs;0 dom.ipc.plugins.processLaunchTimeoutSecs;45 dom.ipc.plugins.reportCrashURL;true dom.ipc.plugins.timeoutSecs;45 and they are all set to the default value according to config:about. There does not seem to be any key pair listing "nswrapper" present. Thank you Andy for the native 64 bit plugin suggestion. It wasn't working properly when I tried it way back went and I had thought that Adobe had abandoned efforts to develop that. I am happy to give it a try now as I know that the nswrapper thing is a bit of a cludge. If this works, it would be the proper solution. I am still confused as to what changed between Firefox 20 and 21 that triggered the wrapper not playing nicely with SELinux anymore.
Uninstalling the 32-bit flash-plugin and the 32-bit Adobe yum repository (installed long long ago) and replacing it with the 64-bit versions poined out by Andy (which are also pointed to correctly on the Adobe website) now allows me to set SELinux to enforcing with no ill effects. Both versions versions of nspluginwrapper is still installed due to a Citrix plugin needing them ... I suspect the dependencies are a little messed up since it is a 64-bit plugin ... and that will bite me when the time comes that I need that. But for the time being, things work better than ever. Thanks for your help.
*** Bug 981737 has been marked as a duplicate of this bug. ***
This bug appears to have been reported against 'rawhide' during the Fedora 20 development cycle. Changing version to '20'. More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora20
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. 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 Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 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, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.