Re: File API - where are the missing parts?

> > * Should permissions persist? If you're working in an editor and reload the tab, being hit with a flurry of permission prompts is less than ideal. But if you visit it again in a day or a year? And, similar to the "template" case above, what if you use a web-based editor to modify a file, then revisit the site a year later.

> I don't think long persistence on file-location is a feasible idea. But the option to choose persistence within a session seems a viable compromise. You'll still need to click the dialog away once, but then you can work uninterrupted.

There is already a case similar to this with built in popup blockers
in most browsers where you can allow once or always allow a similar
approach could be taken with this.

On Tue, Feb 23, 2016 at 4:50 PM, Florian Bösch <pyalot@gmail.com> wrote:
> On Tue, Feb 23, 2016 at 7:06 PM, Joshua Bell <jsbell@google.com> wrote:
>>
>> On Tue, Feb 23, 2016 at 7:12 AM, Florian Bösch <pyalot@gmail.com> wrote:
>>>
>>> On Tue, Feb 23, 2016 at 2:48 AM, Jonas Sicking <jonas@sicking.cc> wrote:
>>>>
>>>> Is the last bullet here really accurate? How can you use existing APIs
>>>> to listen to file modifications?
>>>
>>> I have not tested this on all UAs, but in Google Chrome what you can do
>>> is to set an interval to check a files.lastModified date, and if a
>>> modification is detected, read it in again with a FileReader and that works
>>> fine.
>>
>>
>> Huh... we should probably specify and/or fix that.
>
> Specify rather than fix, please.
>
>>>>
>>>> There are also APIs implemented in several browsers for opening a whole
>>>> directory of files from a webpage. This has been possible for some time in
>>>> Chrome, and support was also recently added to Firefox and Edge. I'm not
>>>> sure how interoperable these APIs are across browsers though :(
>>
>>
>> IIRC, Edge's API[1] mimics Chrome's, and you can polyfill Firefox's API
>> [2] on top of Chrome/Edge's[3]. So in theory if Firefox's pleases developers
>> they can adopt the polyfill, and other browsers can transition to native
>> support.
>>
>> [1] https://lists.w3.org/Archives/Public/public-wicg/2015Sep/0000.html
>> [2] https://wicg.github.io/directory-upload/proposal.html
>> [3] https://github.com/WICG/directory-upload/blob/gh-pages/polyfill.js
>>
>> ... or just read Ali's excellent summary:
>>
>> https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0245.html
>>
>> (But that's all a tangent to Florian's main use cases...)
>
> It's good to know this on a standards track.
>
>> True, but if we determine that permissions must be granted then the API
>> needs to be designed to handle it, e.g. entry points to the API surface are
>> through a requestPermission() API, everything is async, etc.
>
>
> Ack
>
>>
>> One concern is: what capabilities are granted by this action? Can the
>> web-app re-save the file? Can it re-read the file? Does that permission
>> persist across sessions? For example, if I save a document template from a
>> site I would not expect the site to be able to read the file after I've
>> edited with an unrelated file editor.
>>>
>>> Save many files to a user pickable folder: same as above
>>> Working directory: this is more something that would go on in the
>>> background of a UA, it would have to establish a "working directory" per tab
>>> rather than UA-wide. No UX issues with that.
>>
>> Agreed. Likely doesn't even need to be specified - it'd just be a "least
>> surprise" behavior by the UA.
>
> The save to directory case is less easy to handle because it impinges on
> overwrite. After some thought, I'd move that to the more difficult UX cases.
>
>>
>> * Since "File > Open" is supported today (via <input type=file>) we must
>> be careful about exposing functionality that has similar UX (i.e. a native
>> file open dialog) but that implicitly grants extra permissions (e.g. being
>> able to modify the file). This points to either additional UX during the
>> action, UX when the app wants to write, or a more general permission granted
>> to the origin for some scope (file? directory?).
>
> I'd think this to be a non formative note on implementation for UAs. The
> mechanism of denying an action by the API should be fairly straightforward.
>
>>
>> * Should permissions persist? If you're working in an editor and reload
>> the tab, being hit with a flurry of permission prompts is less than ideal.
>> But if you visit it again in a day or a year? And, similar to the "template"
>> case above, what if you use a web-based editor to modify a file, then
>> revisit the site a year later.
>
> I don't think long persistence on file-location is a feasible idea. But the
> option to choose persistence within a session seems a viable compromise.
> You'll still need to click the dialog away once, but then you can work
> uninterrupted.

Received on Tuesday, 23 February 2016 22:29:43 UTC