Don't call NPP_SetWindow during the painting of windowless plugins....

Don't call NPP_SetWindow during the painting of windowless plugins.

On Windows, Flash seems to only start executing script actions after it received an NPP_SetWindow with a 
non-NULL NPWindow.window (HDC). It is possible that Flash then invokes JS to modify DOM of the page.

If Flash movie's widget is on-screen at page load, this call is made during layout and before even the NPP_Write is called,
which is the desired sequence of events.

However, if it is off-screen, this call occurs during painting, which leads to re-entrancy issues (layout while painting)
and bizarre crashes.

As a solution, we remove calls to NPP_SetWindow during painting and instead opt to never provide a null HDC to the plugin.
If no valid HDC is available, we feed it a disposable monochrome 1x1 context to have at least something to draw on.

R=ananta,darin,jam
BUG=16114
TEST=LayoutTests/plugins/flash-setwindow-paint-crash.html (bug reduction).


Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=22383

[darin (slow to review), 2009-07-31 22:43:49]

LGTM

Please add a test... perhaps to chrome/test/plugin/plugin_tests.cpp since that
test framework allows you to exercise flash specific tests.

http://codereview.chromium.org/159717/diff/12/13
File webkit/glue/plugins/webplugin_delegate_impl.cc (right):

http://codereview.chromium.org/159717/diff/12/13#newcode72
Line 72: // is never called with NPNWindoTypeDrawable and NPWindow set to NULL.
nit: NPNWindoTypeDrawable -> NPWindowTypeDrawable

http://codereview.chromium.org/159717/diff/12/13#newcode1007
Line 1007: NPError err = instance()->NPP_SetWindow(&window_);
I think we should add a TODO about the fact that this appears to pass along
"old" values for window_.window, which may be completely junk.  It is really
interesting that this isn't causing problems... or is it? :)

[jam, 2009-07-31 23:50:34]

so if a flash module decided to mess with the dom during paint, we still have
the problem right?

[darin (slow to review), 2009-08-01 01:23:06]

Yeah... but let's hope that they don't do that :-)
-Darin


On Fri, Jul 31, 2009 at 4:50 PM, <jam@chromium.org> wrote:

> so if a flash module decided to mess with the dom during paint, we still
> have the problem right?
>
>
> http://codereview.chromium.org/159717
>

[ananta, 2009-08-01 01:34:11]

LGTM with Darin's comments about a test case addressed. If Safari also suffers
from this bug, then perhaps we can be good citizens and upstream a similar fix
:)

[darin (slow to review), 2009-08-04 16:28:40]

LGTM