Bug 47545

Summary: [Qt] Right clicking on Flash in windowless mode crashes
Product: WebKit Reporter: Girish Ramakrishnan <girish>
Component: Plug-insAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal CC: ademar, ariya.hidayat, robert
Priority: P2 Keywords: Qt
Version: 528+ (Nightly build)   
Hardware: PC   
OS: Linux   
Bug Depends on:    
Bug Blocks: 69123    
Attachments:
Description Flags
Ignore right click in windowless mode ariya.hidayat: review+

Girish Ramakrishnan
Reported 2010-10-12 09:54:29 PDT
Right clicking on Flash in windowless mode crashes on Linux.
Attachments
Ignore right click in windowless mode (3.26 KB, patch)
2010-10-12 10:16 PDT, Girish Ramakrishnan
ariya.hidayat: review+
Girish Ramakrishnan
Comment 1 2010-10-12 10:16:39 PDT
Created attachment 70541 [details] Ignore right click in windowless mode
Ariya Hidayat
Comment 2 2010-10-12 11:51:56 PDT
Will there be a negative effect, i.e. some plugins will not work?
Girish Ramakrishnan
Comment 3 2010-10-12 12:13:48 PDT
(In reply to comment #2) > Will there be a negative effect, i.e. some plugins will not work? There will be no negative effect. The quirk is enabled only for Flash (and only on linux) and Flash's context menu is primarily used for settings. Chrome appears to do the same btw - http://www.communitymx.com/content/source/E5141/wmodetrans.htm. Firefox crashes.
Ariya Hidayat
Comment 4 2010-10-12 12:16:19 PDT
Comment on attachment 70541 [details] Ignore right click in windowless mode > The quirk is enabled only for Flash (and only on linux) .. Maybe useful to add this in the ChangeLog? otherwise, LGTM.
Robert Hogan
Comment 5 2010-10-12 12:19:42 PDT
I think we should establish why it crashes and, if this change is the only way of fixing it, explain why in the changelog. To my limited knowledge plugins on Linux are generally windowed so would it be possible to point to a test cases where the crash can be reproduced or to provide a backtrace?
Robert Hogan
Comment 6 2010-10-12 12:26:05 PDT
(In reply to comment #3) > (In reply to comment #2) > > Will there be a negative effect, i.e. some plugins will not work? > > http://www.communitymx.com/content/source/E5141/wmodetrans.htm. Firefox crashes. It doesn't for me! (Mozilla Firefox 3.6.10)
Girish Ramakrishnan
Comment 7 2010-10-12 12:29:21 PDT
(In reply to comment #5) > I think we should establish why it crashes and, if this change is the only way of fixing it, explain why in the changelog. > > To my limited knowledge plugins on Linux are generally windowed so would it be possible to point to a test cases where the crash can be reproduced or to provide a backtrace? The crash is in Flash and there is nothing we can do. gdb output is not meaninful since it just shows some ??? in flash code. In essence, we give Flash the right-click event and it just locks up. strace seems to suggest that it's waiting in a select() call. The behavior is easily reproducible - Goto www.communitymx.com/content/source/E5141/wmodetrans.htm. Right click on the ball. Chrome disables right click. Firefox 3.6.10 (64-bit) crashes. As for windowed/windowless, we force all Flash to windowless mode with QGraphicsWebView. So, right now, if you right click on Flash on QGraphicsWebView, you will crash.
Girish Ramakrishnan
Comment 8 2010-10-12 12:29:58 PDT
(In reply to comment #6) > (In reply to comment #3) > > (In reply to comment #2) > > > Will there be a negative effect, i.e. some plugins will not work? > > > > http://www.communitymx.com/content/source/E5141/wmodetrans.htm. Firefox crashes. > > It doesn't for me! (Mozilla Firefox 3.6.10) 32-bit or 64-bit?
Girish Ramakrishnan
Comment 9 2010-10-12 12:42:34 PDT
Here's the backtrace. 64-bit linux and Shockwave Flash 10.1 r85 #0 0x00007ffff42702c3 in select () at ../sysdeps/unix/syscall-template.S:82 #1 0x00007fffdd654cc1 in ?? () from /var/lib/flashplugin-installer/npwrapper.libflashplayer.so #2 0x00007fffdd655f99 in ?? () from /var/lib/flashplugin-installer/npwrapper.libflashplayer.so #3 0x00007fffdd656f39 in ?? () from /var/lib/flashplugin-installer/npwrapper.libflashplayer.so #4 0x00007fffdd65736e in ?? () from /var/lib/flashplugin-installer/npwrapper.libflashplayer.so #5 0x00007fffdd6575d7 in ?? () from /var/lib/flashplugin-installer/npwrapper.libflashplayer.so #6 0x00007fffdd64f5b5 in ?? () from /var/lib/flashplugin-installer/npwrapper.libflashplayer.so #7 0x00007ffff756fc37 in WebCore::PluginView::dispatchNPEvent(_XEvent&) () from /home/girish/Qt/qtwebkit/WebKitBuild/Release/bin/../lib/libQtWebKit.so.4 #8 0x00007ffff7572279 in WebCore::PluginView::handleMouseEvent(WebCore::MouseEvent*) () from /home/girish/Qt/qtwebkit/WebKitBuild/Release/bin/../lib/libQtWebKit.so.4 #9 0x00007ffff73e0b50 in WebCore::PluginView::handleEvent(WebCore::Event*) () from /home/girish/Qt/qtwebkit/WebKitBuild/Release/bin/../lib/libQtWebKit.so.4 #10 0x00007ffff711bd0f in WebCore::Node::dispatchGenericEvent(WTF::PassRefPtr<WebCore::Event>) () from /home/girish/Qt/qtwebkit/WebKitBuild/Release/bin/../lib/libQtWebKit.so.4 #11 0x00007ffff711c0fa in WebCore::Node::dispatchEvent(WTF::PassRefPtr<WebCore::Event>) () from /home/girish/Qt/qtwebkit/WebKitBuild/Release/bin/../lib/libQtWebKit.so.4
Robert Hogan
Comment 10 2010-10-12 13:07:12 PDT
(In reply to comment #9) > Here's the backtrace. > > 64-bit linux and Shockwave Flash 10.1 r85 > I'm on 32 bit. I wonder does it crash at all there? Here is the chromium bug: http://code.google.com/p/chromium/issues/detail?id=42883 The bug is now marked as invalid because they can no longer recreate it. Maybe a recent minor version of flash fixed it. (The last poster gives details) If we could confirm that the issue is fixed in the version of flash the last poster quotes we could special-case this quirk to a given version. I agree this is safe to commit but it would be ideal if we could version-control the quirk.
Girish Ramakrishnan
Comment 11 2010-10-12 13:21:22 PDT
(In reply to comment #10) > (In reply to comment #9) > > Here's the backtrace. > > > > 64-bit linux and Shockwave Flash 10.1 r85 > > > > I'm on 32 bit. I wonder does it crash at all there? > > Here is the chromium bug: > > http://code.google.com/p/chromium/issues/detail?id=42883 > > The bug is now marked as invalid because they can no longer recreate it. Maybe a recent minor version of flash fixed it. (The last poster gives details) > > If we could confirm that the issue is fixed in the version of flash the last poster quotes we could special-case this quirk to a given version. > > I agree this is safe to commit but it would be ideal if we could version-control the quirk. Ok, I will go ahead and add the quirk only for 64-bit. I will a. check and commit 32-bit behavior. b. check and version control the quirk if it's fixed in latest flash version in 64-bit.
Girish Ramakrishnan
Comment 12 2010-10-12 14:12:41 PDT
Fix for 64-bit landed in r69602
Girish Ramakrishnan
Comment 13 2010-10-12 21:51:55 PDT
On further investigation: 1. This bug happens with nspluginwrapper. With the latest Shockwave Flash 10.2 d161 32-bit on my 64-bit linux, I am able to reproduce the problem. So quirk is required for this case. 2. With the latest Shockwave Flash 10.2 d161 64-bit, it does not freeeze. Nothing happens. It shows no context menu either. IMO, let's just leave the quirk turned on. There's no major problem with the absence of the context menu AFAIK. (Besides, differentiating between above cases just adds to code complexity). If anyone is experiencing this problem on 32-bit, please let me know and we can remove the special case for the 64-bit check.
Ademar Reis
Comment 14 2010-10-22 05:43:33 PDT
Revision r69602 cherry-picked into qtwebkit-2.1 with commit e273313 <http://gitorious.org/webkit/qtwebkit/commit/e273313>
Note You need to log in before you can comment on or make changes to this bug.