- From: Cameron Heavon-Jones <cmhjones@gmail.com>
- Date: Wed, 27 Jul 2011 18:44:34 +0100
On 27/07/2011, at 5:30 PM, Mike Hanson wrote: > The challenging use case, and one that we had trouble with when we prototyped the Contacts API, is for ongoing or persistent access. The best approach we have right now is to use explicit markup to "sandbox" the permissions grant away from untrusted code. > > In the Contacts case, for example, autocomplete of email addresses, names, and phone numbers was a desired use case. A naive approach is to let the web app read the entire database and perform autocompletion in content. The safe approach, which was harder and less flexible, is to attach autocomplete behavior to input type="tel" and "email", and to set the autocompleted value only when the user has selected it. This is a sound approach, i'm not sure of the implementation complexities. The mapping of "tel" and "email" inputs to a contacts list is functional, not systematic. Might this be extended for some other inputs: date(*), url, search etc? This functionality may be declared and defined through a new attribute, since autocomplete is already used, something like "autoassist"? Maybe this would be able to over-ride the default "file" input behaviour of launching a popup in the case i just want to manually enter a file:/// > > There are definite UX limitations to that approach - the content can't provide visual hinting during the autocomplete, for example (it would be nice if a photo gallery could trim down the set of photos from my friends as I narrow in on the name). This would seems to be ok as long as the contents remain sandboxed until selection is confirmed. > The limitations create an incentive for content to try to get the full set of data anyway, through some other channel. As Roc commented, finding a way to be comfortable with a higher-level permissions grant that persisted over a longer span could be one way to address that. It would be nice for a page\site\app to still be able to access a full contacts list if desired. Though it would seem to extend the integration into the full Contacts API which is of far larger scope. > -- > Michael Hanson, Mozilla Labs Thanks, Cameron Jones
Received on Wednesday, 27 July 2011 10:44:34 UTC