Hide Forgot
+++ This bug was initially created as a clone of Bug #662203 +++ Description of problem: When the user clicks with the right mouse button onto a flash animation the browser will freeze. Version-Release number of selected component (if applicable): firefox-3.6.13-2.el6_0.i686 flash-plugin-10.1.102.64-1.el6.i686 How reproducible: Always Steps to Reproduce: 1. Sart Firefox and open a page which contains Flash such as http://www.btv.bg/weather/5day 2. Right click on the flash video (the weather report in the above URL). 3. Actual results: Firefox freezes Expected results: Right-click menu will appear. Additional info: --- Additional comment from atodorov@redhat.com on 2010-12-10 16:02:46 EST --- Right-click works with http://www.youtube.com/watch?v=wyR0cBYUxUQ It's probably something about the website/video that causes the hang. --- Additional comment from stransky@redhat.com on 2010-12-15 05:59:46 EST --- Do you use nspluginwrapper? Can you reproduce it without nspluginwrapper? --- Additional comment from atodorov@redhat.com on 2010-12-15 06:18:59 EST --- I had nspluginwrapper-1.3.0-14.el6.i686 installed. Removing it fixed the issue. --- Additional comment from stransky@redhat.com on 2010-12-15 07:33:56 EST --- Yes, I can reproduce the crash with npsluginwrapper, flash plug-in is struck somewhere in glib when npsluginwrapper is installed. I wonder why... --- Additional comment from stransky@redhat.com on 2010-12-15 07:35:06 EST --- Backtrace of the flash/glib process. #0 0x0027e430 in __kernel_vsyscall () #1 0x010b3df6 in poll () from /lib/libc.so.6 #2 0x007ec64c in g_poll () from /lib/libglib-2.0.so.0 #3 0x007df044 in ?? () from /lib/libglib-2.0.so.0 #4 0x007df7af in g_main_loop_run () from /lib/libglib-2.0.so.0 #5 0x0155ee2b in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so #6 0x01560a55 in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so #7 0x01560bdf in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so #8 0x014ad6f5 in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so #9 0x011c1306 in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so #10 0x011c23e2 in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so #11 0x011b762a in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so #12 0x011bd884 in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so #13 0x0804b4d1 in g_NPP_HandleEvent (connection=0x892baf8) at ../src/npw-viewer.c:4075 #14 handle_NPP_HandleEvent (connection=0x892baf8) at ../src/npw-viewer.c:4102 #15 0x080587b2 in _rpc_dispatch_1 (connection=0x892baf8, message=0xffc438e0) at ../src/rpc.c:1648 #16 0x08058ae0 in _rpc_dispatch (connection=0x892baf8) at ../src/rpc.c:1679 #17 rpc_dispatch (connection=0x892baf8) at ../src/rpc.c:1747 #18 0x0804af62 in rpc_event_dispatch (source=0x892e258, callback=0x8058a40 <rpc_dispatch>, connection=0x892baf8) at ../src/npw-viewer.c:4386 #19 0x007db525 in g_main_context_dispatch () from /lib/libglib-2.0.so.0 #20 0x007df268 in ?? () from /lib/libglib-2.0.so.0 #21 0x007df7af in g_main_loop_run () from /lib/libglib-2.0.so.0 #22 0x00c8a5a9 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 #23 0x0804ebd7 in do_main (argc=<value optimized out>, argv=0xffc45c14) at ../src/npw-viewer.c:4501 #24 main (argc=<value optimized out>, argv=0xffc45c14) at ../src/npw-viewer.c:4675 --- Additional comment from stransky@redhat.com on 2010-12-16 06:25:40 EST --- Well, it's because the two nested glib loops are waiting for the same content, context=0x8582a88 in this case. We need to attach the rpc handler to a different loop. (gdb) bt #0 0x006b0424 in __kernel_vsyscall () #1 0x01091b16 in poll () from /lib/libc.so.6 #2 0x00ba4dac in g_poll (fds=0x85a8110, nfds=2, timeout=9) at gpoll.c:132 #3 0x00b948b7 in g_main_context_poll (context=0x8582a88, block=1, dispatch=1, self=<value optimized out>) at gmain.c:3093 #4 g_main_context_iterate (context=0x8582a88, block=1, dispatch=1, self=<value optimized out>) at gmain.c:2775 #5 0x00b9504b in g_main_loop_run (loop=0x8690fc8) at gmain.c:2988 #6 0x04cdfe2b in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so #7 0x04ce1a55 in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so #8 0x04ce1bdf in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so #9 0x04c2e6f5 in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so #10 0x04942306 in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so #11 0x049433e2 in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so #12 0x0493862a in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so #13 0x0493e884 in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so #14 0x08052473 in g_NPP_HandleEvent (instance=0x85beff0, event=0xbfd6d7f4) at ../src/npw-viewer.c:4075 #15 0x08052531 in handle_NPP_HandleEvent (connection=0x85a5f50) at ../src/npw-viewer.c:4102 #16 0x080596e7 in _rpc_dispatch_1 (connection=0x85a5f50, message=0xbfd6d8f8) at ../src/rpc.c:1648 #17 0x0805979e in _rpc_dispatch (connection=0x85a5f50, message=0xbfd6d8f8) at ../src/rpc.c:1679 #18 0x080599a1 in rpc_dispatch (connection=0x85a5f50) at ../src/rpc.c:1747 #19 0x08052ce0 in rpc_event_dispatch (source=0x85a80c0, callback=0x8059906 <rpc_dispatch>, connection=0x85a5f50) at ../src/npw-viewer.c:4386 #20 0x00b94192 in g_main_dispatch (context=0x8582a88) at gmain.c:2149 #21 g_main_context_dispatch (context=0x8582a88) at gmain.c:2702 #22 0x00b94978 in g_main_context_iterate (context=0x8582a88, block=1, dispatch=1, self=<value optimized out>) at gmain.c:2780 #23 0x00b9504b in g_main_loop_run (loop=0x85a7a80) at gmain.c:2988 #24 0x007f9499 in IA__gtk_main () at gtkmain.c:1237 #25 0x08052f9a in do_main (argc=1, argv=0xbfd6fc44, connection_path= 0xbfd701b0 "/org/wrapper/NSPlugins/libflashplayer.so/10607-3") at ../src/npw-viewer.c:4501 #26 0x0805365e in main (argc=1, argv=0xbfd6fc44) at ../src/npw-viewer.c:4675 (gdb) f #4 g_main_context_iterate (context=0x8582a88, block=1, dispatch=1, self=<value optimized out>) at gmain.c:2775 (gdb) f 20 #20 0x00b94192 in g_main_dispatch (context=0x8582a88) at gmain.c:2149 --- Additional comment from stransky@redhat.com on 2010-12-16 07:16:48 EST --- *** Bug 633004 has been marked as a duplicate of this bug. *** --- Additional comment from stransky@redhat.com on 2010-12-16 07:18:57 EST --- *** Bug 622416 has been marked as a duplicate of this bug. *** --- Additional comment from stransky@redhat.com on 2010-12-16 07:45:29 EST --- *** Bug 236810 has been marked as a duplicate of this bug. ***
*** Bug 607884 has been marked as a duplicate of this bug. ***
Why is this bug the same as 607884? I didn't click on a flash thing at all... Can you explain? Whatever way: please fix the issue as gnash (an alternative) eats way too much cpu.
Severity needs to be higher: The reference flash implementation doesn't work anymore. The alternatives have shortcomings.... The nspluginwrapper issue has been roaring it's head for a while longer than the start date of this bug. (please do google) Flash is an important part of web content...
Can we help to get this fixed? This is a serious problem. flash from adobe with the wrapper worked soso, but now it doesn't work at all; gnash eats cpu and doesn't work in all cases so what else can we do?
The gtk_main() from nspluginwrapper has to be replaced by something what won't block the event loop when g_main_loop_run() is launched fem flash plugin with the same context. Mozilla uses it's own message loop which does not block so it may be a solution for nspluginwrapper too.
Thanks for the info. Who will make the necessary changes?
What is being done? We aren't even answered what we can do. Our flash isn't working without a decent workaround!
udo, From your comment to Bug 607884 (and here), I think you are experiencing a different bug. Bug 607884, this bug, and its duplicates look to be all flash "right click" related bugs and setting "dom.ipc.plugins.enabled=true" in about:config appears to be an effective workaround. Taken from your previous comment to Bug 607884, I did a search for: "pk-gtk-module flash" (without the quotes) and it returned many bug reports and message board posts that look to be more related to your bug. Such as http://forum.nginx.org/read.php?30,137977 http://fedoraproject.org/wiki/Flash#After_Fedora_upgrade.2Fpreupgrade and many others. I hope this helps.
Bruce, Thanks for the research. So I removed gnash-plugin, reinstalled flash-plugin and nspluginwrapper. about:plugins showed the intended situation. I get: (npviewer.bin:4438): Gtk-WARNING **: Unable to locate theme engine in module_path: "clearlooks", *** NSPlugin Wrapper *** WARNING:(../src/npw-wrapper.c:1858):invoke_NPP_Destroy: assertion failed: (rpc_method_invoke_possible(plugin->connection)) *** NSPlugin Wrapper *** ERROR: NPP_Write() wait for reply: Message timeout *** NSPlugin Wrapper *** WARNING:(../src/npw-wrapper.c:2239):invoke_NPP_DestroyStream: assertion failed: (rpc_method_invoke_possible(plugin->connection)) And a grey youtube screen. Or are the cookies we disabled for gnash so important for adobe's flash?
Without nspluginwrapper everything works fine here.
*** Bug 658225 has been marked as a duplicate of this bug. ***
The hang isn't related to main loops or anything. Flash (or maybe even GTK) is requesting a grab that is supposed to succeed and doesn't. It then gets confused. The thing that makes the youtube video different from the page in question is that the page uses a windowed plugin which causes events to be plumbed to the plugin differently. The failed grab is caused by a combination of an nspluginwrapper bug (if you could call it that) and how X11 input grabs work that makes out-of-process plugins difficult. Arguably NPAPI should have provided a hook for the plugin to request the grab from the browser, but no one would have used it anyway (as it would preclude you from opening the menu with GTK). See this patch. https://github.com/davidben/nspluginwrapper/commit/662820f46b8c37b938cc1dc71f5ab76bac750c21 The fix is somewhat of a hack (the point of doing the passive -> active grab thing is to avoid some UI race conditions), but I'm not sure a better solution is possible in the X protocol. This is also what Firefox does.
> that the page uses a windowed plugin Sorry, the page uses a windowless plugin. A windowed plugin bypasses the browser and gives the passive grab straight to the Flash plugin and everything just works.
nspluginwrapper-1.3.2-1.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/nspluginwrapper-1.3.2-1.fc15
Package nspluginwrapper-1.3.2-1.fc15: * should fix your issue, * was pushed to the Fedora 15 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing nspluginwrapper-1.3.2-1.fc15' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/nspluginwrapper-1.3.2-1.fc15 then log in and leave karma (feedback).
nspluginwrapper-1.3.2-1.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.
nspluginwrapper-1.3.2-1.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/nspluginwrapper-1.3.2-1.fc14
nspluginwrapper-1.3.2-1.fc13 has been submitted as an update for Fedora 13. https://admin.fedoraproject.org/updates/nspluginwrapper-1.3.2-1.fc13
nspluginwrapper-1.3.2-1.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
nspluginwrapper-1.3.2-1.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.