Bug 39889 - [Windows] Scroll offset being applied to plugins during print operation
Summary: [Windows] Scroll offset being applied to plugins during print operation
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit Misc. (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Windows XP
: P2 Normal
Assignee: Brent Fulgham
Depends on:
Reported: 2010-05-28 11:23 PDT by Brent Fulgham
Modified: 2013-03-26 15:35 PDT (History)
6 users (show)

See Also:

Patch (3.76 KB, patch)
2010-05-28 11:38 PDT, Brent Fulgham
no flags Details | Formatted Diff | Diff
Patch (1.45 KB, patch)
2010-05-28 12:01 PDT, Brent Fulgham
no flags Details | Formatted Diff | Diff
Patch (1.60 KB, patch)
2011-06-17 18:16 PDT, Brent Fulgham
andersca: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Brent Fulgham 2010-05-28 11:23:09 PDT
The existing logic for handling printing for windowed plugins computes the
page position based on the current page scroll.  This is incorrect, as the
printed page is never in a scrolled state.  With the current code, scrolling
the page and then printing causes the plugin to draw in different positions
depending on the scroll state.
Comment 1 Brent Fulgham 2010-05-28 11:36:46 PDT
The Windows implementation of PluginView::paintWindowedPluginIntoContext
is only used during print and print preview operations for windowed
plugins.  The drawing location passed to the plugin is computed
based on the current scroll position, which is wrong for printing
operations as the page position is always the same.
Comment 2 Brent Fulgham 2010-05-28 11:38:06 PDT
Created attachment 57353 [details]
Comment 3 Brent Fulgham 2010-05-28 12:01:54 PDT
Created attachment 57358 [details]
Comment 4 Eric Seidel (no email) 2010-05-30 11:21:47 PDT
Don't we have ways to test printing changes like this these days?
Comment 5 Shinichiro Hamaji 2010-05-30 22:23:24 PDT
I guess this patch changes pixel output but doesn't change render tree, right? If so, we cannot test this patch without Bug 20011.
Comment 6 Adam Roben (:aroben) 2010-05-31 12:39:32 PDT
We should get Anders and/or Jon to look at this.
Comment 7 Nikolas Zimmermann 2010-07-30 23:19:46 PDT
Comment on attachment 57358 [details]

We have printing tests these days - Brent can you create a testcase?
Comment 8 Brent Fulgham 2011-06-17 18:16:48 PDT
Created attachment 97676 [details]
Comment 9 Brent Fulgham 2013-03-26 15:35:31 PDT
Wow!  This one got lost in the shuffle.

Landed under https://trac.webkit.org/changeset/146941.