Refactor FileSystem

Refactor FileSystem.

Add global FileSystem registry for new FileSystem Support later.  New file system will need to implement PepperFileSystemRegistry::FileSystemPeeker for FileRef to access.

Due to the fact that 1) FileSystem and FileRef are tightly couple, 2) we wants to move both of them to browser together, there are two temporary changes in this CL.

1. webkit/plugins/ppapi/ppb_file_ref_impl.cc needs some delegation to access content::PepperFileSystemHost.  The delegation code should be removed after FileRef is moved to content.

2. PepperFileSystemHost stays in renderer for now, and will be moved to browser together in the FileRef refactoring.

Also, NullFileSystemCallbackDispatcher is added with default NOTREACHED callbacks.

TEST=browser_tests --gtest_filter='*PPAPI*.*File*'
BUG=227033
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=193995

[victorhsieh, 2013-04-08 19:25:09]

FYI, I add a PepperFileSystemRegistry for supporting adding new file systems. 
New file system will need to implement
PepperFileSystemRegistry::FileSystemPeeker for FileRef to access.

[yzshen1, 2013-04-08 19:34:57]

On 2013/04/08 19:25:09, Victor Hsieh wrote:
> FYI, I add a PepperFileSystemRegistry for supporting adding new file systems. 
> New file system will need to implement
> PepperFileSystemRegistry::FileSystemPeeker for FileRef to access.

I think it is better to make that a separate CL. It is not part of the
refactoring work, right?

[victorhsieh, 2013-04-08 20:42:01]

On 2013/04/08 19:34:57, yzshen1 wrote:
> On 2013/04/08 19:25:09, Victor Hsieh wrote:
> > FYI, I add a PepperFileSystemRegistry for supporting adding new file
systems. 
> > New file system will need to implement
> > PepperFileSystemRegistry::FileSystemPeeker for FileRef to access.
> 
> I think it is better to make that a separate CL. It is not part of the
> refactoring work, right?

OK.  Let me delete patch set 2.

[yzshen1, 2013-04-08 21:05:15]

https://codereview.chromium.org/13726024/diff/5001/content/renderer/pepper/co...
File content/renderer/pepper/content_renderer_pepper_host_factory.cc (right):

https://codereview.chromium.org/13726024/diff/5001/content/renderer/pepper/co...
content/renderer/pepper/content_renderer_pepper_host_factory.cc:54: if
(!PpapiHostMsg_FileSystem_Create::Read(&message, &msg_params)) {
Please use UnpackMessage() defined in ppapi_message_utils.h.

https://codereview.chromium.org/13726024/diff/5001/content/renderer/pepper/nu...
File content/renderer/pepper/null_file_system_callback_dispatcher.h (right):

https://codereview.chromium.org/13726024/diff/5001/content/renderer/pepper/nu...
content/renderer/pepper/null_file_system_callback_dispatcher.h:23: : public
fileapi::FileSystemCallbackDispatcher {
I wonder why fileapi::FileSystemCallbackDispatcher has to declare pure virtual
methods.
Maybe we could ask the owner to see whether it makes sense to merge this class
into  fileapi::FileSystemCallbackDispatcher? (Except the Ppapi-specific
DidFail() method.)

https://codereview.chromium.org/13726024/diff/5001/content/renderer/pepper/nu...
content/renderer/pepper/null_file_system_callback_dispatcher.h:63: virtual void
DidFail(int pp_error) {
- Please use a different name instead of overloading.
- Please use int32_t for error values.

https://codereview.chromium.org/13726024/diff/5001/content/renderer/pepper/pe...
File content/renderer/pepper/pepper_directory_reader_host.cc (right):

https://codereview.chromium.org/13726024/diff/5001/content/renderer/pepper/pe...
content/renderer/pepper/pepper_directory_reader_host.cc:67: virtual void
DidFail(int pp_error) OVERRIDE {
int32_t, please.

https://codereview.chromium.org/13726024/diff/5001/content/renderer/pepper/pe...
File content/renderer/pepper/pepper_file_io_host.cc (left):

https://codereview.chromium.org/13726024/diff/5001/content/renderer/pepper/pe...
content/renderer/pepper/pepper_file_io_host.cc:85: callback_.Run(error_code);
Did you miss one?

https://codereview.chromium.org/13726024/diff/5001/content/renderer/pepper/pe...
File content/renderer/pepper/pepper_file_system_host.cc (right):

https://codereview.chromium.org/13726024/diff/5001/content/renderer/pepper/pe...
content/renderer/pepper/pepper_file_system_host.cc:9: #include
"base/memory/weak_ptr.h"
You already include it in the .h file (and line 14).

https://codereview.chromium.org/13726024/diff/5001/content/renderer/pepper/pe...
content/renderer/pepper/pepper_file_system_host.cc:33: : weak_host_(weak_host)
{}
wrong indent.

https://codereview.chromium.org/13726024/diff/5001/content/renderer/pepper/pe...
content/renderer/pepper/pepper_file_system_host.cc:37: virtual void
DidOpenFileSystem(const std::string& name_unused,
Please use /* */ around unused parameters otherwise you will get compiler
warnings.

https://codereview.chromium.org/13726024/diff/5001/content/renderer/pepper/pe...
content/renderer/pepper/pepper_file_system_host.cc:62: called_open_(false) {
You should init opened_

https://codereview.chromium.org/13726024/diff/5001/content/renderer/pepper/pe...
content/renderer/pepper/pepper_file_system_host.cc:83:
host()->SendReply(reply_context_,
Please reset reply_context_.

https://codereview.chromium.org/13726024/diff/5001/content/renderer/pepper/pe...
File content/renderer/pepper/pepper_file_system_host.h (right):

https://codereview.chromium.org/13726024/diff/5001/content/renderer/pepper/pe...
content/renderer/pepper/pepper_file_system_host.h:12: #include
"content/public/renderer/renderer_ppapi_host.h"
Please move this to the .cc file, you have forward declaration for it.

https://codereview.chromium.org/13726024/diff/5001/content/renderer/pepper/pe...
content/renderer/pepper/pepper_file_system_host.h:18: using
ppapi::host::ReplyMessageContext;
no using in .h files, please.

https://codereview.chromium.org/13726024/diff/5001/content/renderer/pepper/pe...
content/renderer/pepper/pepper_file_system_host.h:26: public
ppapi::host::ResourceHost,
Wrong indent.

https://codereview.chromium.org/13726024/diff/5001/content/renderer/pepper/pe...
content/renderer/pepper/pepper_file_system_host.h:43: std::string GetRootUrl()
const { return root_url_; }
Shall we use GURL instead of std::string?

https://codereview.chromium.org/13726024/diff/5001/content/renderer/pepper/pe...
content/renderer/pepper/pepper_file_system_host.h:45: void
OpenFileSystemReply(int pp_error,
It could be private method.

Please always use int32_t for pp error values.

https://codereview.chromium.org/13726024/diff/5001/content/renderer/pepper/pe...
File content/renderer/pepper/pepper_plugin_delegate_impl.cc (right):

https://codereview.chromium.org/13726024/diff/5001/content/renderer/pepper/pe...
content/renderer/pepper/pepper_plugin_delegate_impl.cc:344: template <typename
HostT>
nit: It seems better to use full name HostType.

https://codereview.chromium.org/13726024/diff/5001/content/renderer/pepper/pe...
content/renderer/pepper/pepper_plugin_delegate_impl.cc:349: if (!resource||
!ppapi_host)
Missing space before ||.

https://codereview.chromium.org/13726024/diff/5001/content/renderer/pepper/pe...
content/renderer/pepper/pepper_plugin_delegate_impl.cc:1048: return host ?
host->GetRootUrl() : "";
nit: please use std::string() instead of "".

https://codereview.chromium.org/13726024/diff/5001/ppapi/proxy/file_system_re...
File ppapi/proxy/file_system_resource.h (right):

https://codereview.chromium.org/13726024/diff/5001/ppapi/proxy/file_system_re...
ppapi/proxy/file_system_resource.h:16: #include
"ppapi/shared_impl/tracked_callback.h"
Now that you have forward declaration below, you could move it to the .cc file.

https://codereview.chromium.org/13726024/diff/5001/ppapi/thunk/ppb_file_ref_t...
File ppapi/thunk/ppb_file_ref_thunk.cc (right):

https://codereview.chromium.org/13726024/diff/5001/ppapi/thunk/ppb_file_ref_t...
ppapi/thunk/ppb_file_ref_thunk.cc:27: EnterResourceNoLock<PPB_FileSystem_API>
enter_file_system(file_system, false);
nit: shall we use 'true' instead of 'false' here?

https://codereview.chromium.org/13726024/diff/5001/webkit/plugins/ppapi/mock_...
File webkit/plugins/ppapi/mock_plugin_delegate.cc (right):

https://codereview.chromium.org/13726024/diff/5001/webkit/plugins/ppapi/mock_...
webkit/plugins/ppapi/mock_plugin_delegate.cc:173: return "";
nit: it is preferred to use std::string().

https://codereview.chromium.org/13726024/diff/5001/webkit/plugins/ppapi/ppb_f...
File webkit/plugins/ppapi/ppb_file_ref_impl.cc (right):

https://codereview.chromium.org/13726024/diff/5001/webkit/plugins/ppapi/ppb_f...
webkit/plugins/ppapi/ppb_file_ref_impl.cc:13: #include "ppapi/c/pp_file_info.h"
This include is already in the .h file. You don't need to include it again.

https://codereview.chromium.org/13726024/diff/5001/webkit/plugins/ppapi/ppb_f...
webkit/plugins/ppapi/ppb_file_ref_impl.cc:395: DCHECK(delegate);
Why we DCHECK here while testing NULL elsewhere?

https://codereview.chromium.org/13726024/diff/5001/webkit/plugins/ppapi/ppb_f...
File webkit/plugins/ppapi/ppb_file_ref_impl.h (right):

https://codereview.chromium.org/13726024/diff/5001/webkit/plugins/ppapi/ppb_f...
webkit/plugins/ppapi/ppb_file_ref_impl.h:83: PP_Resource file_system_;
Could you please comment that this is a 'plugin-side' PP_Resource that we don't
hold a reference to?

One problem here is that because PPB_FileRef_Impl is not able to hold a
reference to the file system PP_Resource. The file system resource may die
earlier than this object if the plugin doesn't explicitly hold references to it.
And then subsequent operations will fail.

If FileRef has switched to the new design, we could let the FileRefResource
obejct (at the plugin process) hold a ref to the file system PP_Resource. 
However, because PPB_FileRef is still using the old design, it is complicated to
manipulate the ref count of the file system PP_Resource: we need to decide
whether FileRef_Impl is created for out-of-process or in-process plugins: for
the former case, the plugin-side proxy should hold a ref; for the latter case,
the impl itself should hold a ref.

The approach to hold a linked_ptr<ResourceHost> was also considered, but it has
a problem: once the PP_Resource goes away, it is removed from the mapping in
PpapiHost and then PpapiHost::GetResourceHost(PP_Resource resource) won't return
the object, so the code in plugin_delegate_impl won't work.

[yzshen1, 2013-04-08 21:06:21]

Thanks!

Also +CC Raymes who is interested in this patch.


On Mon, Apr 8, 2013 at 1:42 PM, <[email protected]> wrote:

> On 2013/04/08 19:34:57, yzshen1 wrote:
>
>> On 2013/04/08 19:25:09, Victor Hsieh wrote:
>> > FYI, I add a PepperFileSystemRegistry for supporting adding new file
>>
> systems.
>
>> > New file system will need to implement
>> > PepperFileSystemRegistry::**FileSystemPeeker for FileRef to access.
>>
>
>  I think it is better to make that a separate CL. It is not part of the
>> refactoring work, right?
>>
>
> OK.  Let me delete patch set 2.
>
>
https://codereview.chromium.**org/13726024/<https://codereview.chromium.org/1...
>

[victorhsieh, 2013-04-08 23:44:37]

PTAL

https://codereview.chromium.org/13726024/diff/5001/content/renderer/pepper/co...
File content/renderer/pepper/content_renderer_pepper_host_factory.cc (right):

https://codereview.chromium.org/13726024/diff/5001/content/renderer/pepper/co...
content/renderer/pepper/content_renderer_pepper_host_factory.cc:54: if
(!PpapiHostMsg_FileSystem_Create::Read(&message, &msg_params)) {
On 2013/04/08 21:05:16, yzshen1 wrote:
> Please use UnpackMessage() defined in ppapi_message_utils.h.

Done.

https://codereview.chromium.org/13726024/diff/5001/content/renderer/pepper/nu...
File content/renderer/pepper/null_file_system_callback_dispatcher.h (right):

https://codereview.chromium.org/13726024/diff/5001/content/renderer/pepper/nu...
content/renderer/pepper/null_file_system_callback_dispatcher.h:63: virtual void
DidFail(int pp_error) {
On 2013/04/08 21:05:16, yzshen1 wrote:
> - Please use a different name instead of overloading.
> - Please use int32_t for error values.

Done.

https://codereview.chromium.org/13726024/diff/5001/content/renderer/pepper/pe...
File content/renderer/pepper/pepper_directory_reader_host.cc (right):

https://codereview.chromium.org/13726024/diff/5001/content/renderer/pepper/pe...
content/renderer/pepper/pepper_directory_reader_host.cc:67: virtual void
DidFail(int pp_error) OVERRIDE {
On 2013/04/08 21:05:16, yzshen1 wrote:
> int32_t, please.

Done.

https://codereview.chromium.org/13726024/diff/5001/content/renderer/pepper/pe...
File content/renderer/pepper/pepper_file_io_host.cc (left):

https://codereview.chromium.org/13726024/diff/5001/content/renderer/pepper/pe...
content/renderer/pepper/pepper_file_io_host.cc:85: callback_.Run(error_code);
On 2013/04/08 21:05:16, yzshen1 wrote:
> Did you miss one?

Thanks for catching.

And I removed ExecutePlatformWillWriteCallback as it's exactly same as
ExecutePlatformWriteCallback.

https://codereview.chromium.org/13726024/diff/5001/content/renderer/pepper/pe...
File content/renderer/pepper/pepper_file_system_host.cc (right):

https://codereview.chromium.org/13726024/diff/5001/content/renderer/pepper/pe...
content/renderer/pepper/pepper_file_system_host.cc:9: #include
"base/memory/weak_ptr.h"
On 2013/04/08 21:05:16, yzshen1 wrote:
> You already include it in the .h file (and line 14).

Done.

https://codereview.chromium.org/13726024/diff/5001/content/renderer/pepper/pe...
content/renderer/pepper/pepper_file_system_host.cc:33: : weak_host_(weak_host)
{}
On 2013/04/08 21:05:16, yzshen1 wrote:
> wrong indent.

Done.

https://codereview.chromium.org/13726024/diff/5001/content/renderer/pepper/pe...
content/renderer/pepper/pepper_file_system_host.cc:37: virtual void
DidOpenFileSystem(const std::string& name_unused,
On 2013/04/08 21:05:16, yzshen1 wrote:
> Please use /* */ around unused parameters otherwise you will get compiler
> warnings. 

Done.

https://codereview.chromium.org/13726024/diff/5001/content/renderer/pepper/pe...
content/renderer/pepper/pepper_file_system_host.cc:62: called_open_(false) {
On 2013/04/08 21:05:16, yzshen1 wrote:
> You should init opened_

Done.

https://codereview.chromium.org/13726024/diff/5001/content/renderer/pepper/pe...
content/renderer/pepper/pepper_file_system_host.cc:83:
host()->SendReply(reply_context_,
On 2013/04/08 21:05:16, yzshen1 wrote:
> Please reset reply_context_.

Done.

https://codereview.chromium.org/13726024/diff/5001/content/renderer/pepper/pe...
File content/renderer/pepper/pepper_file_system_host.h (right):

https://codereview.chromium.org/13726024/diff/5001/content/renderer/pepper/pe...
content/renderer/pepper/pepper_file_system_host.h:12: #include
"content/public/renderer/renderer_ppapi_host.h"
On 2013/04/08 21:05:16, yzshen1 wrote:
> Please move this to the .cc file, you have forward declaration for it.

Done.

https://codereview.chromium.org/13726024/diff/5001/content/renderer/pepper/pe...
content/renderer/pepper/pepper_file_system_host.h:18: using
ppapi::host::ReplyMessageContext;
On 2013/04/08 21:05:16, yzshen1 wrote:
> no using in .h files, please.

Done.

https://codereview.chromium.org/13726024/diff/5001/content/renderer/pepper/pe...
content/renderer/pepper/pepper_file_system_host.h:26: public
ppapi::host::ResourceHost,
On 2013/04/08 21:05:16, yzshen1 wrote:
> Wrong indent.

Done.

https://codereview.chromium.org/13726024/diff/5001/content/renderer/pepper/pe...
content/renderer/pepper/pepper_file_system_host.h:43: std::string GetRootUrl()
const { return root_url_; }
On 2013/04/08 21:05:16, yzshen1 wrote:
> Shall we use GURL instead of std::string?

Done.  I made it a string to avoid sending GURL through IPC, but I think we can
keep it a GURL here now.

https://codereview.chromium.org/13726024/diff/5001/content/renderer/pepper/pe...
content/renderer/pepper/pepper_file_system_host.h:45: void
OpenFileSystemReply(int pp_error,
On 2013/04/08 21:05:16, yzshen1 wrote:
> It could be private method.
> 
> Please always use int32_t for pp error values.

It's put in public to allow PlatformCallbackAdaptor (in .cc) to access.  We
could move the class to .h and make it a friend if you prefer this way.

https://codereview.chromium.org/13726024/diff/5001/content/renderer/pepper/pe...
File content/renderer/pepper/pepper_plugin_delegate_impl.cc (right):

https://codereview.chromium.org/13726024/diff/5001/content/renderer/pepper/pe...
content/renderer/pepper/pepper_plugin_delegate_impl.cc:344: template <typename
HostT>
On 2013/04/08 21:05:16, yzshen1 wrote:
> nit: It seems better to use full name HostType.

Done.

https://codereview.chromium.org/13726024/diff/5001/content/renderer/pepper/pe...
content/renderer/pepper/pepper_plugin_delegate_impl.cc:349: if (!resource||
!ppapi_host)
On 2013/04/08 21:05:16, yzshen1 wrote:
> Missing space before ||.

Done.

https://codereview.chromium.org/13726024/diff/5001/content/renderer/pepper/pe...
content/renderer/pepper/pepper_plugin_delegate_impl.cc:1048: return host ?
host->GetRootUrl() : "";
On 2013/04/08 21:05:16, yzshen1 wrote:
> nit: please use std::string() instead of "".

Done.

https://codereview.chromium.org/13726024/diff/5001/ppapi/proxy/file_system_re...
File ppapi/proxy/file_system_resource.h (right):

https://codereview.chromium.org/13726024/diff/5001/ppapi/proxy/file_system_re...
ppapi/proxy/file_system_resource.h:16: #include
"ppapi/shared_impl/tracked_callback.h"
On 2013/04/08 21:05:16, yzshen1 wrote:
> Now that you have forward declaration below, you could move it to the .cc
file.

Done.

https://codereview.chromium.org/13726024/diff/5001/ppapi/thunk/ppb_file_ref_t...
File ppapi/thunk/ppb_file_ref_thunk.cc (right):

https://codereview.chromium.org/13726024/diff/5001/ppapi/thunk/ppb_file_ref_t...
ppapi/thunk/ppb_file_ref_thunk.cc:27: EnterResourceNoLock<PPB_FileSystem_API>
enter_file_system(file_system, false);
On 2013/04/08 21:05:16, yzshen1 wrote:
> nit: shall we use 'true' instead of 'false' here?

Done.

https://codereview.chromium.org/13726024/diff/5001/webkit/plugins/ppapi/mock_...
File webkit/plugins/ppapi/mock_plugin_delegate.cc (right):

https://codereview.chromium.org/13726024/diff/5001/webkit/plugins/ppapi/mock_...
webkit/plugins/ppapi/mock_plugin_delegate.cc:173: return "";
On 2013/04/08 21:05:16, yzshen1 wrote:
> nit: it is preferred to use std::string().

Done.

https://codereview.chromium.org/13726024/diff/5001/webkit/plugins/ppapi/ppb_f...
File webkit/plugins/ppapi/ppb_file_ref_impl.cc (right):

https://codereview.chromium.org/13726024/diff/5001/webkit/plugins/ppapi/ppb_f...
webkit/plugins/ppapi/ppb_file_ref_impl.cc:13: #include "ppapi/c/pp_file_info.h"
On 2013/04/08 21:05:16, yzshen1 wrote:
> This include is already in the .h file. You don't need to include it again.

Done.

https://codereview.chromium.org/13726024/diff/5001/webkit/plugins/ppapi/ppb_f...
webkit/plugins/ppapi/ppb_file_ref_impl.cc:395: DCHECK(delegate);
On 2013/04/08 21:05:16, yzshen1 wrote:
> Why we DCHECK here while testing NULL elsewhere?

I don't know. Fixed :P

https://codereview.chromium.org/13726024/diff/5001/webkit/plugins/ppapi/ppb_f...
File webkit/plugins/ppapi/ppb_file_ref_impl.h (right):

https://codereview.chromium.org/13726024/diff/5001/webkit/plugins/ppapi/ppb_f...
webkit/plugins/ppapi/ppb_file_ref_impl.h:83: PP_Resource file_system_;
On 2013/04/08 21:05:16, yzshen1 wrote:
> Could you please comment that this is a 'plugin-side' PP_Resource that we
don't
> hold a reference to?
> 
> One problem here is that because PPB_FileRef_Impl is not able to hold a
> reference to the file system PP_Resource. The file system resource may die
> earlier than this object if the plugin doesn't explicitly hold references to
it.
> And then subsequent operations will fail.
> 
> If FileRef has switched to the new design, we could let the FileRefResource
> obejct (at the plugin process) hold a ref to the file system PP_Resource. 
> However, because PPB_FileRef is still using the old design, it is complicated
to
> manipulate the ref count of the file system PP_Resource: we need to decide
> whether FileRef_Impl is created for out-of-process or in-process plugins: for
> the former case, the plugin-side proxy should hold a ref; for the latter case,
> the impl itself should hold a ref.
> 
> The approach to hold a linked_ptr<ResourceHost> was also considered, but it
has
> a problem: once the PP_Resource goes away, it is removed from the mapping in
> PpapiHost and then PpapiHost::GetResourceHost(PP_Resource resource) won't
return
> the object, so the code in plugin_delegate_impl won't work.

Comment added.  It should be safe now as plugin delegate checks the resource
existence before using it, and looks like we don't need to workaround this now? 
Let me know if I'm wrong.

[yzshen1, 2013-04-09 17:25:42]

https://codereview.chromium.org/13726024/diff/5001/content/renderer/pepper/pe...
File content/renderer/pepper/pepper_file_system_host.h (right):

https://codereview.chromium.org/13726024/diff/5001/content/renderer/pepper/pe...
content/renderer/pepper/pepper_file_system_host.h:45: void
OpenFileSystemReply(int pp_error,
It is fine to leave it as it is.
On 2013/04/08 23:44:38, Victor Hsieh wrote:
> On 2013/04/08 21:05:16, yzshen1 wrote:
> > It could be private method.
> > 
> > Please always use int32_t for pp error values.
> 
> It's put in public to allow PlatformCallbackAdaptor (in .cc) to access.  We
> could move the class to .h and make it a friend if you prefer this way.

https://codereview.chromium.org/13726024/diff/5001/webkit/plugins/ppapi/ppb_f...
File webkit/plugins/ppapi/ppb_file_ref_impl.h (right):

https://codereview.chromium.org/13726024/diff/5001/webkit/plugins/ppapi/ppb_f...
webkit/plugins/ppapi/ppb_file_ref_impl.h:83: PP_Resource file_system_;
Let's discuss offline. It is too long to type. :)
On 2013/04/08 23:44:38, Victor Hsieh wrote:
> On 2013/04/08 21:05:16, yzshen1 wrote:
> > Could you please comment that this is a 'plugin-side' PP_Resource that we
> don't
> > hold a reference to?
> > 
> > One problem here is that because PPB_FileRef_Impl is not able to hold a
> > reference to the file system PP_Resource. The file system resource may die
> > earlier than this object if the plugin doesn't explicitly hold references to
> it.
> > And then subsequent operations will fail.
> > 
> > If FileRef has switched to the new design, we could let the FileRefResource
> > obejct (at the plugin process) hold a ref to the file system PP_Resource. 
> > However, because PPB_FileRef is still using the old design, it is
complicated
> to
> > manipulate the ref count of the file system PP_Resource: we need to decide
> > whether FileRef_Impl is created for out-of-process or in-process plugins:
for
> > the former case, the plugin-side proxy should hold a ref; for the latter
case,
> > the impl itself should hold a ref.
> > 
> > The approach to hold a linked_ptr<ResourceHost> was also considered, but it
> has
> > a problem: once the PP_Resource goes away, it is removed from the mapping in
> > PpapiHost and then PpapiHost::GetResourceHost(PP_Resource resource) won't
> return
> > the object, so the code in plugin_delegate_impl won't work.
> 
> Comment added.  It should be safe now as plugin delegate checks the resource
> existence before using it, and looks like we don't need to workaround this
now? 
> Let me know if I'm wrong.

https://codereview.chromium.org/13726024/diff/22001/content/renderer/pepper/n...
File content/renderer/pepper/null_file_system_callback_dispatcher.h (right):

https://codereview.chromium.org/13726024/diff/22001/content/renderer/pepper/n...
content/renderer/pepper/null_file_system_callback_dispatcher.h:64: virtual void
OnError(int32_t pp_error) {
Please see my comment in pepper_file_io_host.cc about getting rid of this method
entirely.

If we really want to keep it, I think the name is not consistent with the other
methods. I cannot come up with a name that is consistent && short && informative
&& different from DidFail(). Maybe we should stick to DidFail(). Sorry. :)

https://codereview.chromium.org/13726024/diff/22001/content/renderer/pepper/p...
File content/renderer/pepper/pepper_file_io_host.cc (right):

https://codereview.chromium.org/13726024/diff/22001/content/renderer/pepper/p...
content/renderer/pepper/pepper_file_io_host.cc:63: virtual void OnError(int32_t
pp_error) OVERRIDE {
I think this OnError() actually complicates things and is error-prone. For
example, you are mixing PlatformFileError and pp errors (line 60 and line 64).
Besides, you have to have ExecutePlatformGeneralCallback and
ExecuteGeneralCallback.

I suggest to go back to the previous implementation of using
DidFail(base::PlatformFileError).

https://codereview.chromium.org/13726024/diff/22001/content/renderer/pepper/p...
File content/renderer/pepper/pepper_file_system_host.cc (right):

https://codereview.chromium.org/13726024/diff/22001/content/renderer/pepper/p...
content/renderer/pepper/pepper_file_system_host.cc:41: virtual void
DidFail(int32_t pp_error) OVERRIDE {
Please see my comment about DidFail() elsewhere.

[victorhsieh, 2013-04-09 18:02:45]

Also, NullFileSystemCallbackDispatcher inline implementation is now split to .cc
as we don't inline virtual.

https://codereview.chromium.org/13726024/diff/5001/content/renderer/pepper/nu...
File content/renderer/pepper/null_file_system_callback_dispatcher.h (right):

https://codereview.chromium.org/13726024/diff/5001/content/renderer/pepper/nu...
content/renderer/pepper/null_file_system_callback_dispatcher.h:23: : public
fileapi::FileSystemCallbackDispatcher {
On 2013/04/08 21:05:16, yzshen1 wrote:
> I wonder why fileapi::FileSystemCallbackDispatcher has to declare pure virtual
> methods.
> Maybe we could ask the owner to see whether it makes sense to merge this class
> into  fileapi::FileSystemCallbackDispatcher? (Except the Ppapi-specific
> DidFail() method.)

As discussed offline, we'll keep this as it is (and should be refactored
together with fileapi side).

https://codereview.chromium.org/13726024/diff/22001/content/renderer/pepper/n...
File content/renderer/pepper/null_file_system_callback_dispatcher.h (right):

https://codereview.chromium.org/13726024/diff/22001/content/renderer/pepper/n...
content/renderer/pepper/null_file_system_callback_dispatcher.h:64: virtual void
OnError(int32_t pp_error) {
On 2013/04/09 17:25:42, yzshen1 wrote:
> Please see my comment in pepper_file_io_host.cc about getting rid of this
method
> entirely.
> 
> If we really want to keep it, I think the name is not consistent with the
other
> methods. I cannot come up with a name that is consistent && short &&
informative
> && different from DidFail(). Maybe we should stick to DidFail(). Sorry. :)
> 

Done.  Remove the conversion.

https://codereview.chromium.org/13726024/diff/22001/content/renderer/pepper/p...
File content/renderer/pepper/pepper_file_io_host.cc (right):

https://codereview.chromium.org/13726024/diff/22001/content/renderer/pepper/p...
content/renderer/pepper/pepper_file_io_host.cc:63: virtual void OnError(int32_t
pp_error) OVERRIDE {
On 2013/04/09 17:25:42, yzshen1 wrote:
> I think this OnError() actually complicates things and is error-prone. For
> example, you are mixing PlatformFileError and pp errors (line 60 and line 64).
> Besides, you have to have ExecutePlatformGeneralCallback and
> ExecuteGeneralCallback.
> 
> I suggest to go back to the previous implementation of using
> DidFail(base::PlatformFileError).

Agree.  I think it's because there are two kinds of access in this file.  One is
to call platform version, and the other calls delegate.  Reverted to original
implementation to make it simple.

https://codereview.chromium.org/13726024/diff/22001/content/renderer/pepper/p...
File content/renderer/pepper/pepper_file_system_host.cc (right):

https://codereview.chromium.org/13726024/diff/22001/content/renderer/pepper/p...
content/renderer/pepper/pepper_file_system_host.cc:41: virtual void
DidFail(int32_t pp_error) OVERRIDE {
On 2013/04/09 17:25:42, yzshen1 wrote:
> Please see my comment about DidFail() elsewhere.

Done.

[victorhsieh, 2013-04-09 19:41:46]

Brett, could you please review following files for owner approval?
 content/content_renderer.gypi
 webkit/glue/webkit_glue.gypi

Julian, could you please review following files for security review?
  ppapi/proxy/ppapi_messages.h

Thanks.

[brettw, 2013-04-09 19:55:15]

gypi lgtm

[victorhsieh, 2013-04-10 19:07:10]

PTAL

https://codereview.chromium.org/13726024/diff/5001/webkit/plugins/ppapi/ppb_f...
File webkit/plugins/ppapi/ppb_file_ref_impl.h (right):

https://codereview.chromium.org/13726024/diff/5001/webkit/plugins/ppapi/ppb_f...
webkit/plugins/ppapi/ppb_file_ref_impl.h:83: PP_Resource file_system_;
On 2013/04/09 17:25:42, yzshen1 wrote:
> Let's discuss offline. It is too long to type. :)
> On 2013/04/08 23:44:38, Victor Hsieh wrote:
> > On 2013/04/08 21:05:16, yzshen1 wrote:
> > > Could you please comment that this is a 'plugin-side' PP_Resource that we
> > don't
> > > hold a reference to?
> > > 
> > > One problem here is that because PPB_FileRef_Impl is not able to hold a
> > > reference to the file system PP_Resource. The file system resource may die
> > > earlier than this object if the plugin doesn't explicitly hold references
to
> > it.
> > > And then subsequent operations will fail.
> > > 
> > > If FileRef has switched to the new design, we could let the
FileRefResource
> > > obejct (at the plugin process) hold a ref to the file system PP_Resource. 
> > > However, because PPB_FileRef is still using the old design, it is
> complicated
> > to
> > > manipulate the ref count of the file system PP_Resource: we need to decide
> > > whether FileRef_Impl is created for out-of-process or in-process plugins:
> for
> > > the former case, the plugin-side proxy should hold a ref; for the latter
> case,
> > > the impl itself should hold a ref.
> > > 
> > > The approach to hold a linked_ptr<ResourceHost> was also considered, but
it
> > has
> > > a problem: once the PP_Resource goes away, it is removed from the mapping
in
> > > PpapiHost and then PpapiHost::GetResourceHost(PP_Resource resource) won't
> > return
> > > the object, so the code in plugin_delegate_impl won't work.
> > 
> > Comment added.  It should be safe now as plugin delegate checks the resource
> > existence before using it, and looks like we don't need to workaround this
> now? 
> > Let me know if I'm wrong.
> 

Done.  Please verify the implementation is correct or not.

[yzshen1, 2013-04-11 17:04:57]

https://codereview.chromium.org/13726024/diff/40001/content/renderer/pepper/n...
File content/renderer/pepper/null_file_system_callback_dispatcher.cc (right):

https://codereview.chromium.org/13726024/diff/40001/content/renderer/pepper/n...
content/renderer/pepper/null_file_system_callback_dispatcher.cc:19: const
base::PlatformFileInfo& file_info,
You probably should put /**/ around parameters to avoid 'unused parameter'
warnings.

https://codereview.chromium.org/13726024/diff/40001/content/renderer/pepper/n...
File content/renderer/pepper/null_file_system_callback_dispatcher.h (right):

https://codereview.chromium.org/13726024/diff/40001/content/renderer/pepper/n...
content/renderer/pepper/null_file_system_callback_dispatcher.h:46: virtual void
DidFail(base::PlatformFileError platform_error) OVERRIDE;
Move this out of private?

https://codereview.chromium.org/13726024/diff/40001/content/renderer/pepper/p...
File content/renderer/pepper/pepper_file_io_host.cc (right):

https://codereview.chromium.org/13726024/diff/40001/content/renderer/pepper/p...
content/renderer/pepper/pepper_file_io_host.cc:48: typedef base::Callback<void
(int32_t)> PlatformGeneralCallback;
I think it is better to use PlatformFileError instead of int32_t here, because:
- it is more consistent, platform in the name indicates that the parameter is
base::PlatformFileError.

- if you make this change, you need to have both
ExecutePlatformGeneralCallback() and ExecuteGeneralCallback().

The previous code looks simpler. I am not sure why we need this change.

https://codereview.chromium.org/13726024/diff/40001/webkit/plugins/ppapi/reso...
File webkit/plugins/ppapi/resource_creation_impl.cc (right):

https://codereview.chromium.org/13726024/diff/40001/webkit/plugins/ppapi/reso...
webkit/plugins/ppapi/resource_creation_impl.cc:92: res->AddFileSystemRefCount();
This method will also get run for the renderer side in out-of-process mode. So
it doesn't work. (Have you tested this code? Am I missing anything?)

I think one way is to check RendererPpapiHost::IsRunningInProcess(), if yes, you
will need to add ref for the FileSystem in PPB_FileRef_Impl.

https://code.google.com/p/chromium/codesearch#chromium/src/content/public/ren...

(You will need some work to expose this to code in webkit/plugins/, though.)

[victorhsieh, 2013-04-11 18:24:38]

PTAL

https://codereview.chromium.org/13726024/diff/40001/content/renderer/pepper/n...
File content/renderer/pepper/null_file_system_callback_dispatcher.cc (right):

https://codereview.chromium.org/13726024/diff/40001/content/renderer/pepper/n...
content/renderer/pepper/null_file_system_callback_dispatcher.cc:19: const
base::PlatformFileInfo& file_info,
On 2013/04/11 17:04:57, yzshen1 wrote:
> You probably should put /**/ around parameters to avoid 'unused parameter'
> warnings.

Done.

https://codereview.chromium.org/13726024/diff/40001/content/renderer/pepper/n...
File content/renderer/pepper/null_file_system_callback_dispatcher.h (right):

https://codereview.chromium.org/13726024/diff/40001/content/renderer/pepper/n...
content/renderer/pepper/null_file_system_callback_dispatcher.h:46: virtual void
DidFail(base::PlatformFileError platform_error) OVERRIDE;
On 2013/04/11 17:04:57, yzshen1 wrote:
> Move this out of private?

Done.

https://codereview.chromium.org/13726024/diff/40001/content/renderer/pepper/p...
File content/renderer/pepper/pepper_file_io_host.cc (right):

https://codereview.chromium.org/13726024/diff/40001/content/renderer/pepper/p...
content/renderer/pepper/pepper_file_io_host.cc:48: typedef base::Callback<void
(int32_t)> PlatformGeneralCallback;
On 2013/04/11 17:04:57, yzshen1 wrote:
> I think it is better to use PlatformFileError instead of int32_t here,
because:
> - it is more consistent, platform in the name indicates that the parameter is
> base::PlatformFileError.

Actually it's a pp_error.

> 
> - if you make this change, you need to have both
> ExecutePlatformGeneralCallback() and ExecuteGeneralCallback().
> 
> The previous code looks simpler. I am not sure why we need this change.

I started this change when checking other files.  Lots of
FileSystemCallbackDispatchers just implement one or two methods and put
NOTREACHED in others (in this case, 6).  And almost all of them (except this
one) repeat to convert the file from platform error to pp error.  So I extract
the new class.  But turned out this class is different from others.

We can remove Null* if you think it's better.  I'm fine with both ways as
fileapi callback api will be changed later.

https://codereview.chromium.org/13726024/diff/40001/ppapi/proxy/ppapi_messages.h
File ppapi/proxy/ppapi_messages.h (right):

https://codereview.chromium.org/13726024/diff/40001/ppapi/proxy/ppapi_message...
ppapi/proxy/ppapi_messages.h:1409: std::string /* root_url */)
Removed root_url as it's not needed now.  So this is just an ACK.

https://codereview.chromium.org/13726024/diff/40001/webkit/plugins/ppapi/reso...
File webkit/plugins/ppapi/resource_creation_impl.cc (right):

https://codereview.chromium.org/13726024/diff/40001/webkit/plugins/ppapi/reso...
webkit/plugins/ppapi/resource_creation_impl.cc:92: res->AddFileSystemRefCount();
On 2013/04/11 17:04:57, yzshen1 wrote:
> This method will also get run for the renderer side in out-of-process mode. So
> it doesn't work. (Have you tested this code? Am I missing anything?)
> 
> I think one way is to check RendererPpapiHost::IsRunningInProcess(), if yes,
you
> will need to add ref for the FileSystem in PPB_FileRef_Impl.
> 
>
https://code.google.com/p/chromium/codesearch#chromium/src/content/public/ren...
> 
> (You will need some work to expose this to code in webkit/plugins/, though.)

I thought this is only used in process (only used by
pepper_in_process_resource_creation.cc)?

[victorhsieh, 2013-04-11 18:39:20]

Julian,

I think this refactoring doesn't change the attach surface much.  I put some
review comment in message.h.  Please let me know if you need to know more about
them.  Thanks.

https://codereview.chromium.org/13726024/diff/46003/ppapi/proxy/ppapi_messages.h
File ppapi/proxy/ppapi_messages.h (right):

https://codereview.chromium.org/13726024/diff/46003/ppapi/proxy/ppapi_message...
ppapi/proxy/ppapi_messages.h:795: PP_Instance /* instance */,
For security review: HostResource contains a pp_instance and pp_resource.  In
the new design, we don't use HostResource, so I expand the struct.

https://codereview.chromium.org/13726024/diff/46003/ppapi/proxy/ppapi_message...
ppapi/proxy/ppapi_messages.h:1404:
IPC_MESSAGE_CONTROL1(PpapiHostMsg_FileSystem_Create,
For security review: Create and Open are just a refactoring change, with less or
equal parameters.

https://codereview.chromium.org/13726024/diff/46003/ppapi/proxy/ppapi_message...
ppapi/proxy/ppapi_messages.h:1408:
IPC_MESSAGE_CONTROL0(PpapiPluginMsg_FileSystem_OpenReply)
For security review: This is a message that simply indicates success or failure.

[victorhsieh, 2013-04-11 19:29:56]

Yuzhu, please see if this is correct as we discussed offline.  I moved the
add-ref code to PPB_FileRef_Impl::CreateInternal as PepperDirectoryReaderHost
also calls it to create a FileRef.

[jln (very slow on Chromium), 2013-04-11 20:32:50]

I had a cursory look, following the trail from ppapi_messages.h. As always with
PPAPI, the learning curve is steep for me.

I didn't see anything that obviously needed a deeper look and Victor's comments
are reassuring.

I only have one question regarding how PpapiPluginMsg_FileSystem_OpenReply
works.

https://codereview.chromium.org/13726024/diff/63001/ppapi/proxy/ppapi_messages.h
File ppapi/proxy/ppapi_messages.h (right):

https://codereview.chromium.org/13726024/diff/63001/ppapi/proxy/ppapi_message...
ppapi/proxy/ppapi_messages.h:1408:
IPC_MESSAGE_CONTROL0(PpapiPluginMsg_FileSystem_OpenReply)
I saw this reply being sent, but how / where is it handled?

[victorhsieh, 2013-04-11 20:49:04]

Thanks.

https://codereview.chromium.org/13726024/diff/63001/ppapi/proxy/ppapi_messages.h
File ppapi/proxy/ppapi_messages.h (right):

https://codereview.chromium.org/13726024/diff/63001/ppapi/proxy/ppapi_message...
ppapi/proxy/ppapi_messages.h:1408:
IPC_MESSAGE_CONTROL0(PpapiPluginMsg_FileSystem_OpenReply)
On 2013/04/11 20:32:51, Julien Tinnes wrote:
> I saw this reply being sent, but how / where is it handled?

In ppapi/proxy/file_system_resource.cc, where it leads to a simple callback.

[jln (very slow on Chromium), 2013-04-11 20:52:59]

ppapi/proxy/ppapi_messages.h lgtm

[yzshen1, 2013-04-11 23:38:41]

Thanks for the nice work.

LGTM

[commit-bot: I haz the power, 2013-04-12 16:42:17]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/13726024/83001

[commit-bot: I haz the power, 2013-04-12 17:42:39]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/13726024/93004

[commit-bot: I haz the power, 2013-04-12 20:28:16]

Change committed as 193995