Drag and drop from Donwloads volume to a browser window works as expected.

<files-triage>

An externalfile: URL (e.g. "externalfile:drive-a5e...497/root/​filename.png") is set to DropData.url when a drive file is dragged from Files app.

This URL is rejected by ChildProcessSecurityPolicyImpl::CanRequestURL [1] and is replaced by "about:blank" because "externalfile:" is not registered as WebSafeScheme [2].

[1] : Stack trace
ChildProcessSecurityPolicyImpl::CanRequestURL
RenderProcessHostImpl::FilterURL
RenderWidgetHostImpl::FilterDropData
WebContentsViewAura::OnDragEntered

[2] : List of schemes registered as WebSafeScheme in ChildProcessSecurityPolicyImpl
http, https, ftp, data, feed, blob, filesystem

I found the following code for whitelisting externalfile:// for ChromeOS in browser_file_system_helper.cc

void PrepareDropDataForChildProcess(...) {
#if defined(OS_CHROMEOS)
  // The externalfile:// scheme is used in Chrome OS to open external files in a
  // browser tab.
  if (drop_data->url.SchemeIs(content::kExternalFileScheme))
    security_policy->GrantRequestURL(child_id, drop_data->url);
#endif

I wonder if we should whitelist externalfile:// for ChromeOS in ChildProcessSecurityPolicyImpl as well.

FYI, browser URL box accepts this externalfile: URL.
(Copy/paste-ing the externalfile: URL ("externalfile:drive-a5e...497/root/​filename.png") into the browser URL box opens the drive web page.)

hirono@-san suggested that handling filesystem: URL might be better than handling external: URL.

I confirmed that DropData contains filesystem: URL below along with externalfile: URL when dragging a GDrive file.

DropData
 url : externalfile:drive-a5e639...81cd497/root/test1.gdoc
 file_system_url : filesystem:chrome-extension://hhaomjibdihmijegdhdafkllkbggdgoj/external/drive-a5e639...81cd497/root/test1.gdoc

The problem seems to be that DragData::AsURL (function used for obtaining target URL in PerformDrag) never returns filesystem: URL even when DragData contains filesystem: URL.

String DragData::AsURL(FilenameConversionPolicy filename_policy,
                       String* title) const {
  String url;
  if (platform_drag_data_->Types().Contains(kMimeTypeTextURIList))
    platform_drag_data_->UrlAndTitle(url, title);
  else if (filename_policy == kConvertFilenames && ContainsFiles())
    url = FilePathToURL(platform_drag_data_->Filenames()[0]);
  return url;
}

(Call stack)
DragData::AsURL
DragController::PerformDrag
WebFrameWidgetBase::DragTargetDrop

Notes of discussions with hirono@

- Currently Files App sets both externalfile URL and filesystem URL into clipboard, but it should actually set only filesystem URL. (file_transfer_controller.js)

- Update browser to converting filesystem URL to externalfile URL in PrepareDropDataForChildProcess

- FileSystemURLToExternalFileURL can be used for the conversion, but the function needs to be moved out of src/chrome/browser/chromeos/... to src/content/...

Hi hirono-san, is this bug really blocked by 811679 (Migrate callers of ConvertPathToArcUrl) ?

Oops, sorry I changed wrong bug. Removed blocking issue.

Just a quick check - Can you confirm if this is a known behavior or regression? Are we still targeting this fix for M67?

We are not targeting this fix for M67 any more, as we are working on more urgent P tasks now. Unssigning myself.

I think hirono@-san knows whether it's a regression or not.

IIRC, this is a regression issue.

Hi,

I came across this bug while investigating another issue for files from Drive.

I tried to reproduce and couldn't reproduce on M66: 66.0.3359.137

Nor on my dev device: 68.0.3410.0

I dragged an image file from Files.app (from within Drive) to browser to create a new tab and it showed the image on the browser correctly.

Closing as won't fix. Please re-open if it still occurring.

Deleted: May 17, 2018 11_42 AM.webm 1.1 MB

	May 17, 2018 11_42 AM.webm 1.1 MB View Download

I could reproduce it with 68.0.3431.0.
It looks the video attached #22 is dragging file from Downloads instead of Drive.
Also please drop a file on the main content area instead of omnibox to reproduce the issue.

Could this be related to issue 862282? Joel, do you have time to take a look?

This is fixed with drivefs.