Re: Moving to Last Call

On Jun 10, 2013, at 3:40 AM, Andrew Wilson <atwilson@google.com> wrote:

> 
> On Fri, Jun 7, 2013 at 10:04 PM, Justin DeWitt <dewittj@google.com> wrote:
> Today, Chrome requires that requestPermission be called from within a callback handler for a user action.  The spec as written makes no mention of such a limitation.  Was it the intention of this WG to remove that restriction?  I searched a bit in the archives but didn't see a discussion on this topic.
> The reason we added this to the original proposal was to prevent web pages from spamming the user with permission requests, although perhaps we've decided we don't need this any longer? I don't recall any discussion on this topic either.

There was no discussion about this specific point, and as far as I can recall there was never any restriction written in the spec. Geolocation suffers from this same issue.
> The presence of the "show" event has a few downsides.  First, it can leak information about the user's idle status, since it's unlikely that UAs will display notifications while the screen is locked.
Websites can detect a user’s idle status in other ways than just this. For example, they could have a interval timer firing a heartbeat.
> In one section ( http://www.w3.org/TR/notifications/#using-events ) the "close" event is said to be fired when the notification is closed by the user, and in another section ( http://www.w3.org/TR/notifications/#closing-a-notification ) the spec says that the "close steps" must be run (and the "close" event fired) whether the notification is closed by the system or by the user. When writing an application, it is essential to know whether the close event has been generated by the user (indicating explicit acknowledgement and dismissal) or by the system (for other unrelated reasons such as screen real estate or resource limitations).  So, I recommend either modifying the spec to only fire the close event when the user has closed the notification, or to add a parameter to the onClose event handler that indicates whether the user closed the notification.
> I'd request that we continue to notify the application for the non-user-initiated close event so the application has a way to clean up any of its data structures related to the notification which may no longer be needed once it is no longer around (i.e. the application needs to know whenever a notification is closed, regardless of its cause). If the application needs to differentiate between different types of close events, I'd be OK with having some attribute on the event itself to indicate this.


Is there a specific situation where understanding the reason is crucial to the page’s functionality? On iOS and Mac, for example, notifications are expected to act like taps on the shoulder, and not necessarily return vital information that users cannot get from the web page or app. Given that the spec declare the event model is best-effort, the web page will not get an accurate picture of which notifications a user has seen and acknowledged, even with this additional flag.

Jon