WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
Bug 47545
[Qt] Right clicking on Flash in windowless mode crashes
https://bugs.webkit.org/show_bug.cgi?id=47545
Summary
[Qt] Right clicking on Flash in windowless mode crashes
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+
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
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.
Top of Page
Format For Printing
XML
Clone This Bug