Issue metadata
Sign in to add a comment
|
Google Drive and screenshots broken with ChromeOS 53 release for HP Chromebox
Reported by
j...@hioscar.com,
Sep 26 2016
|
||||||||||||||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.116 Safari/537.36 Platform: 8530.81.0 Example URL: Steps to reproduce the problem: 1. Attempting to save or upload any file type from browser fails immediately. 2. Taking a screenshot causes ChromeOS to crash and will reopen with 'Restore' option shown on browser. 3. Google Drive is no longer accessible in My Files or via browser even though the app shows the user as logged in. What is the expected behavior? Google Drive and screenshots working What went wrong? Please refer to below files on Drive for context. https://drive.google.com/drive/folders/0B9pZ2PhRXuk2bXg4LW9Mam5xUE0?usp=sharing Did this work before? Yes before 53 release Chrome version: 53.0.2785.103 Channel: stable OS Version: 53.0.2785.103 Flash Version: Shockwave Flash 22.0 r0 These tickets below are related: https://bugs.chromium.org/p/chromium/issues/detail?id=646396 https://bugs.chromium.org/p/chromium/issues/detail?id=239584 https://bugs.chromium.org/p/chromium/issues/detail?id=649113
,
Sep 28 2016
Issue 651201 has been merged into this issue.
,
Sep 28 2016
,
Sep 30 2016
Raising priority on this bug since this seems widespread. Multiple enterprise users are reporting this issue. Image/file downloads are failing and/or chrome browser crashes when the following policies are enabled "DownloadDirectory" and "DeviceEphemeralUsersEnabled". Issue reproducible on multiple devices: Pixel 1, Acer c720, Acer c740 Chrome versions: 53.0.2785.103, 54+
,
Sep 30 2016
Hey Team, I just wanted to share my findings about this issue. We've received a couple of cases this week about users reporting the Google drive folder missing from the file manager in Chrome OS. After some troubleshooting we have identified that if you enable the device policy "Erase all local user data" the Google drive folder disappears from the file manager. This issue is 100% reproducible in all our test devices running 53 and 54. Now, if you force Google Drive as a default "Download Location" the problem get's worse. The Chrome devices that we tested crashes every time that you take a screenshot, probably because the device has no way to save the file since the drive folder and link to the file manager is missing. I hope this help to clarify and to start the investigation in the right direction.
,
Sep 30 2016
,
Sep 30 2016
,
Oct 3 2016
Team, We have a lot of reports from Enterprise customers. Were you guys able to confirm this issue?
,
Oct 3 2016
,
Oct 3 2016
Not able to repro in M54. Drive option and Screenshot looks ok. M ChromeOS Chrome ARC Type Channel 54 8743.52.0 54.0.2840.48 3320691 release beta
,
Oct 4 2016
Could repro on enrolled devices after setting the policy ""Erase all local user data" Could see drive after changing the policy to "Do not erase" and sign in back i.e. log out and login again to see google drive
,
Oct 4 2016
,
Oct 4 2016
,
Oct 4 2016
Screenshots 54.0.2840.24 CANDY logs
,
Oct 4 2016
Do we have an owner from the FileManager component on this thread?
,
Oct 4 2016
,
Oct 4 2016
,
Oct 8 2016
This looks like a regression. Raising visibility.
,
Oct 8 2016
I'll look into this issue. Is there any test account I can use to reproduce this issue? I don't have an account which have "DeviceEphemeralUsersEnabled" enabled.
,
Oct 8 2016
,
Oct 10 2016
Updated status.
,
Oct 10 2016
@fukino, I added repro credentials in valentine for you (search for "650268@yehudatest.com" or "650268") This account has "Erase all local user data" policy and Drive download location policies enabled. Please let me know if you need me to change the policy.
,
Oct 11 2016
Hi yyefet@, Thank you for adding it, but I could not find the credential in valentine. (Search for "650268" didn't show any result) Have you added the credential for fukino@google.com?
,
Oct 11 2016
I was able to reproduce this issue using another account. Thanks!
,
Oct 11 2016
Maybe this is related to the new marking algorithm of Drive cache. After I reverted https://codereview.chromium.org/2006503002 locally, the Google Drive was shown properly. oka@, let's investigate the issue. If reverting the patch does not have negative effect on M53, lets revert it on the branch.
,
Oct 11 2016
fukino@, I emailed you the test credentials
,
Oct 12 2016
M53 is officially done and no longer accepting any CLs. removing M-53 from the labels below.
,
Oct 12 2016
fukino@ should we try reverting CL in C#26 in M54? Any concerns with it?
,
Oct 12 2016
I wrote a CL to fix the issue without breaking existing functionality and it's under review. https://codereview.chromium.org/2412063002/
,
Oct 12 2016
I guess we should cherry-pick this to M54.
,
Oct 12 2016
ok, please do add merge-request once CL is reviewed/committed and tested
,
Oct 13 2016
,
Oct 14 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/7bd26bbf49860786603601e1aae0f9407a4c1292 commit 7bd26bbf49860786603601e1aae0f9407a4c1292 Author: oka <oka@chromium.org> Date: Fri Oct 14 06:59:06 2016 Fixed the bug that Drive doesn't appear on Files App on epehmeral mode. The CL https://codereview.chromium.org/2006503002 assumed file extended attributes and file attributes are available in GCache/v1/files to distinguish removable Drive caches. However, it is not true for ephemral mode, in which tmpfs is used to mount user directory. As a result in ephemeral mode initialization of file caches always fails and thus Drive folder doesn't appear in Files App. This CL fixes the issue by not touching file attributes if underlying filesystem doesn't support it. We compute the availability by checking if the errno is ENOTSUP after xattr() is called. BUG= 650268 TEST=Using link and daisy, - on phemeral mode, - Drive appears in Files App. - Copy & paste between Download and Drive, Drive and Drive are successfully done. - Pin/unpin on Drive works. - /var/log/ui/ui.LATEST doesn't report any error in file_cache.cc . - on normal mode, - GCache/v1/files has +d attribute and user.GCacheFiles extended attribute. - +d file attribute is toggled as expected when a file is pinned/unpinned. Review-Url: https://codereview.chromium.org/2412063002 Cr-Commit-Position: refs/heads/master@{#425263} [modify] https://crrev.com/7bd26bbf49860786603601e1aae0f9407a4c1292/components/drive/chromeos/file_cache.cc
,
Oct 14 2016
,
Oct 14 2016
josafat@ I hate to bother you, but could you merge #34 to M54 branch? Thank you.
,
Oct 14 2016
Merge approve, please merge to 2840 Is this also needed in M55?
,
Oct 14 2016
Yes.
,
Oct 14 2016
,
Oct 14 2016
Thank you guys so much for getting this bug fixed.
,
Oct 14 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/f4b5d9146363e4eec2e41a6d59f21cea4466e0b0 commit f4b5d9146363e4eec2e41a6d59f21cea4466e0b0 Author: Keigo Oka <oka@chromium.org> Date: Fri Oct 14 14:15:00 2016 Fixed the bug that Drive doesn't appear on Files App on epehmeral mode. The CL https://codereview.chromium.org/2006503002 assumed file extended attributes and file attributes are available in GCache/v1/files to distinguish removable Drive caches. However, it is not true for ephemral mode, in which tmpfs is used to mount user directory. As a result in ephemeral mode initialization of file caches always fails and thus Drive folder doesn't appear in Files App. This CL fixes the issue by not touching file attributes if underlying filesystem doesn't support it. We compute the availability by checking if the errno is ENOTSUP after xattr() is called. BUG= 650268 TEST=Using link, the following are confirmed on ephemeral mode. - Drive appears in Files App. - Copy & paste between Download and Drive, Drive and Drive are successfully done. - Pin/unpin on Drive works. - /var/log/ui/ui.LATEST doesn't report any error in file_cache.cc . patch from issue 2412063002 at patchset 80001 (http://crrev.com/2412063002#ps80001) (cherry picked from commit abb32757690fc60983520918cdeba1b77fdc2d11) Review URL: https://codereview.chromium.org/2416093003 . Cr-Commit-Position: refs/branch-heads/2840@{#739} Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607} [modify] https://crrev.com/f4b5d9146363e4eec2e41a6d59f21cea4466e0b0/components/drive/chromeos/file_cache.cc
,
Oct 14 2016
Issue 655525 has been merged into this issue.
,
Oct 14 2016
Approved for M55 too and marking as fixed for verification
,
Oct 17 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/37c69c59079f6138de759e1de506dbe91c91ed38 commit 37c69c59079f6138de759e1de506dbe91c91ed38 Author: Keigo Oka <oka@chromium.org> Date: Mon Oct 17 02:34:24 2016 Fixed the bug that Drive doesn't appear on Files App on epehmeral mode. The CL https://codereview.chromium.org/2006503002 assumed file extended attributes and file attributes are available in GCache/v1/files to distinguish removable Drive caches. However, it is not true for ephemral mode, in which tmpfs is used to mount user directory. As a result in ephemeral mode initialization of file caches always fails and thus Drive folder doesn't appear in Files App. This CL fixes the issue by not touching file attributes if underlying filesystem doesn't support it. We compute the availability by checking if the errno is ENOTSUP after xattr() is called. BUG= 650268 TEST=Using link, the following are confirmed on ephemeral mode. - Drive appears in Files App. - Copy & paste between Download and Drive, Drive and Drive are successfully done. - Pin/unpin on Drive works. - /var/log/ui/ui.LATEST doesn't report any error in file_cache.cc . patch from issue 2412063002 at patchset 80001 (http://crrev.com/2412063002#ps80001) (cherry picked from commit abb32757690fc60983520918cdeba1b77fdc2d11) Review URL: https://codereview.chromium.org/2416093003 . Cr-Commit-Position: refs/branch-heads/2840@{#739} Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607} (cherry picked from commit f4b5d9146363e4eec2e41a6d59f21cea4466e0b0) Review URL: https://codereview.chromium.org/2422093002 . Cr-Commit-Position: refs/branch-heads/2883@{#134} Cr-Branched-From: 614d31daee2f61b0180df403a8ad43f20b9f6dd7-refs/heads/master@{#423768} [modify] https://crrev.com/37c69c59079f6138de759e1de506dbe91c91ed38/components/drive/chromeos/file_cache.cc
,
Oct 18 2016
We updated a text Chromebox to the Beta Channel on version 54 but the issue persists. Please advise.
,
Oct 18 2016
The fix hasn't hit beta yet. I think it will take a few days. josafat@, when will the next beta be pushed?
,
Oct 19 2016
When will this fix hit the Stable channels on chrome OS?
,
Oct 19 2016
Verified in M54 for enrolled device. Pit M ChromeOS Chrome ARC Type Channel 54 8743.69.0 54.0.2840.68 3364514 release beta Could see Google Drive after setting the policy to ""Erase all local user data"
,
Oct 19 2016
Marking this as verified as per #c48
,
Oct 19 2016
Needs to be verified in R55 as well, so marking this as Fixed for now.
,
Oct 19 2016
,
Oct 20 2016
Was the October 18th Date missed for Chrome OS 54 on stable? date pulled from https://www.chromium.org/developers/calendar
,
Oct 20 2016
I believe the M54 stable release has been postponed to end of day today 10/20.
,
Oct 20 2016
Verified in M55/Daisy. M ChromeOS Chrome ARC Type Channel 55 8872.18.0 55.0.2883.20 3367229 release dev Could see Google Drive after setting the policy to ""Erase all local user data"
,
Oct 27 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/37c69c59079f6138de759e1de506dbe91c91ed38 commit 37c69c59079f6138de759e1de506dbe91c91ed38 Author: Keigo Oka <oka@chromium.org> Date: Mon Oct 17 02:34:24 2016 Fixed the bug that Drive doesn't appear on Files App on epehmeral mode. The CL https://codereview.chromium.org/2006503002 assumed file extended attributes and file attributes are available in GCache/v1/files to distinguish removable Drive caches. However, it is not true for ephemral mode, in which tmpfs is used to mount user directory. As a result in ephemeral mode initialization of file caches always fails and thus Drive folder doesn't appear in Files App. This CL fixes the issue by not touching file attributes if underlying filesystem doesn't support it. We compute the availability by checking if the errno is ENOTSUP after xattr() is called. BUG= 650268 TEST=Using link, the following are confirmed on ephemeral mode. - Drive appears in Files App. - Copy & paste between Download and Drive, Drive and Drive are successfully done. - Pin/unpin on Drive works. - /var/log/ui/ui.LATEST doesn't report any error in file_cache.cc . patch from issue 2412063002 at patchset 80001 (http://crrev.com/2412063002#ps80001) (cherry picked from commit abb32757690fc60983520918cdeba1b77fdc2d11) Review URL: https://codereview.chromium.org/2416093003 . Cr-Commit-Position: refs/branch-heads/2840@{#739} Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607} (cherry picked from commit f4b5d9146363e4eec2e41a6d59f21cea4466e0b0) Review URL: https://codereview.chromium.org/2422093002 . Cr-Commit-Position: refs/branch-heads/2883@{#134} Cr-Branched-From: 614d31daee2f61b0180df403a8ad43f20b9f6dd7-refs/heads/master@{#423768} [modify] https://crrev.com/37c69c59079f6138de759e1de506dbe91c91ed38/components/drive/chromeos/file_cache.cc
,
Oct 27 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/f4b5d9146363e4eec2e41a6d59f21cea4466e0b0 commit f4b5d9146363e4eec2e41a6d59f21cea4466e0b0 Author: Keigo Oka <oka@chromium.org> Date: Fri Oct 14 14:15:00 2016 Fixed the bug that Drive doesn't appear on Files App on epehmeral mode. The CL https://codereview.chromium.org/2006503002 assumed file extended attributes and file attributes are available in GCache/v1/files to distinguish removable Drive caches. However, it is not true for ephemral mode, in which tmpfs is used to mount user directory. As a result in ephemeral mode initialization of file caches always fails and thus Drive folder doesn't appear in Files App. This CL fixes the issue by not touching file attributes if underlying filesystem doesn't support it. We compute the availability by checking if the errno is ENOTSUP after xattr() is called. BUG= 650268 TEST=Using link, the following are confirmed on ephemeral mode. - Drive appears in Files App. - Copy & paste between Download and Drive, Drive and Drive are successfully done. - Pin/unpin on Drive works. - /var/log/ui/ui.LATEST doesn't report any error in file_cache.cc . patch from issue 2412063002 at patchset 80001 (http://crrev.com/2412063002#ps80001) (cherry picked from commit abb32757690fc60983520918cdeba1b77fdc2d11) Review URL: https://codereview.chromium.org/2416093003 . Cr-Commit-Position: refs/branch-heads/2840@{#739} Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607} [modify] https://crrev.com/f4b5d9146363e4eec2e41a6d59f21cea4466e0b0/components/drive/chromeos/file_cache.cc |
|||||||||||||||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||||||||||||||
Comment 1 by eroman@chromium.org
, Sep 27 2016