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

2022-06-24 Thread 'Mike Taylor' via blink-dev 
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 
 

 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 
> , 2 , 3 
> ) - 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


 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+...@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
>>  
>> 
>> .
>>
>

-- 
You

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

2022-06-24 Thread '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
>> 
>>
>> 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
>>> , 2
>>> , 3
>>> ) - 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
>
>
>>
>> *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 bug https://crbug.com/1115632
>>
>> Launch bug https://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

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

2022-06-24 Thread Mike Taylor 

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  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




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
, 2
, 3
) - 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


/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

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

2022-06-24 Thread '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
> 
>
> 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
>> , 2
>> , 3
>> ) - 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
>
>
> 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.
>>>

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

2022-06-15 Thread Joshua Bell 
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 <
blink-dev@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
>>> 
>>>
>>> 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 ,
2 , 3
) - 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).



>
>>> 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
> 
> .
>

-- 
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

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

2022-06-15 Thread '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] Re: Intent to Ship: Writable directory prompts for the File System Access API

2022-06-15 Thread Yoav Weiss 


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/6629a5b6-2256-4358-8453-7f241ccd9295n%40chromium.org.