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
