Also noticed that the Text app, which I'm not currently running, but used earlier, is still running its background page, with a keepalive count of 1.

Istiaque, I think you have experience with event page code. Can you take a look?

Assigning to file_manager OWNERS

Thanks for the report.  I'll set the component and status on this to go through the normal FilesApp triage process.

Unconfirmed->Untriaged.

I've just repro'd this with the following:
1. Open Files app.
2. Find a Docs file.
3. Double-click to open it.

At #3 the Docs file should be opened in a new tab. Instead, nothing happens.

It also takes a long while, sometimes, for the Drive folder to even show any contents.

Once Files _does_ succeed in opening the Doc, it seems to continue succeeding, as though some internal state has been "fixed".

Removing extensions component for now to get it out of our triage queue.  Please add it back if there's something extensions-specific that comes up!

I couldn't reproduce the issue either. The only way I could see the column "keepalive count" increasing on Task Manager was by opening new Files app windows.

I tried to open Google doc file, images and videos which open our other apps (gallery and video player), but even those don't count on "keepalive count".

I'm suspecting that it can be the case of Files app taking too long to open (as mentioned on #5) and thus counting on "keepalive count" column.

I'm contating wez@ via email to ask more information about their environment to try to have more clues about what can be causing this.

Re #8: The issue doesn't seem to repro reliably enough to get further information, sadly.  It doesn't seem as though things are taking too long to open, but that they are not opening *at all* - bear in mind that the specific files I'm opening are Docs, so they cause a new tab to be opened.

Any update here?

This bug is marked as a 68 stable release blocker, and we are coming up on stable in a couple weeks, so we need to get it fixed or reclassify it.

Hi,

I have done another round to try to reproduce this issue, with an ARM device and event with no network, opening Docs from Drive and from Downloads.

I can't see any issue with speed of Files app nor with keepalive.

So far it looks like an isolated issue, so I'm removing the release blocker label and changing to P2.

This has repro'd for me on a dev-channel ( 69.0.3486.0) Pixelbook, using my corp account - the File app has keep-alive count of 14 and is continuously running, despite not being in-use, holding 125MiB of RAM.  Uptime of the device is three days.

Based on when I first observed this, I think it is specific to a device which is connected to a network (i.e. it thinks it's online) but can't actually get any data through (e.g. if you were connected to a captive-portal).

Bumping priority back up, since this can be repro'd easily just by using a device for a while.

Captive portal sounds similar to a VPN issue. We've had similar issues with VPNs in the past.

Hmmm, I think when I originally repro'd this issue it was indeed when corp VPN was misbehaving.

Just repro'd this under ChromeOS 69.0.3494.0, with my corp account. Two attempts to open a Doc failed, and then a third attempt a few minutes later aucceeded. Now I have a Files.app extension with a keepalive count of 2.

Noticed that if I follow the steps:
1. Click away from Drive sub-folder, e.g. on to My Drive itself, so that Open option disappears.
2. Click to sub-folder.
3. Click on a doc on the sub-folder.
4. Before the Open button appears, double-click on the file.
5. Close Files.

then I can reliably get Files' keepalive count to increase by one.

So this seems related to whatever asynchronous work is done before showing the Open button for a file.

Possibly related, Files takes noticably longer to show directory contents than in previous releases, suggesting that perhaps we're losing cached directory metadata unexpectedly.

Just touching base here.

I finally managed to reproduce this issue with my corp account.

The issue seems related to the large amount of files/folders inside Drive, Files app spends significant time processing file/folder's metadata and thumbnails.

The fix I'm requesting to merge on M-69 via  crbug.com/867974  will make this slightly better, however there are a few more things that can be done to make this better.

It probably won't be ready for M-69, though.

 crbug.com/867974  has been merged on M-69, which should make it a little better.

I'm still trying to reproduce this issue with a test account to be able to debug better and I can't quite reproduce it outside my corp account. :-/

The keepalive count seems to be increased by our thumbnail generator extension and/or by our metadata worker, which is kind of working as intended. The issue seems that Files app is taking a long time to process all metadata and thumbnail which keeps the keepalive count high. These 2 things have some caching so once it's cached it flows better

I'm trying to narrow down to which of those 2 is the main problem here but without reproducing on a test account it's a bit hard to narrow down.

Re #19: I filed this bug because the behaviour has become noticably worse lately:

- Often when I open Files.app the view is empty and I have to wait for a spinner before it will list the files in commonly-used directories (e.g. top-level, my main project sub-directory).
- Often when trying to open Docs, nothing happens, as described in this bug. That seems an unacceptable side-effect of a background thumbnail-generation activity, especially since I don't have thumbnails enabled in my default Files view!

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/6962b90e61ae35c242cacc6318e3cb000cbaec7e

commit 6962b90e61ae35c242cacc6318e3cb000cbaec7e
Author: Luciano Pacheco <lucmult@chromium.org>
Date: Thu Aug 09 09:52:28 2018

Increase max job count for metadata queue

This improves the response from drive to UI when there are several team
drives.

Drive sync adds one job per Team Drive to this queue, which causes the
queue to be busy with team drive operations and not responsive to
operations to respond to user interactions.

Bug:  852934 
Change-Id: I215bd5fffe60efe576e9b82e4d4737f0ea2d27de
Reviewed-on: https://chromium-review.googlesource.com/1168946
Reviewed-by: Stuart Langley <slangley@chromium.org>
Commit-Queue: Stuart Langley <slangley@chromium.org>
Cr-Commit-Position: refs/heads/master@{#581848}
[modify] https://crrev.com/6962b90e61ae35c242cacc6318e3cb000cbaec7e/components/drive/job_scheduler.cc

When I came in and unlocked my Chromebox (running 69.0.3497.21) this morning, I hit this issue again:

- My Drive took 1-2 seconds to show any content at all.
- Navigating to my Chrome-Fuchsia subdirectory, that took >5 seconds before displaying any contents.
- Attempting to open any Docs under my Chrome-Fuchsia directory had no effect.
- After double-clicking on a doc in that directory, I noticed that the auto-hiding overlay scrollbar down the side of the directory view would flash to being visible, then fade out again, every few seconds.

Next I navigated to a "bugs" directory I use for keeping files relating to bugs I'm looking at, and tried to create a sub-directory for this bug:

- The "bugs" sub-directory of My Drive took ~5 seconds to show any contents.
- Once it finished loading, the scroll-bar kept reappearing every few seconds.
- When I created a New Folder and started editing the name to refer to this bug, but didn't finish typing within those few seconds, the displayed name reverted to New Folder.
- During that period the ordering of the items in that sub-directory changed every so often; not sure whether new items were being discovered, or it was just reordering existing ones for some reason.
- After renaming the New Folder to  Bug852934 , it appeared to revert back to New Folder. When I tried to open it, it showed that I had navigated into New Folder, then after a few seconds that name was replaced by  Bug852934 .

I took a few DevTools performance profiles from the Files window, which I can share with you in case they shed any light.

Merge request for crrev.com/c/1168946 this is an improvement for performance regression for Team Drive.

I have tested this change locally by merging crrev.com/c/1168946 on a local M69 branch (branch-heads/3497) and run ChromeOS locally on my workstation, as well as running our Files app integration tests.

This bug requires manual review: M69 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), kariahda@(iOS), cindyb@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Thanks for the testing information. Merge approved, M69.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/17f1d52e4b653422d51e41ec621ac7ce374fda45

commit 17f1d52e4b653422d51e41ec621ac7ce374fda45
Author: Luciano Pacheco <lucmult@chromium.org>
Date: Tue Aug 14 00:10:39 2018

Increase max job count for metadata queue

This improves the response from drive to UI when there are several team
drives.

Drive sync adds one job per Team Drive to this queue, which causes the
queue to be busy with team drive operations and not responsive to
operations to respond to user interactions.

Bug:  852934 
Change-Id: I215bd5fffe60efe576e9b82e4d4737f0ea2d27de
Reviewed-on: https://chromium-review.googlesource.com/1168946
Reviewed-by: Stuart Langley <slangley@chromium.org>
Commit-Queue: Stuart Langley <slangley@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#581848}(cherry picked from commit 6962b90e61ae35c242cacc6318e3cb000cbaec7e)
Reviewed-on: https://chromium-review.googlesource.com/1173631
Reviewed-by: Luciano Pacheco <lucmult@chromium.org>
Cr-Commit-Position: refs/branch-heads/3497@{#600}
Cr-Branched-From: 271eaf50594eb818c9295dc78d364aea18c82ea8-refs/heads/master@{#576753}
[modify] https://crrev.com/17f1d52e4b653422d51e41ec621ac7ce374fda45/components/drive/job_scheduler.cc

Just encountered the slow-to-load-MyDrive issue with ChromeOS 69.0.3497.35.

For no apparent reason Files had no contents for My Drive when I opened it just now, and I had to wait for ~45s while it showed the activity line across the top, after which the directory contents eventually showed up.

Thanks for the update wez@.

We encountered different performance issues during this investigation and most of them related to the new Team Drives feature.

slangley@ has been working in a few more fixes, most of them haven't made to 69.0.3497.35 and even my fix above (comment #26) only landed on 69.0.3497.39

So, still a few more versions until this gets in a better shape. 

Hi wez@ and all,

I haven't forgot about this bug, I've done an longer assessment about metadata from Files app UI. For example, this revealed we read Drive at start up even when
user is still navigating in Downloads/local files, which explains some of the behaviour wez@ has described.

Internal doc: go/files-app-metadata-audit

crrev.com/c/1203596 Fixed a big issue we metadata in Files app.

Also we have fixed a memory leak in our image thumbnail code that can be related to the keep-alive counter: crrev.com/c/1214966.

wez@ if you have a chance can you tell how does it behave for you in a recent ChromeOS version: >= 71.0.3549.0

I don't think this is fully fixed, but we should be getting closer.

Re #31: FWIW the increase in keepalive count still corresponds directly with failure to open a Google Doc.  I noticed that just now when I couldn't open a Docs document, when I right-clicked on it the top of the context menu had a greyed-out "Open" action, and then "More actions". I was only able to open the doc when those two were replaced with a single "Docs" action.

None of the documents I've been opening from Drive have been images.

(This was observed under ChromeOS 70.0.3538.7).

Also re #31: My (dev-channel) device is still stuck on M70 so I can't verify this yet.

We've included a few changes for M70, I'll keep this open until we're confident with its resolution, however I'm moving to M71.

I've checked on M71: 71.0.3572.0 and it's behaving quite well now (for a corp and a non-corp account).

It behaves well even before has the full sync. This a lot to do with this fix from slangley@ crrev.com/c/1237902

wez@ if you have a device in dev channel can you confirm if this is fixed for you?

On a device running 71.0.3572.0 I've just observed:

1. When I opened Files to go to My Drive about half an hour ago, Google Drive was entirely missing from the app. I left the app open for a while but it never appeared.
2. Just now I opened Files and Google Drive was there, and I was able to click on My Drive, which opened immediately.
3. I closed Files and re-opened it, and clicked on My Drive again - this time it displayed no contents for the first ~30 seconds.

#3 is primarily what I'm suggesting indicates something badly broken; I had literally opened Files and viewed the top level of my Google Drive about 5-10 seconds earlier, and yet suddenly Files found nothing to display and took half a minute(!) to re-fetch data.  Why had we lost the locally-cached data in the first place?

Hi wez@

Thanks for following up here.

For #1, this issue has been fixed on crbug.com/893161, I'm requesting to merge on M-71.

For #3, this seems that your Drive is pretty big and it takes a long time to actually fully sync, while it isn't fully sync, it can read from Drive service more often, slangley@ (crrev.com/c/1237902) added some logic to avoid re-reading from Drive service within a short period of time. Unfortunately this is kind of a limitation of this current Drive integration implementation, which we won't improve further for M71 probably won't either for M-72, instead we'll fix this with the new DriveFS integration.

I understand that the situation here isn't great yet, but we've taken to a more bearable levels with the current Drive integration.

I'm proposing that we close this bug on this current status, WDYT?

Re #37: Is there any timeline for the new impl?

sammc@ is leading the DriveFS effort. 

I've check with him and they're starting a 50% dev channel experiment in M-71 and aiming to launch in M-72.

If you're keen on this, you can already turn the drivefs flag in M-71 dev, which will help to iron out issues like this before we launch.

Thanks; flipped the flag in M71 and so far it seems to be working well.

I'm marking this as fixed for the time being.

If anybody has similar issues with Drive, please open a new bug for investigation.