To clarify, this is attaching using the Attach icon, not the Google Drive icon.

Some work-in-progress notes investigating how this might have regressed:

- Originally fixed in rev 190203 (https://src.chromium.org/viewvc/chrome?revision=190203&view=revision)
- Migrated to Git as 64c24d1 (https://cs.chromium.org/chromium/src/chrome/browser/chromeos/extensions/file_browser_private_api.cc?rcl=64c24d1f8ec2ca2b80c5539488ba204e7542386d)
- file_browser_private_api.cc moved in 6619abc (https://cs.chromium.org/chromium/src/chrome/browser/chromeos/extensions/file_manager/file_browser_private_api.cc?rcl=6619abc862f535996e4dff2f51d84d9389a8e41b)
- Call to "system_service->file_system()->GetFileByPath" was in "void FileBrowserFunction::GetSelectedFileInfoInternal", and this file was refactored out by 2cc796c (https://chromium.googlesource.com/chromium/src/+/2cc796c4dcfe96cb6e04b8286b1181f2f31a6468/chrome/browser/chromeos/extensions/file_manager/file_browser_private_api.cc)
- GetSelectedFileInfoInternal appears to exist in another location now, private_api_util.cc instead (https://cs.chromium.org/chromium/src/chrome/browser/chromeos/extensions/file_manager/private_api_util.cc?l=124-126&rcl=4a9711966b9d8f26dee3abf7a8f5454051ba4ab7)
- The implementation has changed, for the purposes of opening a non-"native" path (e.g. Drive) it appears to defer to GetFileNativeLocalPathForOpening (https://cs.chromium.org/chromium/src/chrome/browser/chromeos/extensions/file_manager/private_api_util.cc?l=65&rcl=4a9711966b9d8f26dee3abf7a8f5454051ba4ab7)

More investigation to be done.

lucmult@ can you PTAL? Would be great to fix this ASAP and merge back if the fix is simple enough.

I can reproduce on my dev build: 68.0.3410.0

I'll investigate the links from #2, next week when I'm back to Files App team.

Why is this a security bug? It seems a pretty bad regression, but I don't see the security aspect of it.

Not a security bug from my perspective either, switching back go regular bug.

Right, I managed to understand the problem better now.

1. It doesn't seem to be a regression from Files app on itself.
2. Gmail is validating the attachment size, which Files app reports as 0 bytes.
3. Drive API exposes .gdoc files as 0 bytes, that's why Files app reports as 0.

So it can be a regression in the sense that Gmail wouldn't validate this in the past.

For .gdoc files that are stored on the physical drive, within "Downloads" folder Files app reports its actual size in bytes, thus attaching to Gmail works. However, the attached file is just a text file with the Drive id.

I discussed with some other team mates on Files app and the long term solution we want is to disallow picking .gdoc files entirely. But this is pending more discussion and prioritizing this work.

That I said, I'm opening a bug to discuss this whole workflow of .gdoc files and so we prioritize it.

Since we have workarounds below, I'm changing the priority to P2.
1. Use "Drive" button to attach from Drive directly (preferable).
2. Copy the .gdoc file to Downloads to then be able to attach (we want to disallow this use case in the future).

Drive API documentation for "fileSize" field [1]:
"The size of the file in bytes. This field is only populated for files with content stored in Drive; it is not populated for Google Docs or shortcut files.	"


[1] - https://developers.google.com/drive/api/v2/reference/files#resource-representations

This is WAI, we could probably improve the messaging to the user - see  issue 843881 .

Gotcha. (Side question: Is it worth/possible to remove the acls on this issue so  people coming from  issue 843881  can read this?)