PPAPI: properly track asynchronous load state in URLLoaderResource.

PPAPI: properly track asynchronous load state in URLLoaderResource.

Committed: https://crrev.com/9c1c349e2b890f704e442c1a7be14c6fd8b07838
Cr-Commit-Position: refs/heads/master@{#433051}

[Lei Zhang, 2016-11-17 19:23:58]

The CQ bit was checked by thestig@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-11-17 19:25:25]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Lei Zhang, 2016-11-17 19:28:21]

thestig@chromium.org changed reviewers:
+ bbudge@chromium.org, rbpotter@chromium.org

[Lei Zhang, 2016-11-17 19:28:22]

rbpotter: Please confirm this fixes the problem you are seeing.

bbudge: PTAL. In https://crrev.com/200412, you can see
|is_asynchronous_load_suspended_| can never be true, yet there is code that
checks to see if it is.

I don't know why this was never a problem before, but with some recent PDF
document loader changes, we can hit the state where URLLoaderResource's buffer
is empty, yet it does not ask for more.

[rbpotter, 2016-11-17 20:24:42]

On 2016/11/17 19:28:22, Lei Zhang (Mostly OOO) wrote:
> rbpotter: Please confirm this fixes the problem you are seeing.
> 
> bbudge: PTAL. In https://crrev.com/200412, you can see
> |is_asynchronous_load_suspended_| can never be true, yet there is code that
> checks to see if it is.
> 
> I don't know why this was never a problem before, but with some recent PDF
> document loader changes, we can hit the state where URLLoaderResource's buffer
> is empty, yet it does not ask for more.

Large PDF now loads, though it is a little slow. Thanks!

[bbudge, 2016-11-17 20:41:23]

Yes, that seems obviously broken. I'm wondering why it hasn't caused more
problems. Thanks for the fix.

LGTM

[commit-bot: I haz the power, 2016-11-17 22:35:47]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-11-17 22:35:47]

Dry run: This issue passed the CQ dry run.

[Lei Zhang, 2016-11-17 22:54:19]

The CQ bit was checked by thestig@chromium.org

[commit-bot: I haz the power, 2016-11-17 22:55:32]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Lei Zhang, 2016-11-17 23:18:50]

On 2016/11/17 20:41:23, bbudge wrote:
> Yes, that seems obviously broken. I'm wondering why it hasn't caused more
> problems. Thanks for the fix.

1) It requires a very large PDF to actually hit the problem.
2) Despite recent attempts to improve the PDF loading code, it has in some cases
gotten slower, so URLLoaderResource is more likely to hit the case where it
needs to ask the renderer to stop sending it data, because its buffer is full
and the PDF loader is not retrieving from the buffer fast enough. (To be worked
out separately)

[commit-bot: I haz the power, 2016-11-18 00:38:36]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-11-18 00:38:38]

Failed to apply the patch.

[Lei Zhang, 2016-11-18 01:36:48]

The CQ bit was checked by thestig@chromium.org

[commit-bot: I haz the power, 2016-11-18 01:38:37]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-18 03:18:06]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-11-18 03:22:23]

Description was changed from

==========
PPAPI: properly track asynchronous load state in URLLoaderResource.
==========

to

==========
PPAPI: properly track asynchronous load state in URLLoaderResource.

Committed: https://crrev.com/9c1c349e2b890f704e442c1a7be14c6fd8b07838
Cr-Commit-Position: refs/heads/master@{#433051}
==========

[commit-bot: I haz the power, 2016-11-18 03:22:24]

Patchset 1 (id:??) landed as
https://crrev.com/9c1c349e2b890f704e442c1a7be14c6fd8b07838
Cr-Commit-Position: refs/heads/master@{#433051}