Closed Bug 581247 Opened 12 years ago Closed 5 years ago

Remove/fix PrintWindow path in nsObjectFrame::PaintPlugin

Categories

(Core :: Plug-ins, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: roc, Unassigned)

Details

Attachments

(1 file)

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.
you can use this testcase to check against aero peek previews.
Resolving old bugs which are likely not relevant any more, since NPAPI plugins are deprecated.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.