Re: [w3c/clipboard-apis] Clipboard Permission (#51)

Hmm, I'm not convinced that either of those problems are going to be concerns in practice (at least initially). I also think that if we add a requestClipboard() function it's going to tickle the same concerns that Mozilla's had with a general request() function and so I don't think it's actually any better to do that. 

I would also add that request() functions that don't return a capability to operate on don't seem like an ideal design. If we had requestClipboard() that returned a clipboard object that could be operated on, it would be a more sensible API.

Unless we go down that path, I think it would be better to try to get away without adding a request() function. The biggest danger would be that in some browser users would see 2 prompts for read() and write(). But I can't imagine any browsers having such an implementation in practice. I still feel that listening to the change event should just be tied to the read permission but I'd be interested to hear use cases for keeping them separate.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/clipboard-apis/issues/51#issuecomment-330712028