W3C home > Mailing lists > Public > public-web-intents@w3.org > December 2011

Re: Non-visible intents

From: Charles Pritchard <chuck@jumis.com>
Date: Tue, 06 Dec 2011 23:40:40 -0800
Message-ID: <4EDF1878.3050800@jumis.com>
To: public-web-intents@w3.org
I appreciate the cases.

To be clear: Notifications API.

And major issue:
"A script event is considered a user gesture if it directly resulted 
from the user using an input device, and the event is generated by the 
user agent, not a script"

There are currently no means of pushing a user gesture across contexts.

That said, for my purposes, Chrome has a notifications permission, and 
so I still get what I want if users have installed additional permissions.

This kind-of comes up with Chrome background pages:
One can't push a full screen call from a background page onto the 
current page, because the user gesture will not transfer.

Anyway, given all that, I'm proposing that a "disposition=notification", 
would register permission to send a notification, when that intent is 

This allows me to do these "invisible" intents, while providing feedback 
if necessary, per timeless and Greg Billock's comments.
It avoid the hack of doing non-visible inline areas, and explicitly 
supports notifications through registration of the disposition, so the 
user gesture issue is not an issue.


On 12/6/11 8:25 PM, timeless wrote:
> Offhand, I'd say "no. Notifications almost certainly doesn't cover that case".
> * Windows 7 uses a notification to tell you that the wifi network to
> which you've connected seems to require additional credentials.
> * I've had notifications from Windows and Outlook that my credentials
> are bad/expired/expiring.
> * Technically, when my credit card is misused, I get a "notification"
> from my credit card company.
> That said, the notifications I get from each of these are more
> persistent than I expect a notification api would be, and yet the
> concern is fairly equivalent.
> Let's consider a simple case:
> 1. I /think/ I'm @eBay.
> 2. I want to make a purchase.
> 3. It triggers a "transfer-money" action.
> 4. UA offers me PayPal and Discover as choices.
> 5. I select Discover.
> 6. Somehow Discover is configured to automatically dispense simple transactions.
> 7. Unfortunately, there's something wrong with this transaction.
> A. Perhaps eBay wants more money than my preapproved per transaction limit.
> B. Perhaps I've hit my monthly limit.
> C. Perhaps my card was suspended.
> D. Perhaps the merchant is suspect.
> 8. Discover wants to tell this to me.
> Let's make some changes to this scenario:
> 1a. I'm not buying from eBay, instead it's eBay market place.
> 1b. I'm actually at eBoy.
> I haven't had time to look over the Intents proposal. And I haven't
> spent any time reviewing the display bits. I'm hoping to play with a
> demo build next week....
> On the topic of Notifications... Generally, I believe that we do *not*
> want Notifications to outlive the sites which trigger them. It's too
> easy for an evil site to do a hit and run notification asking you for
> something.
> If the site I'm visiting is evil and is trying to con me out of money,
> then a system where it can make a request and then navigate away to
> prevent me from seeing my wallet provider's complaint/warning would be
> bad. Now ideally, Discover would contact me by Phone, and the same
> should be said for PayPal, but I don't think all intent providers
> would have that provision and some will probably have a reasonable
> requirement to express a message that the user will actually see.
> Sure, we could require users to allow Intent Providers to have access
> to persistent Notifications, but I don't think that's a good
> requirement. Some Intent Providers will be truly trusted and
> trustworthy, some will just be convenient, transient, hacks, or
> hackable/unreliable, but all of them will probably be used by users
> without much consideration -- just like the rest of the web.
> --
> I won't have time this week to reply to other messages on the list
> (short vacation starting Wednesday night and I generally send my
> replies after work).
> On 12/6/11, Charles Pritchard<chuck@jumis.com>  wrote:
>> Does the notifications mechanism work for this?
>> On Dec 6, 2011, at 3:46 PM, Greg Billock<gbillock@google.com>  wrote:
>>> James, Paul, and I have spent quite a bit of time discussing this. We
>>> have always come back to the question of how do you let the user deal
>>> with exceptional circumstances and status updates. There has to be
>>> some UI surface for a background disposition service, so that the user
>>> can get to it to shut it down if need be. So then we've always ended
>>> up thinking that that UI surface ought to be where the service can
>>> display status messages or perform error handling. But at that point,
>>> it basically looks like an inline disposition.
>>> We've discussed various permutations of Web Workers, invisible tabs,
>>> and so forth, but so far at least, the above line of thinking has
>>> always seemed more compelling.
>>> For an example, think about a 'login' intent. This might often run to
>>> completion with no problems whatsoever. But suppose even in the case
>>> of a success, the service wishes to display a warning: "someone from
>>> this unusual IP address has tried to access your account", or
>>> something more functional: "You enabled two-factor auth, and you need
>>> to enter your credential again." Or even something mechanical, like a
>>> 503 error from the login service. That needs to be displayed
>>> somewhere. Leaving a temporary UI surface for the service to display
>>> an in-process throbber or progress bar is even useful -- it lets the
>>> user know something is happening, and it doesn't look like the client
>>> page is being unresponsive -- so that it's possible for the user to
>>> know to attribute the slowness to the service provider.
>>> On Tue, Dec 6, 2011 at 2:57 PM, Charles Pritchard<chuck@jumis.com>  wrote:
>>>> There are now two disposition types: inline and window, I'm considering a
>>>> non-visible type, which would essentially be a zero-height/width inline.
>>>> Consider a backup service, the user merely means to backup, or "copy"
>>>> their
>>>> file, to a service like dropbox, but has no interest in a window popping
>>>> up,
>>>> nor seeing an<iframe>  confirmation.
>>>> Is that a consideration worth extending, or should<iframe>  be used
>>>> regardless?
>>>> This is a case most often handled, in the present web, by using OAuth and
>>>> creating a new window when authentication fails (or has not taken place).
>>>> In intents, it might be two-fold, having a "login" intent, and a "backup"
>>>> intent.
>>>> I've found that OAuth logins are sufficient for checking credentials:
>>>> I've
>>>> not needed OpenID.
>>>> Though sites haven't standardized on an end-point, most APIs have a
>>>> callback
>>>> that return a user name and associated information.
>>>> Let me point out that an OAuth login intent is always useful. Even if a
>>>> user
>>>> has logged in, there's every reason to think they may want to "switch
>>>> users".
>>>> As for this backup concept, again, I don't need to see a popup window
>>>> every
>>>> single time I choose to backup a file.
>>>> While the<iframe>  concept works, it's a bit of a kludge. I'd prefer that
>>>> the author check for confirmation from the target intent and display it
>>>> in a
>>>> more integrated manner, such as saying "All files have been backed up".
>>>> That's not something an end-point has enough information to state.
>>>> -Charles
Received on Wednesday, 7 December 2011 07:41:14 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:14:45 UTC