2

For all other browsers that I've tried in both Windows and MacOSX (including Chrome under Windows) using an "iframe shim" works fine. However, I have not been able to get iframe shims to work over our plugin in Chrome on the Mac.

Having Googled the problem, and done some testing, it appears to depend upon the object. I've found an example using StreetView (a flash object) which works, and another example using a Java Applet which does not work.

Some links:

Here's a description of the method: http://www.oratransplant.nl/2007/10/26/using-iframe-shim-to-partly-cover-a-java-applet/

This example using a Java Applet is from the above article: http://www.oratransplant.nl/files/iframe_shim.html

And here's the working version using Streetview: http://gmaps-samples.googlecode.com/svn/trunk/streetview/iframeshim.html

By inspecting (and editing) elements in Chrome and copying the objects between the two example pages, it appears to be that the flash object just allows iframe shims (in Chrome on the Mac), but that the Java Applet does not.

In our case we are using a custom plugin, built with Firebreath.

It may be that I need to implement extra functionality into our plugin, mimicking whatever flash is doing, but this could well be caused by a bug in the Mac build of Chrome.

Can anyone help? We really do want to be able to show HTML elements over our plugin, and the iframe shim works on almost all browser/OS combinations!

Dave Knight
  • 402
  • 3
  • 12

2 Answers2

2

The lack of compositing is a known bug in Mac Chrome with any plugin using Core Animation or Invalidating Core Animation. It will be resolved in some future version--in theory, you should never need an iframe hack on the Mac, and plugins should always composite correctly. If you are interested, you can detect whether compositing of Core Animation is supported dynamically in your plugin using NPN_GetValue with the value 74656 (see WKNVSupportsCompositingCoreAnimationPluginsBool in the WebKit source; this should be added to the formal NPAPI spec soon, but the value won't change, so you can hard-code it now and when Chrome supports it that will start returning true).

In general the iframe hack should work in recent versions of Chrome (what version are you testing?), but there are some bugs where it doesn't get noticed until the page gets a re-layout, so you might want to play with forcing that.

Note that your Streetview example isn't a valid test on Mac Chrome, because it's using wmode=opaque, which means it's using the CG mode, not CA mode, and thus compositing works completely regardless of the iframe hack.

smorgan
  • 20,228
  • 3
  • 47
  • 55
  • Thanks, that makes sense. I was using the latest stable version of Chrome (12.0.742.122). Switching to the beta stream (currently at version 13.0.782.55) actually fixes this issue, so it _will_ be fixed at some future point. – Dave Knight Jul 20 '11 at 16:18
1

What drawing method are you using? You shouldn't need to use an iframe over a plugin on Mac because all drawing is windowless, unless you're doing strange things that I wouldn't expect to be possible with Chrome (i.e. creating an opengl context over a coregraphics or quickdraw context). If you were doing something like that there would probably not be anything you could do.

One easy setting would be to just resize the plugin to 1x1 to effectively "hide" it.

taxilian
  • 14,229
  • 4
  • 34
  • 73
  • 1
    I just checked with one of the Chrome guys; aparently Chrome is not capable of compositing CoreAnimation, so you won't be able to layer anything over it. – taxilian Jul 20 '11 at 15:52