Re: [webkit-dev] Can we remove Notification.show()?
It should definitely not be necessary to call Notification.show(), although
I have not removed that API since I am busy with some other tasks
currently. What browser/WebKit revision are you using?
In Chrome 26, I just opened the javascript console and typed new
Notification('blah') and it displayed a notification, so it doesn't seem
like show() is necessary in more recent versions of WebKit.
On Thu, Feb 7, 2013 at 1:51 PM, Claudio Saavedra csaave...@igalia.comwrote:
On Mon, 2013-01-28 at 10:35 +0100, Andrew Wilson wrote:
So, we've recently landed some fixes to address permissions handling
for Notification.show(): http://trac.webkit.org/changeset/140927
Turns out, the notifications specification does not have a show() API
(the notification is automatically shown from the constructor
-- http://notifications.spec.whatwg.org/#api). Does anyone have any
objections to moving the show() API under the
ENABLE_LEGACY_NOTIFICATIONS flag to bring us under compliance with the
spec?
What's the status of this? Apparently it is still necessary to call
Notification.show() after a notification is created. Are you tracking
this in a bug report?
Claudio
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Can we remove Notification.show()?
So, we've recently landed some fixes to address permissions handling for Notification.show(): http://trac.webkit.org/changeset/140927 Turns out, the notifications specification does not have a show() API (the notification is automatically shown from the constructor -- http://notifications.spec.whatwg.org/#api). Does anyone have any objections to moving the show() API under the ENABLE_LEGACY_NOTIFICATIONS flag to bring us under compliance with the spec? Also, it looks like if a platform enables ENABLE_LEGACY_NOTIFICATIONs, not only do they get support for the old webkitNotifications API, but also some of the old API (like show() and cancel()) is exposed on the new Notifications objects, because we share the same interface for webkitNotifications and Notifications. Do we care (will this make it harder to eventually turn off ENABLE_LEGACY_NOTIFICATIONS since web apps may start using those APIs on the new Notifications objects)? -atw ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Can we remove Notification.show()?
On Mon, Jan 28, 2013 at 11:53 AM, Jon Lee jon...@apple.com wrote: Also, it looks like if a platform enables ENABLE_LEGACY_NOTIFICATIONs, not only do they get support for the old webkitNotifications API, but also some of the old API (like show() and cancel()) is exposed on the new Notifications objects, because we share the same interface for webkitNotifications and Notifications. Do we care (will this make it harder to eventually turn off ENABLE_LEGACY_NOTIFICATIONS since web apps may start using those APIs on the new Notifications objects)? I expect most people look for tutorials on the web, or read the spec, rather than feel their way through a new API by inspecting the JS object. I also believe there are hardly any cases of people using the old API with the new Notification object. Once the evangelism sites have updated their code samples, it should clarify any confusion. Yeah, that probably makes sense. I guess the only concern would be future unexpected interactions between the new Notifications code and the (unintentionally) exposed APIs (ala the issue addressed by r140927). But looking at the interface I don't really see anything that seems particularly troublesome. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Followup on removing webkitNotifications.createHTMLNotification
Hmmm. Does FeatureObserver detect features invoked from web apps like Gmail? Because I'm fairly certain that Gmail and Google Calendar still use webkitNotifications for their notifications. Not to say that we shouldn't land this patch anyway - just pointing out that this may still be used more often than your stats would indicate. -atw On Wed, Jan 23, 2013 at 1:47 AM, Adam Barth aba...@webkit.org wrote: As discussed in February 2012 [1], we have been deprecating the webkitNotifications.createHTMLNotification API for almost a year. According to FeatureObserver, the API is used in only 0.0008% of web page views, indicating that we have been successful in depreciating it. I've posted a patch to remove it: https://bugs.webkit.org/show_bug.cgi?id=107598 Thanks, Adam [1] http://lists.webkit.org/pipermail/webkit-dev/2012-February/019354.html ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Followup on removing webkitNotifications.createHTMLNotification
Apologies for the confusion - I should have finished my coffee before reading my mail. I didn't realize this only impacts HTML notifications. It's still a good reminder that Google really should migrate to the new notification APIs, though. I'll get the ball rolling on gmail, at least. -atw On Wed, Jan 23, 2013 at 9:58 AM, Adam Barth aba...@webkit.org wrote: On Wed, Jan 23, 2013 at 12:45 AM, Andrew Wilson atwil...@google.com wrote: Hmmm. Does FeatureObserver detect features invoked from web apps like Gmail? Yes. Because I'm fairly certain that Gmail and Google Calendar still use webkitNotifications for their notifications. Not to say that we shouldn't land this patch anyway - just pointing out that this may still be used more often than your stats would indicate. As Morrita-san writes: On Wed, Jan 23, 2013 at 12:50 AM, Hajime Morrita morr...@google.com wrote: It looks the patch is removing a specific API called createHTMLNotification(). Unless these apps are showing HTML-based notification, it should keep working even after this change. If Gmail is still using the vendor-prefixed webkitNotifications version of the API, they should update to the unprefixed new Notification version of the API, which is implemented by a number of different browsers. I know there's some amount of confusion about the current status of the web notification APIs. I'm working with Chrome's developer relation folks to update our various pieces of documentation and tutorials. Adam On Wed, Jan 23, 2013 at 1:47 AM, Adam Barth aba...@webkit.org wrote: As discussed in February 2012 [1], we have been deprecating the webkitNotifications.createHTMLNotification API for almost a year. According to FeatureObserver, the API is used in only 0.0008% of web page views, indicating that we have been successful in depreciating it. I've posted a patch to remove it: https://bugs.webkit.org/show_bug.cgi?id=107598 Thanks, Adam [1] http://lists.webkit.org/pipermail/webkit-dev/2012-February/019354.html ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Changes to window.focus/window.blur controlled by a setting?
On Mon, May 21, 2012 at 2:17 AM, Jochen Eisinger joc...@chromium.orgwrote: Hey, in https://bugs.webkit.org/show_bug.cgi?id=86969 I'm changing window.focus and window.blur to match Firefox's behavior: window.blur does nothing, and window.focus only works when invoked from the window that actually opened the former. The goal is to thwart so-called pop unders. The new behavior you describe will break notifications, since many pages will want to bring themselves to the front when someone clicks on their notification, and your patch prevents this. I suspect that the Firefox behavior will need to change when they add support for notifications. I still think that a superior change would be to prevent applications from calling window.focus() or window.blur() in the context of a user gesture once they've opened a new window. This would address popunders, while still allowing notifications to work. Does any port want to have this new behavior configurable by e.g. a setting? Feel free to directly comment on the bug. best -jochen ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Changes to window.focus/window.blur controlled by a setting?
On Mon, May 21, 2012 at 12:21 PM, Maciej Stachowiak m...@apple.com wrote: On May 21, 2012, at 12:16 PM, Andrew Wilson atwil...@google.com wrote: On Mon, May 21, 2012 at 2:17 AM, Jochen Eisinger joc...@chromium.orgwrote: Hey, in https://bugs.webkit.org/show_bug.cgi?id=86969 I'm changing window.focus and window.blur to match Firefox's behavior: window.blur does nothing, and window.focus only works when invoked from the window that actually opened the former. The goal is to thwart so-called pop unders. The new behavior you describe will break notifications, since many pages will want to bring themselves to the front when someone clicks on their notification, Not necessarily for or against the change, but we could (and probably should) make notifications do this automatically. Is there any case where clicking a notifiicatin should not bring the relevant page to the front? Yes. For example, in gmail, if you click on an email notification, we open a new window and display that email. We don't want to bring the parent to the front in that case. - Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Changes to window.focus/window.blur controlled by a setting?
On Mon, May 21, 2012 at 12:21 PM, Jochen Eisinger joc...@chromium.orgwrote: On Mon, May 21, 2012 at 9:16 PM, Andrew Wilson atwil...@google.comwrote: On Mon, May 21, 2012 at 2:17 AM, Jochen Eisinger joc...@chromium.orgwrote: Hey, in https://bugs.webkit.org/show_bug.cgi?id=86969 I'm changing window.focus and window.blur to match Firefox's behavior: window.blur does nothing, and window.focus only works when invoked from the window that actually opened the former. The goal is to thwart so-called pop unders. The new behavior you describe will break notifications, since many pages will want to bring themselves to the front when someone clicks on their notification, and your patch prevents this. I suspect that the Firefox behavior will need to change when they add support for notifications. I still think that a superior change would be to prevent applications from calling window.focus() or window.blur() in the context of a user gesture once they've opened a new window. This would address popunders, while still allowing notifications to work. The web page could just use setTimeout your restriction to work around this, no? No, because the setTimeout() callback would be executed outside the context of a user gesture. -jochen Does any port want to have this new behavior configurable by e.g. a setting? Feel free to directly comment on the bug. best -jochen ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Web Notifications API
On Wed, Feb 15, 2012 at 6:12 PM, Jian Li jia...@chromium.org wrote: On Wed, Feb 15, 2012 at 9:46 AM, Jon Lee jon...@apple.com wrote: On Feb 13, 2012, at 5:51 PM, Andrew Wilson atwil...@google.com wrote: I don't have an answer for you here, as the internet is vast :) Among google properties, Gmail and Google Calendar currently use it. I'm not aware of any other google property that uses it in their web pages, but some do via extensions. On Feb 13, 2012, at 5:29 PM, Adam Barth aba...@webkit.org wrote: IRCCloud is an example of a site that I use every day that uses notifications. Ok, thanks for providing these sites. It seems to me that we are in agreement with most of the proposal. I would like to begin work on these changes. I will file a master bug so that we can track progress. I think we can make these improvements without disturbing what we already have, to maintain current compatibility. Does this sound good? My concerns are two-fold: 1) Can we run this by the standards body first? I think it makes sense to gain some consensus among the webkitters before going to the standards body, but now that we have this consensus, I'd really like to give that group a chance to comment before we start implementation in case there's something we missed. Is there a compelling reason to move forward with implementing before getting their feedback (or perhaps do that in parallel?) 2) I'm still concerned with the use of WebKitNotification(), when we already have a proposed API in place for Notification(). Even if we leave the current APIs intact (which is good!), we'll end up with 3 separate notification APIs (the current window.webkitNotifications, your proposed WebKitNotification(), and the final Notification()). It feels like the standards proposal is stable enough that we could move directly to implementing Notification(), especially if we can get prompt feedback about your proposed changes. I may have misunderstood your statement - perhaps you are planning to implement this as Notification() and not WebKitNotification(). I just hate to have yet another set of notification APIs that we'll have to deprecate, so I'd like to avoid it if possible. Sounds good, as long as we keep in mind of not to breaking backward compatibility until app developers can switch to new syntax and scheme. Jon ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Propose adding button support to text based notifications (Was: Removing HTML notifications from WebKit)
On Tue, Feb 14, 2012 at 6:13 PM, Benjamin Poulain benja...@webkit.orgwrote: On Tue, Feb 14, 2012 at 5:59 PM, Jian Li jia...@chromium.org wrote: One of the reasons for using html notifications is to allow direct interaction with the notifications. Here're some scenarios from our customers that want to use html notifications purely for this purpose: Does any platform provide this kind action in their native notification? If not, aren't you just repeating the same mistake as HTML notifications? I hate to reopen this particular point of discussion again (because many many words have already been exchanged about this on the WebApps mailing list), but are you maintaining that we should only expose functionality in our notification APIs that can be supported by native notification platforms? Because that path leads to a lowest-common-denominator API that doesn't support things like onclick events (since NotifyOSD doesn't support clicks on notifications). I know that some people feel that compatibility with Growl should be one of our prime concerns when crafting this API, but keep in mind that there is disagreement on that point, the standard body explicitly made this a non-goal, and so I think we ought to consider API suggestions on their merits rather than in light of whether they can be mapped to any specific native notification framework. Anyhow, Jian, if you think this is a valuable addition, you might want to bring it up on the standards list. I know it's come up before, but we've always pointed to HTML notifications to address those use cases, so it might bear reconsidering if nobody is going to support HTML notifications. Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Web Notifications API
On Mon, Feb 13, 2012 at 5:23 PM, Jon Lee jon...@apple.com wrote: Hi! Lots of responses below (mashed previous replies together for topic coherency): John Gregg wrote: Which missing aspects of the Feature permissions spec are you concerned about? I was only referring to the fact that the spec calls for a separate generic interface for permissions with a parameter that identifies the feature [FeaturePermissions.permissionLevel(notifications)], and in this case it would still be attached to the Notifications interface [Notifications.permissionLevel()]. At the risk of derailing the discussion, I have some concerns about the nature of that spec. Although from an engineering standpoint one could argue for a generic interface, I see two issues. 1) It makes a low-barrier entry to tack on features that require permissions. And 2) it could permit UAs to couple features in a nag sheet, making for a bad user experience. I think it makes sense to keep the permissions mechanism confined to the needs of notifications. Andrew Wilson wrote: One note: if we're going to change the API at all, I'd like to see us change it exactly once - to the draft API defined by the standards body. So I'd be opposed to a transitional phase window.webkitNotifications - WebKitNotification() - draft standard. Otherwise, applications using this API have to try to support all 3 APIs to deal with legacy browsers. I also have concerns about backwards compatibility support. Aside from Gmail, what other web sites have integrated the notifications feature? I could only find example pages, one of which was using already an outdated API. I don't have an answer for you here, as the internet is vast :) Among google properties, Gmail and Google Calendar currently use it. I'm not aware of any other google property that uses it in their web pages, but some do via extensions. John Gregg wrote: Overall my opinion on replaceId is that it's quite useful practically, and we already have real world examples of that usefulness. As a real-world example, gmail wants to show two different types of notifications: chat and email. So it uses two replace IDs: _chat_userid and _email_userid. This ensures that only a single chat notification and a single email notification ever appear for a given user. Ok, thanks for explaining the reason behind this, and it makes total sense. I agree about the utility of having some kind of ID to coordinate between multiple pages, but I think replaceId might be the wrong name here? Maybe just id or globalID? I think it also gives platforms an opportunity to determine how they want to handle dupe notifications (as you said, ignore or replace). Andrew Wilson wrote: Nit: Can you clarify what default means? I think it means the user has not granted permission yet, but you can still create notifications and they will be queued until such time that the user chooses to grant permission. Maybe something clearer than default, like not-granted (the reason why default concerns me is a UA may decide to provide notification permission to all origins as the default configuration, but it seems like this would not map to default but rather to granted. I understand your concern about ambiguity, but I think your suggestion implies that a default of the opposite policy exists or could exist. And yes, I think any UA that wishes to grant permission by default should just return granted. From a flow perspective, it makes sense for a UA to deny by default, for any web site to detect that it's denied, and then request the UA for permission. Assuming the UA's default policy is the opposite, I don't think the flow fits. That is, assume a UA allows all notifications by default, and the web site detects a default-allowed policy. Do you believe all websites will then ask the user to deny itself the privilege? I think in this scenario, the UA should prompt the user for denial directly, and not assume that the web site will be a good citizen and handle the default-granted case. Therefore, I think UA's that want to give permission by default should just return granted. Instead of using passive granted, denied, and default, how about yes, no, and ask? It's more colloquial, but easier to read, and more actionable. OK, I think we're on the same page here. I don't have a strong opinion one way or the other regarding the naming of these permission values. WebKitNotification.requestPermission(callback) An asynchronous call, as it is currently. The callback specified includes one argument which represents the permission, similar to the return values in permissionLevel(). (Currently it is just a void callback.) If the user had already made a policy decision, then the callback is invoked immediately (with either granted or denied). Otherwise the UA may ask the user for permission, and the callback is invoked when the user makes a decision (cancelling the request does
Re: [webkit-dev] Web Notifications API
On Wed, Feb 8, 2012 at 4:58 PM, Jon Lee jon...@apple.com wrote: Hi WebKit! I am interested in refactoring the API for web notifications, and would like your feedback. We are working on getting permission to join the Web Notifications working group, but thought that while doing that I could try to get some general consensus from the WebKit community about these changes prior to proposing them to the WG. The basic intents of the refactoring are to a) align the API with the design of recent APIs in the WebApps WG and elsewhere, and b) to simplify the API by removing unnecessary bits. With these changes I think we can put the API in a good place for future enhancements. Here are the proposed changes: 1. Move the factory method to a constructor function. new WebKitNotification(title, body, [optional] iconURL) This is similar to the spec [NOTIF], except that the icon URL has been moved to the end as an optional argument. Notification platforms may choose not to load the URL for privacy reasons, and I think it should not be a required component for a text notification. One note: if we're going to change the API at all, I'd like to see us change it exactly once - to the draft API defined by the standards body. So I'd be opposed to a transitional phase window.webkitNotifications - WebKitNotification() - draft standard. Otherwise, applications using this API have to try to support all 3 APIs to deal with legacy browsers. 2. Remove HTML notifications. It has been removed from the spec, and we don't intend on ever supporting HTML notifications. I brought this issue up before; is there an update on this front from any other platforms? 3. Use static functions on the notification constructor for permissions checks. By moving them there, it allows us to remove window.webkitNotifications and the NotificationCenter class, cleaning up the API. 4. Adjust the permission functions. WebKitNotification.permissionLevel() -- String Similar to checkPermissions(), synchronous call. The name aligns with similar functionality in the DAP Feature Permissions spec [FEAT], but scoped specifically to Web Notifications. Returns one of three strings: granted, denied, and default. This follows the current best practice from the WebApps WG where strings are being used instead of enums. Nit: Can you clarify what default means? I think it means the user has not granted permission yet, but you can still create notifications and they will be queued until such time that the user chooses to grant permission. Maybe something clearer than default, like not-granted (the reason why default concerns me is a UA may decide to provide notification permission to all origins as the default configuration, but it seems like this would not map to default but rather to granted. WebKitNotification.requestPermission(callback) An asynchronous call, as it is currently. The callback specified includes one argument which represents the permission, similar to the return values in permissionLevel(). (Currently it is just a void callback.) If the user had already made a policy decision, then the callback is invoked immediately (with either granted or denied). Otherwise the UA may ask the user for permission, and the callback is invoked when the user makes a decision (cancelling the request does not invoke the callback). Any notifications posted in the meantime would be queued until then. Multiple calls to this function should just result in one visible request. Just a note, since I'm not sure what immediately means - the callback should always be invoked asynchronously even if permissions have already been granted/denied. I'm slightly uneasy about queueing notifications - I like the current spec's behavior where notification.show() results in an error event if permission is not granted. Otherwise, if the user changes their permission configuration for an origin (from granted to not-granted) the app would not be notified that its notifications are not being displayed - they would just be silently queued (apps would then have to check permissions themselves before posting every notification if they wanted to detect this case - they couldn't just rely on the error callback). 5. Remove replaceId. This could already be done by canceling a previous notification and posting a new one. The idea of replacing a notification with another one without alerting the user is a feature that we don't intend on supporting. This is an important feature when you have multiple web pages open to the same domain, so I would be strongly opposed to removing this. For example, let's say you have facebook open in two windows, and facebook would like to provide a notification to you of some event - by using replaceId, facebook can ensure that you receive only one notification for the event. Otherwise, you'd get a notification from every single window. I added notifications support to Gmail, so I'm happy to discuss
Re: [webkit-dev] Web Notifications API
On Thu, Feb 9, 2012 at 9:53 AM, Jon Lee jon...@apple.com wrote: On Feb 8, 2012, at 5:41 PM, John Gregg wrote: 3. Use static functions on the notification constructor for permissions checks. By moving them there, it allows us to remove window.webkitNotifications and the NotificationCenter class, cleaning up the API. I think that would be consistent with moving from a factory model to a constructor model. The Feature-permissions effort was intended to create a common interface for handling permissions, but it may still be too far off and sticking with a scoped approach is more practical. The only concern is that it is an implementation change that only partially reaches what has been spec'd, which might leave some continuing confusion among users of Notifications as to the authoritative version of the interface. Which missing aspects of the Feature permissions spec are you concerned about? 4. Adjust the permission functions. WebKitNotification.permissionLevel() -- String Similar to checkPermissions(), synchronous call. The name aligns with similar functionality in the DAP Feature Permissions spec [FEAT], but scoped specifically to Web Notifications. Returns one of three strings: granted, denied, and default. This follows the current best practice from the WebApps WG where strings are being used instead of enums. WebKitNotification.requestPermission(callback) An asynchronous call, as it is currently. The callback specified includes one argument which represents the permission, similar to the return values in permissionLevel(). (Currently it is just a void callback.) If the user had already made a policy decision, then the callback is invoked immediately (with either granted or denied). Otherwise the UA may ask the user for permission, and the callback is invoked when the user makes a decision (cancelling the request does not invoke the callback). Any notifications posted in the meantime would be queued until then. Multiple calls to this function should just result in one visible request. This matches the FeaturePermissions spec with the exception of the decision as a parameter, which is reasonable though redundant since the current permission level is already easily read. The queueing of notifications discussed later. It could work either way. But for me, it seems weird from a programming flow perspective to have to explicitly fetch the level again within the callback; I would expect the response to be included in some form as an argument. 5. Remove replaceId. This could already be done by canceling a previous notification and posting a new one. The idea of replacing a notification with another one without alerting the user is a feature that we don't intend on supporting. Just so the use case is clear here, it is not equivalent to canceling and showing from the webapp's perspective, though it is to the browser. The reason for replaceId is when the same application (e.g., Gmail) is open in multiple browser windows. When a new message arrives, both tabs will discover this and lacking communication between them, attempt to show a notification. But if both notifications are tagged as corresponding to the same real-world event, they are seamlessly merged and the user only sees one. But in this case, wouldn't the second notification just be ignored, instead of replacing the first notification? Not sure what you mean - the second notification replaces the first one. Also, does Chrome keep track of IDs that have been shown, even after the notification has been closed? For example, if one page gets the new email before the other, it posts a notification, the user clicks on that notification, and the page closes that notification _before_ the other page has had a chance to query Gmail's servers for new emails, does Chrome still remember that a notification of that ID was posted before? No, so in theory it's possible that you could end up seeing that notification come in again if one page is significantly delayed behind the other. In practice, this doesn't seem to be a problem. As a real-world example, gmail wants to show two different types of notifications: chat and email. So it uses two replace IDs: _chat_userid and _email_userid. This ensures that only a single chat notification and a single email notification ever appear for a given user. Or does this only apply for notifications that are shown but not closed? 6. Improve show() behavior. Calling show() when the site has been denied permission should call onerror(). If no decision was made, then the notification should remain queued, and only until after the user has decided should onshow() or onerror() be called. I also think show() can only be used once. Subsequent invocations should call onerror(). The permission-denied behavior you want is as spec'd (error event). The permission-unknown behavior you propose seems more difficult for authors, since at
