If you scroll a page with a QuickTime plugin, the movie will get drawn at the wrong location, and leave detritus. The widget code should not leave the port bits locked (LockPortBits) over calls to plugins.

The LockPortBits issue only affects Firefox, not Camino. Camino still has scrolling issues. Looking at the webkit source, I see a private QuickDraw function, CallDrawingNotifications(), which WebKit uses to work around QuickTime scrolling issues (unrelated to LockPortBits). Its signature is void CallDrawingNotifications(CGrafPtr port, Rect *mayDrawIntoThisRect, int drawingType); and WebKit calls it with the bounds of the port, and drawingType=8 (kBitsProc, according to cvs annotate -r 1.127.8.2 WebBaseNetscapePluginView.m We should try calling this after scrolling to see if it helps with the shearing.

Anyone have a test URL for this, preferably that works with QT6? (There must be tons, but I can't find one!) Also: Simon, do you mean to indicate that we need to deal with that QuickTime scrolling issue called out in WebKit in addition to unlocking the port bits when we poke the plugin? This is a pretty tragic quality-of-experience issue for Mac users, it'd be really nice to see if there's a safe-enough fix for Fx2.

Josh - any chance you can take a look.

I don't see this with Firefox 1.5.0.4 or BonEcho Alpha 2, and I haven't seen it in a long time in any other normal browsing. I need better repro instructions (maybe a URL?) in order to do anything about this.

I'm not seeing this either anymore, although I'm unsure if that's because QT got upgraded or if it's something we did. Please re-open if you can come up with STR.

well here http://www.apple.com/getamac/ads/ no detritus. apparently. though switching to another tab keeps the currently showing frame until you scroll both directions to get rid of it. i think that's a diff bug though.