Re: [WebNotifications] omnibus feedback reply, new draft

This is great stuff - I have a few obscure comments/questions below, but
overall this is looking very cool!



> > Section 8:
> >
> > Should passing an unsupported type of web content to
> createWebNotification() generate an error event?
>
> I think it should throw an exception.  Since there is no Notification
> object yet to target, an error event doesn't make sense.
>
> My concern is that at the time you call createWebNotification(), the web
content has not yet been loaded, so it's not possible to throw an exception
as you don't yet know the mime-type. I guess I'm saying that section 7.1
doesn't really state what should happen if the content is not supported, and
I think an error event would be appropriate.

Notes about the recent changes:

Section 4:
For the onclick event, I'm wondering how that should be interpreted in the
case of HTML notifications. If I click on a link in an HTML notification,
does the parent notification still receive an onclick event? Can the script
in the notification consume the event and not have it bubbled up to the
notification creator?

-=-=-
Section 5:

 attribute unsigned long  permissionLevel <#dfn-permissionlevel>;

can/should this be "readonly"? Not sure whether IDL supports that or not.

-=-=-

If the current permission level is PERMISSION_DENIED, the user agent may
take no action in response to requestPermission, and must throw an
exception.

This seems unclearly stated - do you mean that the user agent is free to
display the permissions UI again, and only if it decides *not* to display
the UI it must throw an exception?

-=-=-
johnnyg wrote:
> If the request for permission can be satisfied with no action, I think the
method should just return and call the callback immediately.

The spec seems to contradict this:

If the user agent does not initiate a request for permission with the user,
e.g., because if a permission decision has already been recently made, the
user agent must throw an Exception.

My reading of the spec is if the user calls requestPermission() but the UA
doesn't display permissions UI, it must throw an exception. But I think this
is not your intention in the case where the user has already previously
granted permission, so we should clarify this.

-=-=-
Section 8.1:
It's not clear to me when notifications are put on the list of active
notifications - is this supposed to be done by the algorithm in section 8.2?

Also, it looks like the replace algorithm only examines the list of active
notifications - what's the behavior when there's an existing *queued*
notification with the same replace ID as the new notification? It seems like
we should replace queued notifications also?

-=-=-
Section 8.2:
Fetch the resource given by url (for createWebNotification) or by iconUrl
 (for createNotification), using the algorithm defined in [HTML5 <#HTML5>]
with the *synchronous* flag set.

The use of the synchronous flag makes me nervous - is the intent to block
script execution when show() is invoked until the resource is loaded? If so,
that seems very undesirable. If the intent is to ensure that notifications
are displayed in the correct order regardless of how quickly their content
is loaded, then I'm not sure this is the right way to do it if it also
blocks script execution.

Speaking of which, what guarantees do we want to make regarding the display
of notifications? Do we want to guarantee that notifications always are
displayed in the order in which show() is invoked, regardless of how
quickly/slowly their resources are loaded? It seems bad to enforce this
cross-origin, as I wouldn't want one origin to be able to DoS all other
notifications via a slow server response.

-=-=-
Section 9:
In the following example, this event is used to guarantee that regardless of
when the notification is shown, it is displayed for only 15 seconds.

To be clear, that code ensures that the notification is displayed for *no
more than* 15 seconds. It's quite possible depending on the queueing done by
the underlying framework that the notification might show for less time (or
not at all).