Don't try to call setDefersLoading when the loader is null. This does a bit of cleanup so the che...

Don't try to call setDefersLoading when the loader is null. This does a bit of cleanup so the checks for the null-ness of this variable is centralized, and I filed a bug for not having this implemented for main document loads.

TEST=manual
BUG=96727
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=101524

[bbudge, 2011-09-16 00:06:12]

One comment about error codes.

Would you like to assign the TODO to me for the WebKit change to defer document
loads?

http://codereview.chromium.org/7920001/diff/5001/webkit/plugins/ppapi/ppb_url...
File webkit/plugins/ppapi/ppb_url_loader_impl.cc (right):

http://codereview.chromium.org/7920001/diff/5001/webkit/plugins/ppapi/ppb_url...
webkit/plugins/ppapi/ppb_url_loader_impl.cc:102: return PP_ERROR_NOACCESS;
Maybe PP_ERROR_INPROGRESS is a more appropriate error code in this case.

[bbudge, 2011-09-16 00:10:23]

The more I think about it, the more it seems like re-using this class to pass a
main document WebURLLoader to the plugin is a hack. Maybe it would be better to
create a new WebURLLoader class to wrap the document loader.

[bbudge, 2011-09-16 01:05:31]

On 2011/09/16 00:10:23, bbudge1 wrote:
> The more I think about it, the more it seems like re-using this class to pass
a
> main document WebURLLoader to the plugin is a hack. Maybe it would be better
to
> create a new WebURLLoader class to wrap the document loader.

Oh nevermind, I see we must pass a PPB_URLLoader_Impl in HandleDocumentLoad.

[brettw, 2011-09-16 04:32:24]

Actually, if I had my druthers, the Frame could expuse a WebURLLoader
for the frame's request, then we would not have to differentiate
between main document and regular loads at all.

I'm guessing this wasn't done because the WebCore::Frame owns the
loader, which is a different memory management model. If that's the
case, we could have a different mode (or implementation of
WebURLRequest) where the WebFrame and it know about each other and can
manage their memory properly regardless of whatever weird stuff the
client is doing.

Brett

On Thu, Sep 15, 2011 at 5:10 PM,  <bbudge@chromium.org> wrote:
> The more I think about it, the more it seems like re-using this class to
> pass a
> main document WebURLLoader to the plugin is a hack. Maybe it would be better
> to
> create a new WebURLLoader class to wrap the document loader.
>
> http://codereview.chromium.org/7920001/
>

[brettw, 2011-09-16 18:05:40]

New snap up.

http://codereview.chromium.org/7920001/diff/5001/webkit/plugins/ppapi/ppb_url...
File webkit/plugins/ppapi/ppb_url_loader_impl.cc (right):

http://codereview.chromium.org/7920001/diff/5001/webkit/plugins/ppapi/ppb_url...
webkit/plugins/ppapi/ppb_url_loader_impl.cc:102: return PP_ERROR_NOACCESS;
On 2011/09/16 00:06:12, bbudge1 wrote:
> Maybe PP_ERROR_INPROGRESS is a more appropriate error code in this case.

Done.

[bbudge, 2011-09-16 18:11:08]

LGTM