+weifang - is there a longer term vision for unifying file picker dialogs on non-ChromeOS?

Thanks for looking into this. Getting the File Manager to run on Linux is something we've looked into before as it would help improve our development & testing workflow. However, I have some questions...

(1) What are the exact use cases for SelectFileDialogExtension outside of ChromeOS? Is this only for Wayland? Are there that many users running Chrome that don't have a native UI toolkit?

(2) FileManagerPrivate is heavily dependent on ChromeOS (MTP, ARC, Drive, etc) and we have no plans to support these features on other platforms. We would have to split the API into Chrome- and ChromeOS-specific versions, and somehow detect this on the front-end to know which API to call, which would be difficult. Unless you had another idea?

(3) Is there a timeline for Wayland support? We're pretty full with features for M69, but this might be something we can look into in the future. We couldn't accept a patch that large but we could look into it and break it apart and implement it ourselves. We also have some other planned changes/refactors for the file picker in the pipeline, so we'd have to find where it best fits with those as well.

(1) What are the exact use cases for SelectFileDialogExtension outside of ChromeOS? Is this only for Wayland? Are there that many users running Chrome that don't have a native UI toolkit?
=> there are various solutions that make use of ozone/wayland today in production, which forcibly disable Chromium's Gtk+ support or do not have the toolkit available in their systems at all. To name a few, WebOS, Tizen (mobile, TV and and other low end embedded environments), AGL (Automotive Grade Linux,  https://www.automotivelinux.org/), and qtwebengine, all have chosen to adopt chromium as their Web solution, and do not have Gtk toolkit available on their systems. Such solutions need an alternative implementations for their dialog support.

(2) FileManagerPrivate is heavily dependent on ChromeOS (MTP, ARC, Drive, etc) and we have no plans to support these features on other platforms. We would have to split the API into Chrome- and ChromeOS-specific versions, and somehow detect this on the front-end to know which API to call, which would be difficult. Unless you had another idea?
=>I thought we could not split the APIs. We just make the front-end call the APIs without recognition. Even if we don't split the APIs, we have to keep separate implementation for linux and ChromeOS. For linux, it could just return when it doesn't support and the front-end might care the case when the function returns empty, false, or not supported. From the changes I shared before, it didn't split the APIs definition and kept the front-end side used on ChromeOS. I could share the demo video.

(3) Is there a timeline for Wayland support? We're pretty full with features for M69, but this might be something we can look into in the future. We couldn't accept a patch that large but we could look into it and break it apart and implement it ourselves. We also have some other planned changes/refactors for the file picker in the pipeline, so we'd have to find where it best fits with those as well.
=> We are upstreaming the patches required to support Wayland natively, and it is possible to launch a minimally functional Chromium/Wayland browser off of ToT today. The rough schedule to finish upstreaming is Q3, but work to unify X11 and Wayland code paths through Ozone will spawn through Q4.
I agree current patch is too big to upstream and I'd like to just show that it could be one of workable options to users couldn't use UI toolkit on their environment. In order to upstream it, I think we need to touch them more. BTW, It's great to hear that you're considering to enhance it. I hope this use cases we faced be also considered.

I attached video to show its working on linux. It's only allowed to explorer 'Downloads' folder.

Deleted: FileSelectionExtension.mp4 946 KB

	FileSelectionExtension.mp4 946 KB View Download

Assigning to Weifang for prioritization.

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

commit c2af1f3ddc17e21663e1202207bc130e14d7dfac
Author: Julie Jeongeun Kim <jkim@igalia.com>
Date: Sat Sep 01 02:56:19 2018

Create file_manager_strings.grdp to manage independently

This patch creates file_manager_strings.grdp as collecting file
manager strings from chromeos_strings.grdp to manage
independently.

It also moves sha1 for file manager already added at
chrome/app/chromeos_strings_grdp to
chrome/app/file_manager_strings_grdp

It's wrapped in <if expr="chromeos"> at generated_resources.grd.

TEST=tested manually

Bug: 845818
Change-Id: I3741871b2fe9e0d0aec8da10caa7f4ab3f20363a
Reviewed-on: https://chromium-review.googlesource.com/1195173
Reviewed-by: Naoki Fukino <fukino@chromium.org>
Reviewed-by: Ken Rockot <rockot@chromium.org>
Commit-Queue: Julie Jeongeun Kim <jkim@igalia.com>
Cr-Commit-Position: refs/heads/master@{#588255}
[modify] https://crrev.com/c2af1f3ddc17e21663e1202207bc130e14d7dfac/chrome/app/chromeos_strings.grdp
[add] https://crrev.com/c2af1f3ddc17e21663e1202207bc130e14d7dfac/chrome/app/file_manager_strings.grdp
[rename] https://crrev.com/c2af1f3ddc17e21663e1202207bc130e14d7dfac/chrome/app/file_manager_strings_grdp/IDS_FILE_BROWSER_ANDROID_FILES_ROOT_LABEL.png.sha1
[rename] https://crrev.com/c2af1f3ddc17e21663e1202207bc130e14d7dfac/chrome/app/file_manager_strings_grdp/IDS_FILE_BROWSER_MY_FILES_ROOT_LABEL.png.sha1
[rename] https://crrev.com/c2af1f3ddc17e21663e1202207bc130e14d7dfac/chrome/app/file_manager_strings_grdp/IDS_FILE_BROWSER_SHOW_ALL_ANDROID_FOLDERS_OPTION.png.sha1
[modify] https://crrev.com/c2af1f3ddc17e21663e1202207bc130e14d7dfac/chrome/app/generated_resources.grd