|Summary:||[GTK] Scroll offset is applied in the wrong direction for plugins on Windows|
|Product:||WebKit||Reporter:||Kalev Lember <kalevlember>|
|Version:||528+ (Nightly build)|
|Bug Depends on:||54531|
Description Kalev Lember 2012-06-19 12:46:30 PDT
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.
Comment 2 Brent Fulgham 2012-06-28 10:19:03 PDT
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 3 WebKit Review Bot 2012-06-28 11:00:56 PDT
Comment on attachment 148393 [details] Patch Clearing flags on attachment: 148393 Committed r121441: <http://trac.webkit.org/changeset/121441>
Comment 4 WebKit Review Bot 2012-06-28 11:01:01 PDT
All reviewed patches have been landed. Closing bug.