Avoid OOB memcpy in chrome_pdf::CopyImage.

Avoid OOB memcpy in chrome_pdf::CopyImage.

This is a re-work of palmer's patch at https://codereview.chromium.org/515023002/ which has more context, but comes down to stricter bounds checking.

We also correct an arithmetic bug when copying the image behind a control that is positioned before the origin of the image.

BUG=398384
Committed: https://crrev.com/d734d197bb5462a65c37b17594a8c8d07dd79bc1
Cr-Commit-Position: refs/heads/master@{#293213}

[Tom Sepez, 2014-08-29 18:14:06]

tsepez@chromium.org changed reviewers:
+ gene@chromium.org, raymes@chromium.org

[Tom Sepez, 2014-08-29 18:14:46]

Reviewers, please review:
@gene - for context from previous patch
@raymes - for OWNERS stamp.

[gene, 2014-08-29 18:23:46]

lgtm

[Tom Sepez, 2014-08-29 21:14:07]

Meh.  Looks like this is causing some repaint failures (black bars while
scrolling). Stay tuned.

[Tom Sepez, 2014-08-29 21:33:37]

On 2014/08/29 21:14:07, Tom Sepez wrote:
> Meh.  Looks like this is causing some repaint failures (black bars while
> scrolling). Stay tuned.
Ok, Fixed.  Typo lead to using wrong object's size() method.  Everybody got's a
size method here.

[gene, 2014-08-29 21:36:07]

good catch, thanks!

lgtm

[Tom Sepez, 2014-08-29 23:26:30]

I dug a little deeper into why we're getting negative numbers in the first
place, and it turns out theres  a subtraction going the wrong way.  See the bug
entry for details.  Note that we still need protection from negative numbers in
the draw_utils, since the new code can produce this when the control is entirely
beyond the page.

Slowly reducing the iframe size in of the test case for the bug show that the
new code produces visually the right output.

[raymes, 2014-09-01 00:42:17]

https://codereview.chromium.org/519873002/diff/40001/ppapi/cpp/image_data.h
File ppapi/cpp/image_data.h (right):

https://codereview.chromium.org/519873002/diff/40001/ppapi/cpp/image_data.h#n...
ppapi/cpp/image_data.h:139: bool Contains(const pp::Rect& rect) const;
Technically this is a change to the public API. We haven't needed this in the
long history of pp::ImageData, do you think we will start to need it a lot more?
If not, I think it might be better just to move a helper function into the place
where it's used. 

What do you think? :)

[Tom Sepez, 2014-09-02 17:19:03]

> What do you think? :)
I think we can avoid the public API change.

[Tom Sepez, 2014-09-02 17:48:21]

Raymes, please re-review.

[raymes, 2014-09-03 00:29:22]

Thanks - it looks ok but I didn't review it in detail. I defer to gene@ :)

[Tom Sepez, 2014-09-03 17:37:23]

@gene - we good to go?  Thanks.

[gene, 2014-09-03 17:52:19]

good to go!
lgtm

[Tom Sepez, 2014-09-03 19:08:48]

The CQ bit was checked by tsepez@chromium.org

[commit-bot: I haz the power, 2014-09-03 19:10:53]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/tsepez@chromium.org/519873002/80001

[commit-bot: I haz the power, 2014-09-03 23:18:56]

Committed patchset #5 (id:80001) as cd5d372f682e9034e6cac5afebaf976506ff5d25

[commit-bot: I haz the power, 2014-09-10 03:28:17]

Patchset 5 (id:??) landed as
https://crrev.com/d734d197bb5462a65c37b17594a8c8d07dd79bc1
Cr-Commit-Position: refs/heads/master@{#293213}