Bug 89499

Summary: [GTK] Scroll offset is applied in the wrong direction for plugins on Windows
Product: WebKit Reporter: Kalev Lember <kalevlember>
Component: WebKitGTKAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal CC: webkit.review.bot
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on: 54531    
Bug Blocks:    
Attachments:
Description Flags
Patch none

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 1 Kalev Lember 2012-06-19 12:49:13 PDT
Created attachment 148393 [details]
Patch
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.