Files opened through native "Files" app cannot be save back in their file path
Reported by
p.deray...@gmail.com,
Dec 1 2017
|
|||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; CrOS aarch64 10172.0.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3280.5 Safari/537.36 Platform: 10172.0.0 (Official Build) dev-channel elm Steps to reproduce the problem: 1. Open any document file (Word, Excel,...) or any PDF file IN YOUR LOCAL HARD DRIVE through any app that allows editing the file 2. Make a small change in the file (add a line, highlight a text) 3. Try to save the document 4. You'll it asks you to indicate the path to save the file in. 5. Use one of these file explorer apps: (File Commander, ES File Explorer, Amaze) and reproduce steps 1 to 3 6. The file is saved back in the original path 7. Conclusion: Native "Files" app is not fully integrated to work with Android apps yet What is the expected behavior? Being able to open the file, edit it, and simply save it upon exit, IN THE SAME FILE PATH What went wrong? As I described, each time I try to save a document I have to do the painful process of indicating the saving path from the sratch Did this work before? N/A Chrome version: 64.0.3280.5 Channel: n/a OS Version: 10172.0.0 Flash Version: 28.0.0.120 This is a huge buying point to me if I want to "COMPLETELY" switch from Windows to Chrome OS, to be able to open multiple "file tabs" as "Files" is the only app capable of, and be able to save files naturally after I'm done with them. Also, HUGE productivity barries (Compared to windows): not being able to pin single files, not being able to create shortcuts! With these expensive chromebooks with large SSD capacities I feel those expectations are more than justified!
,
Feb 20 2018
<files-triage>
,
Feb 28 2018
,
Mar 28 2018
,
Apr 3 2018
I can't reproduce this without an Office 365 subscription, which is required for editing file with the MS Word Android App. Let me get one and then try repro this.
,
Apr 6 2018
This seems like ARC bug - likely the app does "safe save" through a temporary file, which fails because ARC exposes access to that file only and the app is unable to create temporary file or swap them later.
,
Apr 6 2018
,
Apr 6 2018
+hirono as the author of http://crrev.com/c/622462 +niwa and nya who might have opinions about the path conversion logic. Probably, the said application tries to overwrite the file only when a file is given with a file URL? We used to do that too, but we switched to use content URLs later. https://chromium-review.googlesource.com/c/chromium/src/+/622462/3/chrome/browser/chromeos/file_manager/path_util.cc If that's the case, I'm not sure if it's the app's fault (i.e. the apps should try to do the same thing which ever URL scheme was given), or our fault (i.e. we should switch back to use file URLs again).
,
Apr 6 2018
I guess the content:// URL given to the app is not writable -- IIRC ArcIntentHelper gives only read permissions on sending intents. Maybe try giving write permissions if the URL is on FileProvider? (I guess we can't do the same with ArcContentProvider URLs)
,
Apr 6 2018
It seems ArcIntentHelperService#handleUrlList() is the method granting only read permission.
,
Apr 6 2018
,
Apr 13 2018
We are assuming three types of apps here: a) Apps which handles content:// URI with write permission. This is the preferred behavior in Android world. Adding write permission to Uri solves the problem. b) Apps which handles content:// URI, then extracts file path from it. This type of apps claim WRITE_EXTERNAL_STORAGE permission to access the file via file path. To extract path from content:// URI apps uses the assumption about Uri format of built-in documents providers (e.g. DownloadStorageProvider, ExternalStorageProvider ...). Currently ARC++ uses its own FileProvider to extract files on Downloads so this type of apps cannot extract the path from content:// URI. c) Apps which handles file:// URI directly. This is legacy behavior which is no longer workable since N. https://developer.android.com/reference/android/os/FileUriExposedException.html
,
Jul 20
Just confirmed that granting WRITE_URI_PERMISSION in ArcIntentHelperService#handleUrlList() allowed the user to write back to the same file path on several editor apps (Word, Text Editor, QuickEdit, etc.)
,
Jul 20
FYI, here is the permission error I got when attempting to write back to a file path in /Downloads using "Text Editor" app. E DatabaseUtils: java.lang.SecurityException: Permission Denial: writing android.support.v4.content.FileProvider uri content://org.chromium.arc.intent_helper.fileprovider/download/sample.txt from pid=2265, uid=10084 requires the provider be exported, or grantUriPermission() E DatabaseUtils: at android.content.ContentProvider.enforceWritePermissionInner(ContentProvider.java:706) https://paste.googleplex.com/6229977540329472?raw
,
Jul 20
Buganizer bug: b/111670096
,
Jul 20
[Details redacted due to bug visibility] Change-Id: I71c60bd840f766f72e3592ade879dbaa540cdcab https://googleplex-android-review.git.corp.google.com/4592173
,
Jul 20
,
Jul 23
Thanks niwa-san for the super quick fix :D
,
Jul 24
Awesome thanks!! |
|||||||||||
►
Sign in to add a comment |
|||||||||||
Comment 1 by weifangsun@chromium.org
, Dec 1 2017Owner: weifangsun@chromium.org