With the reworked Windows plugin support in bug #54531, the target rectangle calculation is off when the frame is scrolled. I've split this fix off to a separate patch as I'd like some more scrutiny for this. The issue seems to be caused by PluginViewWin.cpp's PluginView::paint() trying to draw using a wrong coordinate system: the target rect coordinates are converted to window coordinates using FrameView::contentsToWindow(), but this will cause the target rect to move to the opposite direction when scrolling. Apparently the backing store for the GTK+ port uses a different coordinate system than the Windows port (Frame coordinate system? Not sure how to call this.) I've fixed this with #ifdefs in PluginViewWin.cpp, but I'm not sure if this is the right place for applying the fix.
Created attachment 148393 [details] Patch
Comment on attachment 148393 [details] Patch This seems fine to me, and has no possibility of harming the standard Windows build. I don't see an easy way to bundle the implementation differently that would provide any advantage in legibility or maintainability. r=me.
Comment on attachment 148393 [details] Patch Clearing flags on attachment: 148393 Committed r121441: <http://trac.webkit.org/changeset/121441>
All reviewed patches have been landed. Closing bug.