Implement exo::FileHelper without using file_manager::util::ConvertPathToArcUrl() |
|||||
Issue descriptionTo lunch exo for ARC++, we need implement exo::FileHelper. In current implementation[1], it uses file_manager::util::ConvertPathToArcUrl() to convert a path to an arc URL. This function's implementation is in //chrome/browser/chromeos/file_manager/path_util.cc . For ARC++ on Mus+ash, exo is not running in the browser process. It should not call any code in //chrome/browser/folder. [1] https://cs.chromium.org/chromium/src/chrome/browser/exo_parts.cc?q=exo_parts.cc&dr&l=41
,
Sep 25 2017
+hirono@, who has added the code to exo, IIUC.
,
Sep 26 2017
It seems we need a new IPC for exo::FileHelper. Is there any mojom I can add the IPC, or should I create new mojom for this? To unblock Mus+ash work, please implement exo::FileHelper it just returns false. It should only affect drag and drop for files Chrome -> Android.
,
Sep 26 2017
Why we need an IPC, what kind of IPC? And could you please explain the detail of sending files to ARC++?
,
Sep 27 2017
Yes, exo::FileHelper is used when a user drag and drop files from Chrome OS -> ARC++. The dropped data contains native path in Chrome OS side, but ARC++ container cannot access the path directly. Instead we mount specific directories (e.g. Downloads) in ARC++ container and allow ARC++ apps to access the files via the mount points. Thus we need to convert paths when dropping files to ARC++ apps and it requires mount point information managed in the browser process. IPC should be mojo message which requests the browser process to convert Chrome OS native path into path in ARC++ container.
,
Sep 27 2017
For long term, we would like to run ARC++ apps without launching a browser process. So it would be great if we can have ash process(or a dedicated process) to manage mount points for ARC++. However for short term, it is Okay to still have the browser process.
,
Sep 27 2017
If we don't launch browser process, we may not need to implement file_manager::util::ConvertPathToArcUrl() anyway, because there are only ARC windows and drag and drop operations only happen between ARC++ apps without the browser process.
,
Aug 15
In single-process mash chrome is supplying the correct FileHelper. For multi-process mash that isn't the case though.
,
Sep 28
Triage nag: This Chrome OS bug has an owner but no component. Please add a component so that this can be tracked by the relevant team.
,
Nov 8
<UI triage> Bug owners, please add the appropriate component to your bug. Thanks!
,
Jan 18
(4 days ago)
|
|||||
►
Sign in to add a comment |
|||||
Comment 1 by penghuang@chromium.org
, Sep 25 2017