Re: [blink-dev] Intent to Ship: Writable directory prompts for the File System Access API

['Austin Sullivan' via blink-dev]

I've filed an issue <https://github.com/web-platform-tests/wpt/issues/34665>,
though I don't have access to add the "untestable" label

On Wed, Jun 29, 2022 at 12:54 PM Marijn Kruisselbrink 
wrote:

> FWIW, that is more or less how in chrome's tree we already automate some
> of these "manual" WPT tests. Chrome has two private test APIs, one to set
> whatever path file/directory pickers should return, and one to get a path
> to a temporary (writable) directory. That doesn't really help for testing
> most of the options passed to the various picker methods since their effect
> generally isn't visible to the web (most options just change what the UI
> looks like/behaves like), although for this particular one I suppose there
> at least some web-visible/testable effects.
>
> https://github.com/web-platform-tests/wpt/issues/8114 is at least
> tangentially related to the missing WP functionality
>
> On Wed, Jun 29, 2022 at 8:57 AM Philip Jägenstedt 
> wrote:
>
>> Hi Austin,
>>
>> Would you mind filing a bug for this testing capability for WPT at
>>
>> https://github.com/web-platform-tests/wpt/issues?q=is%3Aopen+is%3Aissue+label%3Atype%3Auntestable
>> ?
>>
>> It sounds like what you need here is a WebDriver end point that
>> configures the browser to automatically resolve a
>> showDirectoryPicker() call with a directory controlled by WebDriver.
>>
>> Tests would then do something like `await
>> test_driver.set_directory_picker('/path/to/a/directory')` before the
>> showDirectoryPicker() call.
>>
>> If you think that setup would make sense, I'd be happy to provide more
>> pointers for how to get it done in the different layers.
>>
>> Best regards,
>> Philip
>>
>> On Wed, Jun 29, 2022 at 5:22 PM 'Austin Sullivan' via blink-dev
>>  wrote:
>> >
>> > This feature is covered by integration tests. showDirectoryPicker()
>> only has manual WPT coverage, and since this launch only corresponds to
>> changes in permission prompt behavior, WPTs didn't really make sense.
>> >
>> > On Wed, Jun 29, 2022 at 10:57 AM Chris Harrelson 
>> wrote:
>> >>
>> >>
>> >>
>> >> On Wed, Jun 29, 2022 at 7:52 AM Mike West  wrote:
>> >>>
>> >>> LGTM2. Thank you for working with the permissions and UX teams to
>> hammer out a reasonable approach here.
>> >>>
>> >>> -mike
>> >>>
>> >>>
>> >>> On Mon, Jun 27, 2022 at 4:40 PM 'Austin Sullivan' via blink-dev <
>> blink-dev@chromium.org> wrote:
>> >>>>
>> >>>> PR is landed
>> >>>>
>> >>>> On Fri, Jun 24, 2022 at 3:09 PM Austin Sullivan 
>> wrote:
>> >>>>>
>> >>>>> I was waiting for approval on this I2S before landing, but clearly
>> I had my order of operations inverted :)
>> >>>>>
>> >>>>> Also I could've sworn I was already in the WICG, but for some
>> reason the IPR bot doesn't think I am. I've submitted another request...
>> >>>>>
>> >>>>> On Fri, Jun 24, 2022 at 11:49 AM Yoav Weiss 
>> wrote:
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> On Mon, Jun 13, 2022 at 1:58 PM 'Austin Sullivan' via blink-dev <
>> blink-dev@chromium.org> wrote:
>> >>>>>>>
>> >>>>>>> Contact emails
>> >>>>>>>
>> >>>>>>> asu...@chromium.org
>> >>>>>>>
>> >>>>>>> Explainer
>> >>>>>>>
>> >>>>>>> None
>> >>>>>>>
>> >>>>>>> Specification
>> >>>>>>>
>> >>>>>>> https://github.com/WICG/file-system-access/pull/300
>> >>>>>>
>> >>>>>>
>> >>>>>> Anything preventing us from landing the PR?
>> >>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> Summary
>> >>>>>>>
>> >>>>>>> Allow returning a directory with both read and write permissions
>> in a single prompt for the File System Access API. Currently
>> showDirectoryPicker() always returns a read-only directory (after showing a
>> re

Re: [blink-dev] Intent to Ship: Writable directory prompts for the File System Access API

['Austin Sullivan' via blink-dev]

This feature is covered by integration tests. showDirectoryPicker() only
has manual WPT coverage
<https://crsrc.org/c/third_party/blink/web_tests/external/wpt/file-system-access/showDirectoryPicker-manual.https.html?q=showdirectorypicker>,
and since this launch only corresponds to changes in permission prompt
behavior, WPTs didn't really make sense.

On Wed, Jun 29, 2022 at 10:57 AM Chris Harrelson 
wrote:

>
>
> On Wed, Jun 29, 2022 at 7:52 AM Mike West  wrote:
>
>> LGTM2. Thank you for working with the permissions and UX teams to hammer
>> out a reasonable approach here.
>>
>> -mike
>>
>>
>> On Mon, Jun 27, 2022 at 4:40 PM 'Austin Sullivan' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> PR is landed
>>>
>>> On Fri, Jun 24, 2022 at 3:09 PM Austin Sullivan 
>>> wrote:
>>>
>>>> I was waiting for approval on this I2S before landing, but clearly I
>>>> had my order of operations inverted :)
>>>>
>>>> Also I could've sworn I was already in the WICG, but for some reason
>>>> the IPR bot doesn't think I am. I've submitted another request...
>>>>
>>>> On Fri, Jun 24, 2022 at 11:49 AM Yoav Weiss 
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Mon, Jun 13, 2022 at 1:58 PM 'Austin Sullivan' via blink-dev <
>>>>> blink-dev@chromium.org> wrote:
>>>>>
>>>>>> Contact emailsasu...@chromium.org
>>>>>>
>>>>>> ExplainerNone
>>>>>>
>>>>>> Specificationhttps://github.com/WICG/file-system-access/pull/300
>>>>>>
>>>>>
>>>>> Anything preventing us from landing the PR?
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>> Summary
>>>>>>
>>>>>> Allow returning a directory with both read and write permissions in a
>>>>>> single prompt for the File System Access API. Currently
>>>>>> showDirectoryPicker() always returns a read-only directory (after 
>>>>>> showing a
>>>>>> read access prompt), requiring a second permission prompt to get write
>>>>>> access. This double-prompt is a poor user experience and contributes to
>>>>>> confusion and permission fatigue among users.
>>>>>>
>>>>>>
>>>>>> Adds an optional "mode" option to DirectoryPickerOptions which can be
>>>>>> specified as "read" or "readwrite".
>>>>>>
>>>>>>
>>>>>> Blink componentBlink>Storage>FileSystem
>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EStorage%3EFileSystem>
>>>>>>
>>>>>> TAG reviewWe did not seek a TAG review given the small scope of this
>>>>>> feature. This launch does not add any new capabilities, but merely 
>>>>>> provides
>>>>>> the browser with enough information to combine two permission prompts 
>>>>>> into
>>>>>> one.
>>>>>>
>>>>>> TAG review statusN/A
>>>>>>
>>>>>> Risks
>>>>>>
>>>>>>
>>>>>> Interoperability and Compatibility
>>>>>>
>>>>>>
>>>>>>
>>>>>> *Gecko*: No signal
>>>>>>
>>>>>> *WebKit*: No signal
>>>>>>
>>>>>> *Web developers*: Strongly positive (
>>>>>> https://github.com/WICG/file-system-access/issues/89)
>>>>>>
>>>>>> *Other signals*:
>>>>>>
>>>>>> WebView application risks
>>>>>>
>>>>>> Does this intent deprecate or change behavior of existing APIs, such
>>>>>> that it has potentially high risk for Android WebView-based applications?
>>>>>>
>>>>>> No
>>>>>>
>>>>>>
>>>>>>
>>>>>> Debuggability
>>>>>>
>>>>>> N/A
>>>>>>
>>>>>>
>>>>>> Will this feature be supported on all six Blink platforms (Windows,
>>>>>> Mac, Linux, Chrome OS, Android, and Android WebView)?No - The File
>>>>>> System Access API is not supported on Andro

Re: [blink-dev] Intent to Ship: Writable directory prompts for the File System Access API

['Austin Sullivan' via blink-dev]

PR is landed

On Fri, Jun 24, 2022 at 3:09 PM Austin Sullivan  wrote:

> I was waiting for approval on this I2S before landing, but clearly I had
> my order of operations inverted :)
>
> Also I could've sworn I was already in the WICG, but for some reason the
> IPR bot doesn't think I am. I've submitted another request...
>
> On Fri, Jun 24, 2022 at 11:49 AM Yoav Weiss 
> wrote:
>
>>
>>
>> On Mon, Jun 13, 2022 at 1:58 PM 'Austin Sullivan' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> Contact emailsasu...@chromium.org
>>>
>>> ExplainerNone
>>>
>>> Specificationhttps://github.com/WICG/file-system-access/pull/300
>>>
>>
>> Anything preventing us from landing the PR?
>>
>>
>>>
>>>
>>> Summary
>>>
>>> Allow returning a directory with both read and write permissions in a
>>> single prompt for the File System Access API. Currently
>>> showDirectoryPicker() always returns a read-only directory (after showing a
>>> read access prompt), requiring a second permission prompt to get write
>>> access. This double-prompt is a poor user experience and contributes to
>>> confusion and permission fatigue among users.
>>>
>>>
>>> Adds an optional "mode" option to DirectoryPickerOptions which can be
>>> specified as "read" or "readwrite".
>>>
>>>
>>> Blink componentBlink>Storage>FileSystem
>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EStorage%3EFileSystem>
>>>
>>> TAG reviewWe did not seek a TAG review given the small scope of this
>>> feature. This launch does not add any new capabilities, but merely provides
>>> the browser with enough information to combine two permission prompts into
>>> one.
>>>
>>> TAG review statusN/A
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>>
>>>
>>> *Gecko*: No signal
>>>
>>> *WebKit*: No signal
>>>
>>> *Web developers*: Strongly positive (
>>> https://github.com/WICG/file-system-access/issues/89)
>>>
>>> *Other signals*:
>>>
>>> WebView application risks
>>>
>>> Does this intent deprecate or change behavior of existing APIs, such
>>> that it has potentially high risk for Android WebView-based applications?
>>>
>>> No
>>>
>>>
>>>
>>> Debuggability
>>>
>>> N/A
>>>
>>>
>>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>>> Linux, Chrome OS, Android, and Android WebView)?No - The File System
>>> Access API is not supported on Android
>>>
>>> Is this feature fully tested by web-platform-tests
>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>>> ?No
>>>
>>> Flag name
>>>
>>> Requires code in //chrome?False
>>>
>>> Tracking bughttps://crbug.com/1115632
>>>
>>> Launch bughttps://crbug.com/1213159
>>>
>>> Estimated milestones
>>>
>>> 105
>>>
>>>
>>> Anticipated spec changes
>>>
>>> Open questions about a feature may be a source of future web compat or
>>> interop issues. Please list open issues (e.g. links to known github issues
>>> in the project for the feature specification) whose resolution may
>>> introduce web compat/interop risk (e.g., changing to naming or structure of
>>> the API in a non-backward-compatible way).
>>>
>>>
>>> Link to entry on the Chrome Platform Status
>>> https://chromestatus.com/feature/6383970247770112
>>>
>>> This intent message was generated by Chrome Platform Status
>>> <https://chromestatus.com/>.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "blink-dev" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to blink-dev+unsubscr...@chromium.org.
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADs-7rHzNmDAE89ZmOEBR5CNCGprOVUBasCjijADr1LxvAd_Qg%40mail.gmail.com
>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADs-7rHzNmDAE89ZmOEBR5CNCGprOVUBasCjijADr1LxvAd_Qg%40mail.gmail.com?utm_medium=email_source=footer>
>>> .
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADs-7rEz2YSh35tGs_hq1ENBZsp-1Q3kVfEv19Chwbh8gjXTmw%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Writable directory prompts for the File System Access API

['Austin Sullivan' via blink-dev]

I was waiting for approval on this I2S before landing, but clearly I had my
order of operations inverted :)

Also I could've sworn I was already in the WICG, but for some reason the
IPR bot doesn't think I am. I've submitted another request...

On Fri, Jun 24, 2022 at 11:49 AM Yoav Weiss  wrote:

>
>
> On Mon, Jun 13, 2022 at 1:58 PM 'Austin Sullivan' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Contact emailsasu...@chromium.org
>>
>> ExplainerNone
>>
>> Specificationhttps://github.com/WICG/file-system-access/pull/300
>>
>
> Anything preventing us from landing the PR?
>
>
>>
>>
>> Summary
>>
>> Allow returning a directory with both read and write permissions in a
>> single prompt for the File System Access API. Currently
>> showDirectoryPicker() always returns a read-only directory (after showing a
>> read access prompt), requiring a second permission prompt to get write
>> access. This double-prompt is a poor user experience and contributes to
>> confusion and permission fatigue among users.
>>
>>
>> Adds an optional "mode" option to DirectoryPickerOptions which can be
>> specified as "read" or "readwrite".
>>
>>
>> Blink componentBlink>Storage>FileSystem
>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EStorage%3EFileSystem>
>>
>> TAG reviewWe did not seek a TAG review given the small scope of this
>> feature. This launch does not add any new capabilities, but merely provides
>> the browser with enough information to combine two permission prompts into
>> one.
>>
>> TAG review statusN/A
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>>
>>
>> *Gecko*: No signal
>>
>> *WebKit*: No signal
>>
>> *Web developers*: Strongly positive (
>> https://github.com/WICG/file-system-access/issues/89)
>>
>> *Other signals*:
>>
>> WebView application risks
>>
>> Does this intent deprecate or change behavior of existing APIs, such that
>> it has potentially high risk for Android WebView-based applications?
>>
>> No
>>
>>
>>
>> Debuggability
>>
>> N/A
>>
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, Chrome OS, Android, and Android WebView)?No - The File System
>> Access API is not supported on Android
>>
>> Is this feature fully tested by web-platform-tests
>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>> ?No
>>
>> Flag name
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://crbug.com/1115632
>>
>> Launch bughttps://crbug.com/1213159
>>
>> Estimated milestones
>>
>> 105
>>
>>
>> Anticipated spec changes
>>
>> Open questions about a feature may be a source of future web compat or
>> interop issues. Please list open issues (e.g. links to known github issues
>> in the project for the feature specification) whose resolution may
>> introduce web compat/interop risk (e.g., changing to naming or structure of
>> the API in a non-backward-compatible way).
>>
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/6383970247770112
>>
>> This intent message was generated by Chrome Platform Status
>> <https://chromestatus.com/>.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "blink-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to blink-dev+unsubscr...@chromium.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADs-7rHzNmDAE89ZmOEBR5CNCGprOVUBasCjijADr1LxvAd_Qg%40mail.gmail.com
>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADs-7rHzNmDAE89ZmOEBR5CNCGprOVUBasCjijADr1LxvAd_Qg%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADs-7rGaOaEQS1M2NnySmjDgA_8qasuYpSVn0_DOWuH1VG4e%2Bw%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Ship: Writable directory prompts for the File System Access API

['Austin Sullivan' via blink-dev]

An FYI TAG review has been submitted:
https://github.com/w3ctag/design-reviews/issues/749

On Fri, Jun 24, 2022 at 6:33 AM Mike Taylor  wrote:

> No worries. I think an "FYI" TAG review would be appropriate here.
>
> LGTM1 to ship w/ that.
>
> On 6/24/22 9:02 AM, 'Austin Sullivan' via blink-dev wrote:
>
> Apologies for the confusion here. I had initially been advised that a TAG
> review would not be necessary given the scope of this launch (it's an
> incremental addition which does not add any new capabilities to an API
> which is Chromium-only), but if you think this should undergo a TAG
> review then I'm happy to file one.
>
> On Thu, Jun 23, 2022 at 5:17 PM Mike Taylor  wrote:
>
>> On Wednesday, June 15, 2022 at 7:00:07 PM UTC-4 Joshua Bell wrote:
>>
>>> Since this is an incremental addition to the existing FSA API, my guess
>>> is that the positions there sufficient here:
>>>
>>> Gecko: https://mozilla.github.io/standards-positions/#native-file-system
>>> Webkit:
>>> https://lists.webkit.org/pipermail/webkit-dev/2020-August/031362.html
>>>
>>> These two engines give a Negative signal. I would not expect they would
>>> comment further on this incremental addition.
>>>
>>>
>>>
>>> On Wed, Jun 15, 2022 at 8:06 AM 'Austin Sullivan' via blink-dev <
>>> blin...@chromium.org> wrote:
>>>
>>>> No, I did not realize this was required? showDirectoryPicker() is
>>>> currently only implemented for Chromium browsers
>>>>
>>>> On Wed, Jun 15, 2022 at 7:55 AM Yoav Weiss 
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Monday, June 13, 2022 at 1:58:43 PM UTC+2 Austin Sullivan wrote:
>>>>>
>>>>>> Contact emails asu...@chromium.org
>>>>>>
>>>>>> Explainer None
>>>>>>
>>>>>> Specification https://github.com/WICG/file-system-access/pull/300
>>>>>>
>>>>>> Summary
>>>>>>
>>>>>> Allow returning a directory with both read and write permissions in a
>>>>>> single prompt for the File System Access API. Currently
>>>>>> showDirectoryPicker() always returns a read-only directory (after 
>>>>>> showing a
>>>>>> read access prompt), requiring a second permission prompt to get write
>>>>>> access. This double-prompt is a poor user experience and contributes to
>>>>>> confusion and permission fatigue among users.
>>>>>>
>>>>>> Adds an optional "mode" option to DirectoryPickerOptions which can be
>>>>>> specified as "read" or "readwrite".
>>>>>>
>>>>>>
>>>>>> Blink component Blink>Storage>FileSystem
>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EStorage%3EFileSystem>
>>>>>>
>>>>>> TAG review We did not seek a TAG review given the small scope of
>>>>>> this feature. This launch does not add any new capabilities, but merely
>>>>>> provides the browser with enough information to combine two permission
>>>>>> prompts into one.
>>>>>>
>>>>>
>>> We have filed TAG design review requests for incremental additions to
>>> the FSA API (examples: 1
>>> <https://github.com/w3ctag/design-reviews/issues/600>, 2
>>> <https://github.com/w3ctag/design-reviews/issues/598>, 3
>>> <https://github.com/w3ctag/design-reviews/issues/580>) - I think it's
>>> worth doing here as well, although I expect support since it's following
>>> existing patterns (using an enum value in an options dictionary, with a
>>> reasonable/safe default).
>>>
>>
>> Just to clarify, does this mean we can expect a TAG review for this
>> intent?
>>
>>
>>>
>>>
>>>
>>>>
>>>>>> TAG review status N/A
>>>>>>
>>>>>> Risks
>>>>>>
>>>>>>
>>>>>> Interoperability and Compatibility
>>>>>>
>>>>>> *Gecko*: No signal
>>>>>>
>>>>>> *WebKit*: No signal
>>>>>>
>>>>>
>>>>> Have you asked for signals? https://bit.ly/blink-signals
>>>>>
>>>>>
>>>>>>
>>>>

Re: [blink-dev] Re: Intent to Ship: Writable directory prompts for the File System Access API

['Austin Sullivan' via blink-dev]

Apologies for the confusion here. I had initially been advised that a TAG
review would not be necessary given the scope of this launch (it's an
incremental addition which does not add any new capabilities to an API
which is Chromium-only), but if you think this should undergo a TAG
review then I'm happy to file one.

On Thu, Jun 23, 2022 at 5:17 PM Mike Taylor  wrote:

> On Wednesday, June 15, 2022 at 7:00:07 PM UTC-4 Joshua Bell wrote:
>
>> Since this is an incremental addition to the existing FSA API, my guess
>> is that the positions there sufficient here:
>>
>> Gecko: https://mozilla.github.io/standards-positions/#native-file-system
>> Webkit:
>> https://lists.webkit.org/pipermail/webkit-dev/2020-August/031362.html
>>
>> These two engines give a Negative signal. I would not expect they would
>> comment further on this incremental addition.
>>
>>
>>
>> On Wed, Jun 15, 2022 at 8:06 AM 'Austin Sullivan' via blink-dev <
>> blin...@chromium.org> wrote:
>>
>>> No, I did not realize this was required? showDirectoryPicker() is
>>> currently only implemented for Chromium browsers
>>>
>>> On Wed, Jun 15, 2022 at 7:55 AM Yoav Weiss  wrote:
>>>
>>>>
>>>>
>>>> On Monday, June 13, 2022 at 1:58:43 PM UTC+2 Austin Sullivan wrote:
>>>>
>>>>> Contact emailsasu...@chromium.org
>>>>>
>>>>> ExplainerNone
>>>>>
>>>>> Specificationhttps://github.com/WICG/file-system-access/pull/300
>>>>>
>>>>> Summary
>>>>>
>>>>> Allow returning a directory with both read and write permissions in a
>>>>> single prompt for the File System Access API. Currently
>>>>> showDirectoryPicker() always returns a read-only directory (after showing 
>>>>> a
>>>>> read access prompt), requiring a second permission prompt to get write
>>>>> access. This double-prompt is a poor user experience and contributes to
>>>>> confusion and permission fatigue among users.
>>>>>
>>>>>
>>>>> Adds an optional "mode" option to DirectoryPickerOptions which can be
>>>>> specified as "read" or "readwrite".
>>>>>
>>>>>
>>>>> Blink componentBlink>Storage>FileSystem
>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EStorage%3EFileSystem>
>>>>>
>>>>> TAG reviewWe did not seek a TAG review given the small scope of this
>>>>> feature. This launch does not add any new capabilities, but merely 
>>>>> provides
>>>>> the browser with enough information to combine two permission prompts into
>>>>> one.
>>>>>
>>>>
>> We have filed TAG design review requests for incremental additions to the
>> FSA API (examples: 1
>> <https://github.com/w3ctag/design-reviews/issues/600>, 2
>> <https://github.com/w3ctag/design-reviews/issues/598>, 3
>> <https://github.com/w3ctag/design-reviews/issues/580>) - I think it's
>> worth doing here as well, although I expect support since it's following
>> existing patterns (using an enum value in an options dictionary, with a
>> reasonable/safe default).
>>
>
> Just to clarify, does this mean we can expect a TAG review for this intent?
>
>
>>
>>
>>
>>>
>>>>> TAG review statusN/A
>>>>>
>>>>> Risks
>>>>>
>>>>>
>>>>> Interoperability and Compatibility
>>>>>
>>>>>
>>>>>
>>>>> *Gecko*: No signal
>>>>>
>>>>> *WebKit*: No signal
>>>>>
>>>>
>>>> Have you asked for signals? https://bit.ly/blink-signals
>>>>
>>>>
>>>>>
>>>>> *Web developers*: Strongly positive (
>>>>> https://github.com/WICG/file-system-access/issues/89)
>>>>>
>>>>> *Other signals*:
>>>>>
>>>>> WebView application risks
>>>>>
>>>>> Does this intent deprecate or change behavior of existing APIs, such
>>>>> that it has potentially high risk for Android WebView-based applications?
>>>>>
>>>>> No
>>>>>
>>>>>
>>>>>
>>>>> Debuggability
>>>>>
>>>>> N/A
>>>>>
>&g

[blink-dev] Re: Intent to Ship: Writable directory prompts for the File System Access API

['Austin Sullivan' via blink-dev]

No, I did not realize this was required? showDirectoryPicker() is currently
only implemented for Chromium browsers

On Wed, Jun 15, 2022 at 7:55 AM Yoav Weiss  wrote:

>
>
> On Monday, June 13, 2022 at 1:58:43 PM UTC+2 Austin Sullivan wrote:
>
>> Contact emailsasu...@chromium.org
>>
>> ExplainerNone
>>
>> Specificationhttps://github.com/WICG/file-system-access/pull/300
>>
>> Summary
>>
>> Allow returning a directory with both read and write permissions in a
>> single prompt for the File System Access API. Currently
>> showDirectoryPicker() always returns a read-only directory (after showing a
>> read access prompt), requiring a second permission prompt to get write
>> access. This double-prompt is a poor user experience and contributes to
>> confusion and permission fatigue among users.
>>
>>
>> Adds an optional "mode" option to DirectoryPickerOptions which can be
>> specified as "read" or "readwrite".
>>
>>
>> Blink componentBlink>Storage>FileSystem
>> 
>>
>> TAG reviewWe did not seek a TAG review given the small scope of this
>> feature. This launch does not add any new capabilities, but merely provides
>> the browser with enough information to combine two permission prompts into
>> one.
>>
>> TAG review statusN/A
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>>
>>
>> *Gecko*: No signal
>>
>> *WebKit*: No signal
>>
>
> Have you asked for signals? https://bit.ly/blink-signals
>
>
>>
>> *Web developers*: Strongly positive (
>> https://github.com/WICG/file-system-access/issues/89)
>>
>> *Other signals*:
>>
>> WebView application risks
>>
>> Does this intent deprecate or change behavior of existing APIs, such that
>> it has potentially high risk for Android WebView-based applications?
>>
>> No
>>
>>
>>
>> Debuggability
>>
>> N/A
>>
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, Chrome OS, Android, and Android WebView)?No - The File System
>> Access API is not supported on Android
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?No
>>
>> Flag name
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://crbug.com/1115632
>>
>> Launch bughttps://crbug.com/1213159
>>
>> Estimated milestones
>>
>> 105
>>
>>
>> Anticipated spec changes
>>
>> Open questions about a feature may be a source of future web compat or
>> interop issues. Please list open issues (e.g. links to known github issues
>> in the project for the feature specification) whose resolution may
>> introduce web compat/interop risk (e.g., changing to naming or structure of
>> the API in a non-backward-compatible way).
>>
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/6383970247770112
>>
>> This intent message was generated by Chrome Platform Status
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADs-7rEsYumZp%3Dd9VuzMixOq5xB7kD0HxrQ2QwYvLM_K%2B7LaLw%40mail.gmail.com.

[blink-dev] Intent to Ship: Writable directory prompts for the File System Access API

['Austin Sullivan' via blink-dev]

Contact emailsasu...@chromium.org

ExplainerNone

Specificationhttps://github.com/WICG/file-system-access/pull/300

Summary

Allow returning a directory with both read and write permissions in a
single prompt for the File System Access API. Currently
showDirectoryPicker() always returns a read-only directory (after showing a
read access prompt), requiring a second permission prompt to get write
access. This double-prompt is a poor user experience and contributes to
confusion and permission fatigue among users.


Adds an optional "mode" option to DirectoryPickerOptions which can be
specified as "read" or "readwrite".


Blink componentBlink>Storage>FileSystem


TAG reviewWe did not seek a TAG review given the small scope of this
feature. This launch does not add any new capabilities, but merely provides
the browser with enough information to combine two permission prompts into
one.

TAG review statusN/A

Risks


Interoperability and Compatibility



*Gecko*: No signal

*WebKit*: No signal

*Web developers*: Strongly positive (
https://github.com/WICG/file-system-access/issues/89)

*Other signals*:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that
it has potentially high risk for Android WebView-based applications?

No



Debuggability

N/A


Will this feature be supported on all six Blink platforms (Windows, Mac,
Linux, Chrome OS, Android, and Android WebView)?No - The File System Access
API is not supported on Android

Is this feature fully tested by web-platform-tests

?No

Flag name

Requires code in //chrome?False

Tracking bughttps://crbug.com/1115632

Launch bughttps://crbug.com/1213159

Estimated milestones

105


Anticipated spec changes

Open questions about a feature may be a source of future web compat or
interop issues. Please list open issues (e.g. links to known github issues
in the project for the feature specification) whose resolution may
introduce web compat/interop risk (e.g., changing to naming or structure of
the API in a non-backward-compatible way).


Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/6383970247770112

This intent message was generated by Chrome Platform Status
.

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADs-7rHzNmDAE89ZmOEBR5CNCGprOVUBasCjijADr1LxvAd_Qg%40mail.gmail.com.

[blink-dev] Re: Intent to Extend Origin Trial: Origin Private File System extension: AccessHandle

['Austin Sullivan' via blink-dev]

DISREGARD. This is a duplicate of 
https://groups.google.com/a/chromium.org/g/blink-dev/c/yNslidDtNho/m/IEPD25X_AAAJ

On Thursday, January 20, 2022 at 9:42:39 AM UTC-8 Austin Sullivan wrote:

> Contact emailsasu...@chromium.org, five...@chromium.org, m...@chromium.org
> , rs...@chromium.org
>
> Explainer
> https://github.com/WICG/file-system-access/blob/main/AccessHandle.md
>
> Specification
>
> Summary
>
> The Origin Private File System (OPFS, part of the File System Access API) 
> is augmented with a new surface that brings very performant access to data. 
> This new surface differs from existing ones by offering in-place and 
> exclusive write access to a file’s content. This change, along with the 
> ability to consistently read unflushed modifications and the availability 
> of a synchronous variant on dedicated workers, significantly improves 
> performance and unblocks new use cases.
>
>
> Included in this origin trial is also a version of the 
> FileSystemHandle::move() method, currently limited to files in the OPFS 
> only. The move() method will be shipped separately with its own intent (
> https://chromestatus.com/feature/5640802622504960), but this limited 
> subset is included in this origin trial because it significantly improves 
> the performance and ease of use of the OPFS.
>
> Blink componentBlink>Storage>FileSystem 
> 
>
> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/664
>
> TAG review statusPending
>
> Risks
>
>
> Interoperability and Compatibility
>
> The feature has to be compatible with existing ways to access data on OPFS 
> i.e., createWritable() and getFile(). The use of write locks and care for 
> backwards compatibility should mean that the risk here is low. In order to 
> ease compatibility concerns in the future, we've added an optional 'mode' 
> parameter to createAccessHandle()/createSyncAccessHandle(). This allows us 
> to eventually extend AccessHandle functionality to non-OPFS file systems 
> without necessarily taking the OPFS behaviour as default (more details 
> here: 
> https://github.com/WICG/file-system-access/blob/main/AccessHandle.md#exposing-accesshandles-on-all-filesystems).
>  
> There is a risk of interoperability between vendors, pending the position 
> on implementing this surface. This design is the result of feedback from 
> Gecko and WebKit, who reviewed previous iterations of this functionality 
> and gave feedback that it should integrate more strongly with OPFS. We 
> believe that the new design, when paired with a separate streams-based 
> extension to OPFS, meets these goals. However, we have not yet received 
> work back as to whether they agree with our assessment.
>
>
> Gecko: No signal on official Request for Position (
> https://github.com/mozilla/standards-positions/issues/562), but 
> supportive of migrating the spec to whatwg (
> https://github.com/whatwg/sg/issues/176).
>
> WebKit: In development (
> https://lists.webkit.org/pipermail/webkit-dev/2021-August/031934.html) 
> Request for position was not answered, but the feature is being implemented 
> and is available in TP. See reference bug: 
> https://bugs.webkit.org/show_bug.cgi?id=231185
>
> Web developers: No signals
>
> Other signals:
>
>
> Goals for experimentation
>
> In general, we want to validate the new surface against "real world" use 
> cases from our partners and developers at large. In particular, we are 
> interested in the relative usage between the sync and async methods, since 
> this could have an impact on performance when using Asyncify. We also would 
> like to receive qualitative feedback on the ease of use of the API from 
> within Wasm.
>
>
> Reason this experiment is being extended
>
> We're working with a partner, but they need more time to test and give 
> feedback on the API.
>
> Ongoing technical constraints
>
> None
>
> Debuggability
>
> Basic tooling: Autocomplete works as described in "New WebIDL/DOM 
> interfaces and attributes". Extended tooling: we'll eventually want to be 
> able to explore files stored in OPFS. There are two tracking bugs related 
> to this: crbug.com/256067 and crbug.com/735618. This API doesn't really 
> add new storage backends, just new ways to interact with files, so we'd be 
> covered by those as well. 
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac, 
> Linux, Chrome OS, Android, and Android WebView)?No
>
> Is this feature fully tested by web-platform-tests 
> 
> ?Yes
>
> DevTrial instructions
> https://github.com/WICG/file-system-access/blob/main/AccessHandle.md#trying-it-out
>
> Flag nameFileSystemAccessAccessHandle
>
> Requires code in //chrome?False
>
> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1218431
>
> Launch bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1232436
>

Re: [blink-dev] Re: Intent to Ship: Clipboard: Preserve PNG metadata

['Austin Sullivan' via blink-dev]

I just chimed in on the GitHub thread you linked. It's not entirely
related, since this change is simply putting us in line with other browsers
and we want to reflect this newly consistent behavior in the spec, while
the HTML sanitization changes seem like they'll require a bit more
discussion and perhaps include more substantial changes. Regardless, if
you'll be updating the spec for this change that info should be useful.
Feel free to reach out if you have other questions.

On Tue, Aug 31, 2021 at 10:03 AM Anupam Snigdha 
wrote:

> I can probably add something to this discussion. In this
>  thread, we are
> discussing about making the sanitization process more explicit in async
> clipboard APIs spec during read & write. We have proposed the HTML
> sanitization behavior here
> . I
> have limited knowledge on the sanitization process in image/png, so it'd be
> nice if someone can chime in that thread and describe the change that is
> being shipped here so we can standardize this behavior. I can make the spec
> changes once we all agree on the specifics.
>
> -Anupam
>
> On Thu, Aug 26, 2021 at 12:07 PM Mike West  wrote:
>
>> Friendly ping to Yoav's question. I would also like to see some sort of
>> hook in the spec that made this mechanism explicit. I think this is a
>> reasonable change to ship, I just want to ensure we lock in reasonable
>> behavior at the spec level. Is that something y'all can take care of?
>>
>> Thanks!
>>
>> -mike
>>
>>
>> On Wed, Aug 18, 2021 at 11:19 PM Yoav Weiss 
>> wrote:
>>
>>> Changing the spec to explicitly say that no sanitization is to be done
>>> on input would be good. I agree that aligning behavior with other
>>> implementers is the right thing to do, but we need to document that
>>> behavior. Can y'all please file a spec PR to that effect?
>>>
>>> On Wed, Aug 18, 2021 at 10:53 PM Marijn Kruisselbrink 
>>> wrote:
>>>
 While I agree that it would be nice for the clipboard API to better
 specify what sanitization is and isn't done, do note that this change
 merely brings us in line with other existing implementations. I.e. both
 Safari and Firefox already ship the behavior we're proposing to ship with
 here as well. https://w3c.github.io/clipboard-apis/#image-transcode
 would probably be the most relevant section in the spec as it stands today,
 although it only addresses writing images to the clipboard, not reading
 images from the clipboard.

 So I don't think changes to the spec are needed for this intent, as the
 spec arguably already matches our proposed new behavior. Nowhere (except
 for some subset of pasting HTML) does it mention any sanitization on
 reading from the clipboard, while it does explicitly mention sanitizing
 data as it is being written to the clipboard. I think what we're proposing
 here is fully in line with that behavior (and our previous/current behavior
 is not spec compliant).

 On Fri, Aug 13, 2021 at 9:27 AM Anupam Snigdha <
 snianu.micros...@gmail.com> wrote:

> I don't see a spec linked in the I2S. Are we planning to make changes
> in the Clipboard API  at some
> point in the future? I think it would be nice to document what unsanitized
> content means and the security/privacy concerns related to it.
>
> -Anupam
>
> On Thu, Aug 12, 2021 at 12:55 PM Alex Russell <
> slightly...@chromium.org> wrote:
>
>> LGTM1 with caveats:
>>
>>- this sanitization behavior was previously discussed with the
>>TAG, and not updating them on it is a mistake. Please file a 
>> non-blocking
>>FYI with them
>>- the explainer was less clear than the bug, requiring the OWNERs
>>to read all the linked threads in detail. Ideally, an Explainer should
>>clarify what is changing, why, and who it helps.
>>- Please post explainers as GH markdown files rather than google
>>docs
>>
>> Thanks!
>>
>> On Friday, August 6, 2021 at 10:47:04 AM UTC-7 Austin Sullivan wrote:
>>
>>> *Contact emails*
>>> asu...@chromium.org, m...@chromium.org
>>>
>>> Explainer
>>>
>>> https://docs.google.com/document/d/1qZonN0xhfkuAOV58WOAMcPXjOB7uCfms3tf_ZDXNDks/edit?usp=sharing
>>>
>>> Specification
>>>
>>> Summary
>>>
>>> Read unsanitized PNGs from the system clipboard. This will apply to
>>> both DataTransfer and the Async Clipboard API 
>>> (navigator.clipboard.read()).
>>>
>>>
>>> Motivation
>>> Currently, reading PNGs from the system clipboard involves
>>> sanitizing the image by stripping its metadata. There is a strong 
>>> argument
>>> that images from the system clipboard should not be sanitized on read, 
>>> and
>>> this behavior