Re: [webkit-dev] Can we remove Notification.show()?
On Mon, Jan 28, 2013 at 2:24 PM, Jochen Eisinger joc...@chromium.orgwrote: On Mon, Jan 28, 2013 at 11:19 PM, Elliott Sprehn espr...@chromium.orgwrote: This seems like a badly designed API, constructors shouldn't have side effects and not having show() means after calling close() the notification object is useless which is silly. There was a discussion a while ago which resulted in removing the show method and making show implicit in construction. http://lists.w3.org/Archives/Public/public-web-notification/2011Jun/0005.html. The reasoning was that there typically isn't much value in reusing a notification. In the new API, there's also no close() method... There is still a close() method in the latest spec: http://notifications.spec.whatwg.org/#api -jochen On Mon, Jan 28, 2013 at 4:35 AM, Andrew Wilson atwil...@google.comwrote: 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 ___ 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 mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
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? 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()]. 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? Ignored or replaced, you still need a way of tagging them. I still think replacement is better, since it also gives you the benefit of the most recent information when it's something other than exact copies. That brings up another use case when you do get frequent updates, say for chat notifications (one per incoming line of text, typically) - use a single replaceId for the chat session and just update it with the latest message. This can be done with cancel/show, but multiple chats or other notifications, the notifications would be constantly re-ordering and the end-user experience is not good. 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? Or does this only apply for notifications that are shown but not closed? The replacement logic in Chrome only applies for notifications that are still active (shown or in the display queue). You are correct
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. Glad there is continued interest in Notifications! I definitely hope you join the WG and work these concerns out there as well. 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. Seems reasonable that icon should be optional. 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? It has indeed been removed from the spec that's moving forward. I'd probably argue it could continue as an experimental feature, but will leave this alone for now lest it distract from the other items. 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. 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. 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. 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
Re: [webkit-dev] No getters for iconURL/title/body in Notification.idl
On Fri, Jul 1, 2011 at 10:31 AM, Xan Lopez x...@gnome.org wrote: Hi, we are adding all the Notification related objects to the GTK+ DOM bindings, and also adding the necessary APIs to WebKitGTK+ to interact with the UA. One thing we have noticed is that although the constructors for the Notification objects have the three data parameters mentioned in the subject, the spec we follow ( http://dev.chromium.org/developers/design-documents/desktop-notifications/api-specification , as I understand it) does not provide attributes for those in the Notification interface. Since those are needed by the UA to actually show the notification in a meaningful way, we wonder if that's an oversight or a design decision. It seems the way Chromium solves this is by doing a custom class with those getters, but since we already have pretty complete DOM bindings we'd like our low-level signals and APIs to use those instead of reimplementing them (or, at best, subclassing to add the needed functionality). Any comments? Xan The data parameters are certainly needed by the UA to show the notification, but it seems like you're suggesting they need to be exposed as part of the Notification API (i.e., to web pages). I don't see why that would be necessary. WebCore has a Notification object in C++ which does provide access to the fields, and which is passed up through the NotificationPresenter interface implemented in the ChromeClient. That's how Chromium does it -- would it not work for GTK? -John ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Directory upload experimental feature
FYI, I've posted a patch for my proposed version of the directory upload feature at https://bugs.webkit.org/show_bug.cgi?id=40872. Most of it is behind a ENABLE_DIRECTORY_UPLOAD flag, except for some glue code I needed to integrate with the recent Blob changes. One question was on the directory attribute. I didn't notice any precedent for attributes named with the webkit-foo style, but since this is an experimental thing I would think webkit-directory might make sense. Thanks, -John On Thu, Jun 3, 2010 at 7:19 AM, David Kilzer ddkil...@webkit.org wrote: Also, I was simply pointing out existing behavior, not arguing for/against the zip file format. Dave -- *From:* Sam Weinig sam.wei...@gmail.com *To:* David Kilzer ddkil...@webkit.org *Cc:* John Gregg john...@google.com; webkit-dev@lists.webkit.org; Adele Peterson ad...@apple.com *Sent:* Wed, June 2, 2010 11:28:11 AM *Subject:* Re: [webkit-dev] Directory upload experimental feature I think this is only true for Mac OS X style bundles, not all folders. On Wed, Jun 2, 2010 at 3:44 AM, David Kilzer ddkil...@webkit.org wrote: Other alternatives? I believe Safari will zip a folder and send it as a single file for you if you attach a folder to a file upload element instead of an individual file. Dave -- *From:* John Gregg john...@google.com *To:* Sam Weinig sam.wei...@gmail.com *Cc:* webkit-dev@lists.webkit.org *Sent:* Tue, June 1, 2010 3:09:00 PM *Subject:* Re: [webkit-dev] Directory upload experimental feature My proposal for that is that all the files would be listed in the form submission the same way as if it were a input type=file multiple, but in the Content-Disposition header, the filename component would contain the path information. One alternative idea would be add a path component to the Content-Disposition header alongside the filename which remains unchanged, but I think that would be a much more difficult approach. Other alternatives? Example follows. -John If you are have these files /home/John/photos/vacation/1.jpeg /home/John/photos/vacation/2.jpeg /home/John/photos/conference/1.jpeg and choose photos from the directory picker, you'd end up with input.files[0].name = 1.jpeg input.files[0].path = photos/vacation/1.jpeg input.files[1].name = 2.jpeg input.files[1].path = photos/vacation/2.jpeg input.files[2].name = 1.jpeg input.files[2].path = photos/conference/1.jpeg Your POST would look like Content-type: multipart/form-data; boundary=WebKitFormBoundaryFoo WebKitFormBoundaryFoo Content-Disposition: form-data; name=input; filename=photos/vacation/1.jpeg Content-Type: image/jpeg contents WebKitFormBoundaryFoo Content-Disposition: form-data; name=input; filename=photos/vacation/2.jpeg Content-Type: image/jpeg contents WebKitFormBoundaryFoo Content-Disposition: form-data; name=input; filename=photos/conference/1.jpeg Content-Type: image/jpeg contents On Sat, May 29, 2010 at 10:22 AM, Sam Weinig sam.wei...@gmail.comwrote: How will the directory structure and all the files therein be represented in the form submission? -Sam On Fri, May 28, 2010 at 3:17 PM, John Gregg john...@google.com wrote: Hi WebKit, I recently proposed adding directory upload support to HTML via a new input attribute to whatwg@, and the discussion arrived at try it out. Having written some code I think I have something that works pretty well, and I'd like to land it on an experimental basis in WebKit, but want to reach out early before trying to put any code in the tree. The plan that comes to mind is a new ENABLE_DIRECTORY_UPLOAD flag, but I'm completely open to other options. Background (cf. the whatwg thread http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-April/025764.html ): - The use case for this is a photo album or file manager web application, which wants the user to easily choose an entire directory to recursively upload, while preserving the sub-directory structure. - The reason for the new attribute is to signal the UA to show a native folder-picker rather than a file-picker, which on most OSs are two distinct dialogs. The approach I'm using has 2 parts and is a small amount of WebCore code (about 200 lines). - Extend HTMLInputElement to support the directory attribute, which is passed up via FileChooser allowing the UA to display a folder-picker. UA enumerates all the files and returns them in the normal way. - Extend File to have a File.path property, which contains the path information starting from the chosen directory as the root. HTMLInputElement is responsible for generating these values from the list of files when the directory attribute is set. Thoughts? Thanks, -John ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Directory upload experimental feature
My proposal for that is that all the files would be listed in the form submission the same way as if it were a input type=file multiple, but in the Content-Disposition header, the filename component would contain the path information. One alternative idea would be add a path component to the Content-Disposition header alongside the filename which remains unchanged, but I think that would be a much more difficult approach. Other alternatives? Example follows. -John If you are have these files /home/John/photos/vacation/1.jpeg /home/John/photos/vacation/2.jpeg /home/John/photos/conference/1.jpeg and choose photos from the directory picker, you'd end up with input.files[0].name = 1.jpeg input.files[0].path = photos/vacation/1.jpeg input.files[1].name = 2.jpeg input.files[1].path = photos/vacation/2.jpeg input.files[2].name = 1.jpeg input.files[2].path = photos/conference/1.jpeg Your POST would look like Content-type: multipart/form-data; boundary=WebKitFormBoundaryFoo WebKitFormBoundaryFoo Content-Disposition: form-data; name=input; filename=photos/vacation/1.jpeg Content-Type: image/jpeg contents WebKitFormBoundaryFoo Content-Disposition: form-data; name=input; filename=photos/vacation/2.jpeg Content-Type: image/jpeg contents WebKitFormBoundaryFoo Content-Disposition: form-data; name=input; filename=photos/conference/1.jpeg Content-Type: image/jpeg contents On Sat, May 29, 2010 at 10:22 AM, Sam Weinig sam.wei...@gmail.com wrote: How will the directory structure and all the files therein be represented in the form submission? -Sam On Fri, May 28, 2010 at 3:17 PM, John Gregg john...@google.com wrote: Hi WebKit, I recently proposed adding directory upload support to HTML via a new input attribute to whatwg@, and the discussion arrived at try it out. Having written some code I think I have something that works pretty well, and I'd like to land it on an experimental basis in WebKit, but want to reach out early before trying to put any code in the tree. The plan that comes to mind is a new ENABLE_DIRECTORY_UPLOAD flag, but I'm completely open to other options. Background (cf. the whatwg thread http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-April/025764.html ): - The use case for this is a photo album or file manager web application, which wants the user to easily choose an entire directory to recursively upload, while preserving the sub-directory structure. - The reason for the new attribute is to signal the UA to show a native folder-picker rather than a file-picker, which on most OSs are two distinct dialogs. The approach I'm using has 2 parts and is a small amount of WebCore code (about 200 lines). - Extend HTMLInputElement to support the directory attribute, which is passed up via FileChooser allowing the UA to display a folder-picker. UA enumerates all the files and returns them in the normal way. - Extend File to have a File.path property, which contains the path information starting from the chosen directory as the root. HTMLInputElement is responsible for generating these values from the list of files when the directory attribute is set. Thoughts? Thanks, -John ___ 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] Runtime setting for incomplete features
I also have a patch (https://bugs.webkit.org/show_bug.cgi?id=28930) that's awaiting a resolution of this for desktop notifications. Does anyone object to putting experimental in the name of the setting as a good solution? -John On Wed, Sep 9, 2009 at 9:50 AM, Eric Seidel e...@webkit.org wrote: experimental would be one option. We used to have build-webkit --svg-experimental iirc. -eric On Wed, Sep 9, 2009 at 9:47 AM, Darin Fisher da...@chromium.org wrote: Perhaps... any suggestions?-Darin On Wed, Sep 9, 2009 at 8:45 AM, Adam Barth aba...@webkit.org wrote: Maybe it's worth distinguishing these settings with some sort of naming convention so that embedders know they'll be removed at some point? Adam On Tue, Sep 8, 2009 at 11:47 PM, Darin Fisherda...@chromium.org wrote: As is described in https://bugs.webkit.org/show_bug.cgi?id=28941, for the Chromium project, we like to make incomplete features available behind a command line flag to help facilitate testing. I understand that the norm for WebKit is to only have compile time options for new / incomplete features. In some cases, runtime settings are defined, but these generally correspond to end user preferences or the needs of specific embedders. At any rate, I just wanted to make sure that folks were aware that some settings may only exist to help facilitate Chromium's goal of shipping incomplete features, disabled by default. Alexey asked if there are any guidelines for when these settings may be removed. I think the main thing is that the feature has to be reasonably complete and enabled by default by embedders (e.g., Chromium) that are compiling the feature. Regards, -Darin ___ 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 ___ 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] Notifications API
I think that makes sense for now as well. I expect we'll get to this sort of generic permissions system in the future, but for the time being I am adding to my current patch some methods: // internal methods implemented by the embedder int NotificationProvider::checkPermission(SecurityOrigin*); void NotificationProvider::requestPermission(SecurityOrigin*, PermissionCallback); // JS API methods int Notifications.checkPermission() -- invokes m_provider-checkPermission(my_origin); void Notifications.requestPermission(PermissionCallback) -- likewise. callback is invoked when the user (or user agent) makes a decision. Additionally, Notifications.createNotification() will throw a SECURITY_ERR exception if permission is not granted. Sound good? I think most of the code will easily migrate to a generic system. -John On Wed, May 27, 2009 at 11:44 AM, Sam Weinig sam.wei...@gmail.com wrote: I would prefer we limit the scope to notifications, since this is an experimental feature at the moment. Perhaps something along the lines of window.notifications.requestTrust(), or window.notifications.requestUse() (I am not a huge fan of either of those function names, but you get the general idea). We can always revisit this if this type of explicit privilege escalation becomes something other apis need as well. -Sam On Wed, May 27, 2009 at 9:22 AM, Drew Wilson atwil...@google.com wrote: Sam, I think you are right here. I'm convinced that applications should be specific about what permissions they are asking for. I also believe that from a UX standpoint, we will probably want to provide the user with a single dialog that enumerates the permissions being granted, although a given user-agent may want to do this differently. We certainly want to enable both models. So I'd like to propose an API like the following (cribbed from the Android permissions manifest): int getTrusted(permissionName) - returns 0 if the application is blocked/unsupported (user said no or user-agent does not support it), 1 if it is untrusted (no permissions grant yet), 2 if it is trusted void requestTrust(permissionArray, callback) This provides a couple of important things: 1) granularity, so an application can specify exactly what permissions it wants 2) flexibility for the user agent - the application asks for a block of permissions at once (for example, a given feature like background notifications may require two permissions: persistent workers and notifications). The user agent has the flexibility to decide whether to display this as one dialog enumerating permissions, two separate dialogs, a dialog which allows the user to pick and choose which permissions it wants to grant, etc. What do you think? -atw On Tue, May 26, 2009 at 9:49 PM, Sam Weinig sam.wei...@gmail.com wrote: On Tue, May 26, 2009 at 9:18 PM, David Levin le...@chromium.org wrote: On Tue, May 26, 2009 at 8:57 PM, Sam Weinig sam.wei...@gmail.comwrote: On Tue, May 26, 2009 at 5:04 PM, Drew Wilson atwil...@google.comwrote: On Tue, May 26, 2009 at 4:43 PM, Sam Weinig sam.wei...@gmail.comwrote: On Tue, May 26, 2009 at 4:20 PM, Drew Wilson atwil...@google.comwrote: To give the list some insight into the discussions we've had with the Chrome UX folks: 1) We want to associate some set of enhanced permissions with a given origin (e.g. https://mail.yahoo.com), and we want the user to be presented with a single do you want to grant permissions to https://mail.yahoo.com; dialog, rather peppering the user with a bunch of individual permission dialogs for each feature (Yes, please allow mail.yahoo.com to use 100MB of local storage, Yes, allow mail.yahoo.com to display notifications, Yes, allow mail.yahoo.com to run in the background). It seems like a bad idea to give all or nothing trust, and not along the lines of how APIs have managed choices in the past (quotas are increased when the limit is hit). I am not even sure how a UA would present such a choice to a user in a meaningful manner. I think a workflow such as the one quoted above by Maciej is a good direction, that gives a user a better chance of understanding the choice they are making. I thought that maciej suggested the same thing we suggested - an explicit javascript API to request permissions. In our case, we want to ask for permissions in bulk up front, rather than peppering the user with permissions on an ad-hoc basis - in your example (prompting for more quota when the quota is hit) will break things like background sync in persistent workers, as the user may not be around when that background sync occurs. It is similar, but I am concerned with how to present a dialog to a user that states that by clicking grant they are completely trusting you. 2) We want the timing of the permission grant UI to be under application control (as part of some kind of application user
[webkit-dev] testing question for code that calls abstract methods (like ChromeClient)
What's a good strategy for testing WebKit code that calls out to the ChromeClient interface or some other abstract interface? I can't find anything obvious in the codebase-- is there any way to mock out those calls for unit tests? Thanks, -John ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Notifications API
On Tue, May 26, 2009 at 2:20 PM, Maciej Stachowiak m...@apple.com wrote: On May 22, 2009, at 10:19 AM, John Gregg wrote: Sure. We have the following plan for how to handle opt-in: - Use of the feature by script, if permission isn't granted to the origin, should throw an exception, not present permissions UI. So your insistent porn site would have no effect on the user. - A dialog box asking for permission should only appear in response to a user gesture like a click. So in the normal case, an application will present a user with a link New: Desktop Calendar Notifications available! Click here to setup. And that link will present a prompt from the user-agent Do you trust calendar.com? The site wants to display notifications on your desktop. [Yes/No] If the user says yes, script running under that origin will have permission to show desktop notifications. To expose this flow, wouldn't you need a method in the API exposed to JavaScript that requests permission for notifications, rather than actually posting a notification? I don't see such a method in the submitted patch. It would not make sense for a link labeled New: Desktop Calendar Notifications available! Click here to setup to actually display a notification itself, I wouldn't think. Having a JavaScript API to request permissions, along with plumbing through the WebKit layer to allow a WebKit embedder to suitably prompt the user, would address most of my concerns. Yes, this would be necessary. It's actually part of the spec API I originally proposed at http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-March/019113.html(readonly bool trusted attribute and void requestTrust() method), and I was planning to submit in a follow-up patch. But if you prefer it come in at the same time as the rest of the code, it can be done all at once. Do you have any particular proposal for how to accomplish the plumbing? Part of the thinking is that it would be nice to avoid overwhelming users with lots of different permission UIs for individual native-app-like features that will come up (persistent workers (if and when) local database quota come to mind). Thanks, -John ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Notifications API
I circulated a proposal several weeks ago which specified a notifications API for workers (desktop toasts), and the feedback was that (a) persistent workers are still far away, (b) is a notifications api necessary given it's basically a new window?, and (c) have we thought through the security issues? (https://bugs.webkit.org/show_bug.cgi?id=25463) I've tried to answer these questions but some points have remained sticky, so I'm reaching out again in search of consensus. As far as workers go, I've modified the proposal (and patch) to attach the notifications object to DOMWindow as well as WorkerContext, so that both regular pages can access it as well and this is not worker-specific. On the security question, a substantial amount of thought has gone into how to prevent unwanted popups (and in general how to control access to HTML5 application features). We think user opt-in on an origin-basis is the best policy and it's what we plan to do in Chromium; the WebKit interfaces are structured so that the policy is up to the user agent via a NotificationProvider interface. The API use case question seems to be the big one remaining open. On the use case front, there are several Google products interested in using it (Calendar reminders, Gmail alerts, etc.) We also see Mozilla Jetpack demoing an API very similar to the one I've proposed in their recent release. So I think there is plenty of reason to believe this feature would be used to greatly enhance applications. Last, if the feature is included should the interface be * window.notifications.create*() -- my proposal (also Jetpack's API) -- or * window.open*(style=notification), the alternate suggestion? Here are my thoughts supporting the former: - Notifications will evolve: the first generation is text+icon only, the second generation is small HTML bubbles, maybe something else later. While small HTML bubbles might align well with window.open, text+icon toasts don't. For some platforms we can get both, for some only the simple form. Logically what an app developer will do is check what notification options are available on the platform, then use the most full-featured option available. This check should be easy to do, and the result shouldn't send them to different existing APIs to find the closest match, if we can help it. I think providing a notifications object to encapsulate the feature makes more sense. - Opening a new window for an HTML notification is only one possible implementation. In the future (or now) a user agent may want to toast up the HTML block on the taskbar, or in a corner of an existing tab, or append it to a stream in a dedicated notification panel. Semantically the service provided to the app developer is alert the user using the HTML at this URL, and defining the interface to match gives us the most flexibility to implement in the future without being tied to a particular existing notion. Other thoughts? Thanks, -John ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Notifications API
Sure. We have the following plan for how to handle opt-in: - Use of the feature by script, if permission isn't granted to the origin, should throw an exception, not present permissions UI. So your insistent porn site would have no effect on the user. - A dialog box asking for permission should only appear in response to a user gesture like a click. So in the normal case, an application will present a user with a link New: Desktop Calendar Notifications available! Click here to setup. And that link will present a prompt from the user-agent Do you trust calendar.com? The site wants to display notifications on your desktop. [Yes/No] If the user says yes, script running under that origin will have permission to show desktop notifications. - Permission should be removable through a menu which is accessible from the notification UI itself. As proposed the permissions policy is somewhat external to WebKit, which contains the Javascript API layer but not the actual user-visible parts of the system including UI, permissions flow, and filtering by origin which will be in Chromium or another user agent. -John On Thu, May 21, 2009 at 11:39 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 21 May 2009, John Gregg wrote: On the security question, a substantial amount of thought has gone into how to prevent unwanted popups (and in general how to control access to HTML5 application features). We think user opt-in on an origin-basis is the best policy and it's what we plan to do in Chromium; the WebKit interfaces are structured so that the policy is up to the user agent via a NotificationProvider interface. Could you elaborate on what you mean by user opt-in? A prompt or installation step seems like a poor user experience given that any site could start asking for this, and we don't want users to click yes to make the message go away (consider a porn site that just does while notifications are not allowed, try to notify). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Notifications API for workers
Thanks Maciej for the feedback. We are definitely concerned with making this feature resistant to abuse, since everyone agrees we don't want to create another class of annoying or insecure pop-ups. A good amount of thought has preceded the code, although I probably didn't coordinate the distribution of the design very well. In the design doc I did send to whatwg ( http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-March/019113.html), there are several options presented for how to prevent unwanted popups via notifications, such as: it can be mitigated by separating applications into trust zones defined by the user-agent, where trust is granted by the user. Desktop placement is limited to trusted origins... So what I meant by similar to popups was just that background notifications should only be allowed if the user has given permission in advance, which has been my experience with popups (though maybe I got that idea from non-WebKit browsers). The design also reflects some thoughts into preventing phishing: It is recommended that HTML notification bubbles always contain a recognizable browser frame, which displays the origin source of the bubble and identifies HTTPS and other security elements in a standard way. Regarding the issue of making the notifications stop, I think HTML notifications should always have an options control in the frame which makes this easy. In terms of the implementation so far, the code provides a pass-through from the worker script to a NotificationProvider interface in the WebKit client, which can should go through a security policy before showing anything to the user. I think that leaves things flexible for stopping abuse paths, both the ones we already have thought of and anything that might occur later. If you have ideas to move specific enforcement rules into WebKit itself, we should discuss that too. -John On Sat, May 2, 2009 at 4:07 PM, Maciej Stachowiak m...@apple.com wrote: I'm pretty concerned about the security/spamming implications of notifications from Workers. A lot of thought has been put into how to make them a good feature for thoughtful, competent Web developers like those at Google. But it seems to me that not as much thought has been put into making the feature resistant to abuse. A few specific concerns: 1) Notifications may appear to the user to come from the Web page they are currently looking at, even if the Worker issuing them was created by a different originating page. 2) In the case of a SharedWorker, there may not even be an originating page with which to assiciate the notification, and it may not be clear to the user how to make notifications stop. 3) It appears that Notifications can be used for unwelcome advertising spam, much as pop-up windows before the advent of browser pop-up blocking. On Apr 30, 2009, at 2:05 PM, John Gregg wrote: Hi WebKit, I'm working on a Notifications API for Web Workers, with the idea that a user agent could receive these from script and route them in a platform-appropriate user-configurable way (desktop HTML toasts, Growl calls, status bar on mobile browsers, etc.). Permission controls would be similar to popups. I don't see how that's possible. The default policy used by many WebKit clients (including Safari) is that popups are only allowed in response to explicit user actions, such as clicking a link. But no code running in a Worker is in response to a user action. In addition, as I understand it, the whole point of Notifications is that they are in response to background events, *not* in response to user actions. I have a prototype working in Chromium but I need some advice as to how I might get the JS API checked in. I opened a bugzilla item here: https://bugs.webkit.org/show_bug.cgi?id=25463, which links to the design doc I'm using and has a rough draft of the patch I'm proposing. I got some feedback there already, so I thought I would reach out for more advice. Basically it amounts to adding to WorkerContext.idl an attribute WorkerContext.notifications, which notifications object contains methods like createNotification(URL or text+icon). Because of the proposed idea of dynamic routing, I'm inclined not to roll it in to window.open() until we get more experience building apps on it and decide that makes sense. Since this is experimental, it's already behind a compile time flag, but I would be happy to do more to make it further protected (like calling it WorkerContext.chromiumNotifications to indicate it's currently a Chromium experiment). Any other advice on how to proceed? I think we should have a clear design for how this feature will resist abuse by malware before landing it in the WebKit tree. And if we can't find a solid design for that, then we shouldn't implement it. While many of us working on WebKit are greatly interested in extending the capabilities of Web applications, we have to recognize that it's important
[webkit-dev] Notifications API for workers
Hi WebKit, I'm working on a Notifications API for Web Workers, with the idea that a user agent could receive these from script and route them in a platform-appropriate user-configurable way (desktop HTML toasts, Growl calls, status bar on mobile browsers, etc.). Permission controls would be similar to popups. I have a prototype working in Chromium but I need some advice as to how I might get the JS API checked in. I opened a bugzilla item here: https://bugs.webkit.org/show_bug.cgi?id=25463, which links to the design doc I'm using and has a rough draft of the patch I'm proposing. I got some feedback there already, so I thought I would reach out for more advice. Basically it amounts to adding to WorkerContext.idl an attribute WorkerContext.notifications, which notifications object contains methods like createNotification(URL or text+icon). Because of the proposed idea of dynamic routing, I'm inclined not to roll it in to window.open() until we get more experience building apps on it and decide that makes sense. Since this is experimental, it's already behind a compile time flag, but I would be happy to do more to make it further protected (like calling it WorkerContext.chromiumNotifications to indicate it's currently a Chromium experiment). Any other advice on how to proceed? Thanks! -John ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
