Bug 89499 – [GTK] Scroll offset is applied in the wrong direction for plugins on Windows

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKitGTK

[Kalev Lember]

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.

[Kalev Lember]

Created attachment 148393 [details]
Patch

[Brent Fulgham]

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.

[WebKit Review Bot]

Comment on attachment 148393 [details]
Patch

Clearing flags on attachment: 148393

Committed r121441: <http://trac.webkit.org/changeset/121441>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.