Emmy Huang points us at a long overdue technote about the infamous Shockwave 3d offset bug. For those of you who are blissfuly unaware about the bug, here's the thing:

Safari, or indeed any other browser using the Apple's WebCore framework for OS X, renders hardware accellerated (OpenGL) content 20 pixels too heigh, even over browser window elements such as toolbars or the title bar of a bare popup.

The Director team has decided not to put their limited resources into working around the bug, since it is a bug in Apple's framework. Unfortunately, Shockwave seems to be the only plugin affected, so it is Director that's looking bad, and ultimately content providers like me. As a result all of us developers must try to special-case Safari (though we don't have the proper hooks to do so), and render 3d content 20 pixels lower to compensate for the bug. This is what I am doing in the SPi-V engine.

This bug has been persisted ever since the first version of Safari. Unfortunately, instead of fixing it in the OS X 10.4 aka Tiger, the bug has escalated to render the content 20 or 51 pixels too heigh depending on whether the adress bar is shown. It seems this is no longer something the Director team can work around.

As an interesting aside, I found out that the additional 31 pixels in Tiger seem to be a bug in Safari 2.0, not in WebCore. The upgrade from 10.3 to 10.4 on my mac mini left Safari 1.3 untouched, so I have a choice between Safari 1.3 and Safari 2.0 on my system. Safari 1.3 renders Shockwave 3d content with the good old 20 pixel offset, wether the address bar is shown or not. Are you listening Dave Hyatt? There's a bug in your browser! I know it's not juicy CSS, but could you please fix it?

Anyway, back to the technote. The technote suggests to switch back to software rendering.

Switching the 3D Renderer setting to use "Software" instead of "OpenGL" will display the 3D sprite without the offset, however, performance might decrease when using the Software Renderer.

'might'? Oh come on! If it just might affect performance, then why are we bothering with hardware acceleration at all? There is another workaround that, in my tests, is quicker than using software rendering. Turning off the Direct To Stage property of the 3d sprite and/or member also fixes the 3d rendering offset, and while this still decreases performance it seems to be noticably faster than using software rendering, at least for my fillrate expensive application.

But neither workaround is something you'ld want to force upon everybody, just because the Safari/Shockwave combo is buggy. Unfortunately, the technote does not include and easy way to detect the browser a Shockwave movie is running in. Perhaps that's because there is no easy way to do that. One way would be to use browser-side Javascript to communicate with the Shockwave movie, but this would make including a Shockwave movie into HTML more complicated. Here's the Lingo-only workaround I am using in SPi-V:

-- Retreives navigator.userAgent from 
-- the browser and forgets itself

property parent
property pNetID

on new me, _parent
  parent = _parent 
  
  pNetID=getNetText("javascript:navigator.userAgent")
  
  parent.pSprite.scriptInstanceList.add(me)
  return me
end new

on exitFrame me
  if netDone(pNetID) then
    parent.pBrowserAgent = string(netTextResult(pNetID))
    parent.updateRect()
    parent.pSprite.scriptInstanceList.deleteOne(me)  
  end if
end exitFrame

Update: The bug in Safari/Webkit may have been fixed!