Bug 47545 - [Qt] Right clicking on Flash in windowless mode crashes
Summary: [Qt] Right clicking on Flash in windowless mode crashes
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Plug-ins (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Linux
: P2 Normal
Assignee: Nobody
URL:
Keywords: Qt
Depends on:
Blocks: 69123
  Show dependency treegraph
 
Reported: 2010-10-12 09:54 PDT by Girish Ramakrishnan
Modified: 2011-09-29 21:31 PDT (History)
3 users (show)

See Also:


Attachments
Ignore right click in windowless mode (3.26 KB, patch)
2010-10-12 10:16 PDT, Girish Ramakrishnan
ariya.hidayat: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Girish Ramakrishnan 2010-10-12 09:54:29 PDT
Right clicking on Flash in windowless mode crashes on Linux.
Comment 1 Girish Ramakrishnan 2010-10-12 10:16:39 PDT
Created attachment 70541 [details]
Ignore right click in windowless mode
Comment 2 Ariya Hidayat 2010-10-12 11:51:56 PDT
Will there be a negative effect, i.e. some plugins will not work?
Comment 3 Girish Ramakrishnan 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.
Comment 4 Ariya Hidayat 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.
Comment 5 Robert Hogan 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?
Comment 6 Robert Hogan 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)
Comment 7 Girish Ramakrishnan 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.
Comment 8 Girish Ramakrishnan 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?
Comment 9 Girish Ramakrishnan 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
Comment 10 Robert Hogan 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.
Comment 11 Girish Ramakrishnan 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.
Comment 12 Girish Ramakrishnan 2010-10-12 14:12:41 PDT
Fix for 64-bit landed in r69602
Comment 13 Girish Ramakrishnan 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.
Comment 14 Ademar Reis 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>