581247 - Remove/fix PrintWindow path in nsObjectFrame::PaintPlugin

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Plug-ins, defect)

Description

[Robert O'Callahan (:roc) (email my personal email if necessary)]

When painting content to a non-screen destination, we try to use PrintWindow to grab the contents of a windowed plugin. In bug 579262 this seemed to cause problems for OOPP. It definitely allows asynchronous NPN_Evaluates to be processed by the content process during painting, because we're doing an (indirect) synchronous call into a plugin during painting but since it's not a normal paint event, our race-resolution logic does not kick in.

We could take out this path altogether, but that would probably be bad since thumbnails etc would lose plugin display.

We could try to replace it with a windowless paint event and hope Flash responds to that even for windowed plugins. I can't remember if that works or not, or how it would go for other plugins.

We could perhaps send a windowless paint event and turn it into a PrintWindow on the plugin-container side.

Comment 1

[[not reading bugmail]]

Attachment: windowed vs windowless testcase

you can use this testcase to check against aero peek previews.

Comment 2

[Benjamin Smedberg]

Resolving old bugs which are likely not relevant any more, since NPAPI plugins are deprecated.