392620 - Should plugin views be non-opaque?

Status: UNCONFIRMED

(Core :: Widget: Cocoa, defect)

Description

[Stuart Morgan]

We've pretty much always returned YES for plugin ChildViews. Given all the discussion in bug 166932 (particularly https://bugzilla.mozilla.org/show_bug.cgi?id=166932#c16), I'm wondering if that's part of why plugins are so messed up (drawing across tabs, freaking out during scrolling, etc.).

Perhaps we should always return NO for NSQD-based plugins? Seems worth testing--although the checkin comment for the original code says to make them opaque "since they don't need to draw", so perhaps I'm confused about plugin drawing. Simon, any thoughts?

Comment 1

[Simon Fraser [no longer active]]

This stuff:
http://lxr.mozilla.org/mozilla/source/widget/src/cocoa/nsChildView.mm#2213
needs to be cleaned up now that NSQuickDrawView is no longer being used. You need to purge the code of ALL QuickDraw calls.

Once you've done that, then revisit plugins. They'll probably still draw all over the place. I suggest looking at the WebKit code to see what they do for QD-based plugins.

Comment 2

[Josh Aas]

How are we supposed to support QD-based plugins if we purge all QD calls from our codebase? Are you talking about some glorious time in the future when we can actually do that?

WebKit uses the same QD calls we do...

http://trac.webkit.org/projects/webkit/browser/trunk/WebKit/Plugins/WebBaseNetscapePluginView.mm

Comment 3

[Simon Fraser [no longer active]]

You want to avoid making any QD calls until you need to. I assume that WebKit only makes a WebBaseNetscapePluginView when it needs to host an NPAPI plug-in. You should do something similar. Making QD calls causes your window to fall off the fast drawing path.

Comment 4

[Håkan Waara]

An idea, maybe plugin-views could be a subclass of ChildView so we can separate out plugin-specific code from other widgets (e.g. the top-level ChildView)?