> > * 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 <pya...@gmail.com> wrote: > On Tue, Feb 23, 2016 at 7:06 PM, Joshua Bell <jsb...@google.com> wrote: >> >> On Tue, Feb 23, 2016 at 7:12 AM, Florian Bösch <pya...@gmail.com> wrote: >>> >>> On Tue, Feb 23, 2016 at 2:48 AM, Jonas Sicking <jo...@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 mimics Chrome's, and you can polyfill Firefox's API >>  on top of Chrome/Edge's. So in theory if Firefox's pleases developers >> they can adopt the polyfill, and other browsers can transition to native >> support. >> >>  https://lists.w3.org/Archives/Public/public-wicg/2015Sep/0000.html >>  https://wicg.github.io/directory-upload/proposal.html >>  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.