Summary: | [GTK] Full page size flash plugins do not show in all situations | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Juan Pablo Ugarte <juanpablougarte> | ||||||||
Component: | WebKitGTK | Assignee: | Nobody <webkit-unassigned> | ||||||||
Status: | RESOLVED FIXED | ||||||||||
Severity: | Normal | CC: | abarth, commit-queue, gustavo, mrobinson, nicolas | ||||||||
Priority: | P2 | ||||||||||
Version: | 528+ (Nightly build) | ||||||||||
Hardware: | PC | ||||||||||
OS: | Linux | ||||||||||
Attachments: |
|
Description
Juan Pablo Ugarte
2010-10-15 15:03:20 PDT
(In reply to comment #0) > I was not able to find the exact problem, but it seems that flash objects the size of the WebKitWebView or bigger do not show up properly. > They start working after you resize the window. I've run this with trunk revison 69781, and I don't see any issues. This was with Flash player 10.1.85.3. Would it be possible to describe more the issue you see and let us know which version of the Flash player you are running ? (In reply to comment #1) > (In reply to comment #0) > > I was not able to find the exact problem, but it seems that flash objects the size of the WebKitWebView or bigger do not show up properly. > > They start working after you resize the window. > > I've run this with trunk revison 69781, and I don't see any issues. This was with Flash player 10.1.85.3. Would it be possible to describe more the issue you see and let us know which version of the Flash player you are running ? Ok I finally manage to reproduce this bug by moving away from nspluginwrapper. It seems that the widget size allocation does not work very well with the way it is implement right now. Created attachment 74388 [details]
Move widget allocation after NPP_SetWindow
This patch moves the plugin widget size allocation after the
NPP_SetWindow is called with the effect that the resize of Flash
content no longer result in grey flash. This seems logical since the
widget tree cannot be fully constructed before the plugin receives
the new container window.
Comment on attachment 74388 [details]
Move widget allocation after NPP_SetWindow
No test?
(In reply to comment #4) > (From update of attachment 74388 [details]) > No test? If you know a way to write a test for this I'd appreciate, but so far those kind of rendering glitches are really hard to automatically test. I think we may be able to do so by: 1. Creating a window with a fullscreen plugin 2. Scaling down the window 3. Checking that the plugin content is not GTK Theme default color (assuming we have a test plugin that mimics Flash correctly and shows a different color) The problem is mainly about implementing a plugin that mimic the Adobe's Flash player since we don't really know what it's doing. So far I'm pretty sure they use a GtkDrawingArea, but's that's all I know. So my conclusion is that it's probably possible to test this, but it's very time consuming, which as usual is an issue ;) Let me know what you think about all this (assuming you have already read the code a little to take in consideration the level of changes involved too). Note that another way to reproduce this is to Zoom-out pages like youtube.com (assuming you have full zoom enable, and not text zoom). (In reply to comment #5) > (In reply to comment #4) > > (From update of attachment 74388 [details] [details]) > > No test? > > If you know a way to write a test for this I'd appreciate, but so far those kind of rendering glitches are really hard to automatically test. > > I think we may be able to do so by: > 1. Creating a window with a fullscreen plugin > 2. Scaling down the window > 3. Checking that the plugin content is not GTK Theme default color (assuming we have a test plugin that mimics Flash correctly and shows a different color) We have pixel dumping support if that will be useful. (In reply to comment #6) > We have pixel dumping support if that will be useful. I don't think that works with windowed plugin. Is this an issue just for windowed plugins? If so, perhaps it would be enough to have a manual test, given the difficulty of testing this in an automated fashion? Check WebCore/manual-tests/, there are plenty of plugin tests in there. (In reply to comment #8) > Is this an issue just for windowed plugins? If so, perhaps it would be enough to have a manual test, given the difficulty of testing this in an automated fashion? Check WebCore/manual-tests/, there are plenty of plugin tests in there. Yes it's only for windowed plugins. Thanks for the pointer, I'll have a look at those. Created attachment 75936 [details]
Patch
Comment on attachment 75936 [details]
Patch
Okay. I guess this is worth a shot. Thanks for including the test.
Comment on attachment 75936 [details] Patch Clearing flags on attachment: 75936 Committed r73587: <http://trac.webkit.org/changeset/73587> All reviewed patches have been landed. Closing bug. |