Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases
This discussion reminds me of a similar issue with MessagePorts. The original MessagePort spec exposed GC behavior through the use of onclose events/closed attributes on MessagePorts. It turns out that on Chromium, there are situations where it's very difficult for us to GC MessagePorts (a port's reachability depends on the reachability of the entangled port on an entirely separate process), and so we just don't. My concern is that there may be situations like this with IDB - if at some point it's possible for events to be fired on an IDB instance (if we support triggers), you'll have a situation where the reachability of an IDB instance may depend on the reachability of that same DB in other processes. The net effect is that on multi-process/multi-heap platforms, we may not be able to GC databases, while on other platforms (which have a unified heap) we will be able to GC them. This will end up being a source of cross-browser incompatibility, because code will work just fine on platforms that are able to deterministically GC databases, but then will break on other platforms that cannot. (As an aside, Jeremy mentions that there may already be situations where we cannot GC databases today - I don't know the spec well enough to comment, though, so perhaps he can elaborate). In any case, I don't think that IDB should be the first place in the entire web platform where we expose GC behavior to clients. -atw On Tue, Feb 8, 2011 at 4:43 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Feb 8, 2011 at 3:31 PM, Glenn Maynard gl...@zewt.org wrote: On Tue, Feb 8, 2011 at 4:01 PM, Jeremy Orlow jor...@chromium.org wrote: I talked it over with Darin (Fisher), and he largely agreed with you guys. I'll file a bug saying that after unload, all IDBDatabases attached to that document should be closed. What happens if a database is open in a page in the back-forward cache? That's incompatible with onunload having side-effects. I know the BF-cache is off-spec, but it's extremely useful and will hopefully find its way into the standard some day, so it'd be nice to keep it in mind. I suppose the browser would discard whole pages from the BF-cache on demand if required by a setVersion call. That's exactly what we do in Firefox. Implementations have to be able to throw things out of the BF cache on command anyway (since you generally want to limit the number of pages living in BF cache, and so loading a new page often causes other pages to be thrown out), so it's just a matter of calling into the same code here. / Jonas
Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases
On Wed, Feb 9, 2011 at 11:20 AM, Jeremy Orlow jor...@chromium.org wrote: On Wed, Feb 9, 2011 at 11:05 AM, Drew Wilson atwil...@google.com wrote: This discussion reminds me of a similar issue with MessagePorts. The original MessagePort spec exposed GC behavior through the use of onclose events/closed attributes on MessagePorts. It turns out that on Chromium, there are situations where it's very difficult for us to GC MessagePorts (a port's reachability depends on the reachability of the entangled port on an entirely separate process), and so we just don't. My concern is that there may be situations like this with IDB - if at some point it's possible for events to be fired on an IDB instance (if we support triggers), you'll have a situation where the reachability of an IDB instance may depend on the reachability of that same DB in other processes. The net effect is that on multi-process/multi-heap platforms, we may not be able to GC databases, while on other platforms (which have a unified heap) we will be able to GC them. This will end up being a source of cross-browser incompatibility, because code will work just fine on platforms that are able to deterministically GC databases, but then will break on other platforms that cannot. (As an aside, Jeremy mentions that there may already be situations where we cannot GC databases today - I don't know the spec well enough to comment, though, so perhaps he can elaborate). Yeah. Talking to Drew made me realize that we (WebKit) already have a cycle so that we probably can't collect IDBDatabase objects with event listeners attached to it. When there's a listener, we have to hold a reference to the JavaScript wrapper since it's what holds onto the JavaScript function we call. But the wrapper holds a reference to our WebCore object. We can break the cycle only when we know that we're not going to call any more events on it. We know that when .close() is called. Working around this as is will be tricky, but isn't really a spec problem. But it does mean that the developer will need to always call .close() or ask the user to close the tab in order to ever be able to run a setVersion transaction. At least for the time being in any WebKit browser. This mainly becomes an issue if some browsers are able to GC when others are not - if that happens, then you end up with incompatible behavior because setVersion() calls that work on one browser won't work on others. So if setVersion() is going to expose GC behavior, then I think you have to codify in the spec the Least Common Denominator GC behavior (for example, spec-compliant implementations *must not* GC databases with event handlers registered). This is a rabbit hole I don't think we want to go down. In any case, I don't think that IDB should be the first place in the entire web platform where we expose GC behavior to clients. -atw On Tue, Feb 8, 2011 at 4:43 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Feb 8, 2011 at 3:31 PM, Glenn Maynard gl...@zewt.org wrote: On Tue, Feb 8, 2011 at 4:01 PM, Jeremy Orlow jor...@chromium.org wrote: I talked it over with Darin (Fisher), and he largely agreed with you guys. I'll file a bug saying that after unload, all IDBDatabases attached to that document should be closed. What happens if a database is open in a page in the back-forward cache? That's incompatible with onunload having side-effects. I know the BF-cache is off-spec, but it's extremely useful and will hopefully find its way into the standard some day, so it'd be nice to keep it in mind. I suppose the browser would discard whole pages from the BF-cache on demand if required by a setVersion call. That's exactly what we do in Firefox. Implementations have to be able to throw things out of the BF cache on command anyway (since you generally want to limit the number of pages living in BF cache, and so loading a new page often causes other pages to be thrown out), so it's just a matter of calling into the same code here. / Jonas
Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases
In some cases we leak them, yes (they live for the life of the parent
context) if the developer does not close them. Typically this is only when
you've cloned a MessagePort and sent the other end to a different process.
Trying to figure out if a port is reachable when the entangled port lives in
a different process (and whose reachability may itself depend on the
reachability of a third port in yet another process ad infinitum) is a
fairly intractable problem.
This does not happen with the implicit ports associated with dedicated
workers, because in WebKit those aren't actually MessagePorts (mainly
because the webkit implementation of dedicated workers predates message
ports). Chromium SharedWorkers use real MessagePorts though, so if you do
this:
var w = new SharedWorker(foo.html);
w.port.onmessage = function() {...};
that port will not be GC'd in chromium, even if the SharedWorker drops its
end of the port on the floor, until either the SharedWorker calls close() on
the port, the worker exits or your parent document is collected.
On a related note, please see this statement from section 5.5 of the
MessagePort spec:
Authors are strongly encouraged to explicitly close
MessagePorthttp://dev.w3.org/html5/postmsg/#messageport objects
to disentangle them, so that their resources can be recollected. Creating
many MessagePort http://dev.w3.org/html5/postmsg/#messageport objects and
discarding them without closing them can lead to high memory usage.
-atw
On Wed, Feb 9, 2011 at 12:56 PM, Glenn Maynard gl...@zewt.org wrote:
On Wed, Feb 9, 2011 at 2:05 PM, Drew Wilson atwil...@google.com wrote:
This discussion reminds me of a similar issue with MessagePorts. The
original MessagePort spec exposed GC behavior through the use of onclose
events/closed attributes on MessagePorts. It turns out that on Chromium,
there are situations where it's very difficult for us to GC MessagePorts (a
port's reachability depends on the reachability of the entangled port on an
entirely separate process), and so we just don't.
Err, so you just leak MessagePorts? Or just in those situations, whatever
they are? Does this happen even for the implicit MessagePort associated
with each worker?
--
Glenn Maynard
Re: [IndexedDB] setVersion blocked on uncollected garbage IDBDatabases
On Wed, Feb 9, 2011 at 2:03 PM, Jonas Sicking jo...@sicking.cc wrote: For what it's worth, shared workers already expose GC behavior. You'll get a already-existing shared worker, or a new one will be created, depending on if GC has collected the worker or not. Hmmm. That was certainly not the intent when I was discussing the WebKit implementation with Hixie, but either there was a miscommunication or the definition of when a document becomes discarded has changed since then. In the WebKit implementation, SharedWorker lifecycle is not tied to GC, but is instead tied to specific deterministic navigation/close actions on the parent document. Dependence of SharedWorkers on GC is bad for all the same reasons I outlined above - I'll follow up in a separate thread whether that is indeed the intent of the spec. Not saying that this is great, just pointing out that this is the case. / Jonas
Re: [Web Workers] Bug filed and general question
I'm also curious about this - I wrote a set of tests for SharedWorkers for WebKit that cover some of the subtler points around worker lifetime that I'm suspecting other implementations would find useful, and I'm guessing that there are tests from other implementations that would expose bugs in WebKit which would be useful to shake out sooner rather than later. I'm not certain if a test suite is a typical W3C deliverable, though, or if an external suite maintained by a third party (ala Acid) is the way to go? -atw On Thu, Jan 20, 2011 at 4:10 PM, Travis Leithead tra...@microsoft.comwrote: Also, have any tests been submitted for this spec yet? *From:* Travis Leithead *Sent:* Thursday, January 20, 2011 4:10 PM *To:* public-webapps *Cc:* Adrian Bateman *Subject:* [Web Workers] Bug filed and general question Is this the right list to comment about the web workers specification? I filed a bug: http://www.w3.org/Bugs/Public/show_bug.cgi?id=11827 and am also interested in participating (or forming?) a regular meeting time to discuss this spec, it's status, and path to REC. It seems to be at LCWD, but is blocked by workload of HTML5 editor??: http://www.w3.org/2008/webapps/wiki/PubStatus
Re: [Bug 11606] New: wanted: awareness of non-persistent web storage
FWIW, the Chrome team has come down pretty hard on the side of not ever leaking to apps that the user is in incognito mode, for precisely the reasons described previously. Incognito mode loses much of its utility if pages are able to screen for it and block access. I do think there's a user education burden that isn't entirely being met yet, though - the Chrome documentation doesn't really talk about local storage, for example. But I don't think that pushing this responsibility onto individual web applications is the right solution. -atw On Mon, Dec 27, 2010 at 5:45 PM, Glenn Maynard gl...@zewt.org wrote: (Note that this is from a ticket; the OP probably won't see replies here.) On Mon, Dec 27, 2010 at 7:46 PM, João Eiras joao.ei...@gmail.com wrote: When the user open a tab in private mode, he/she knows that data will not be stored, therefore there is no need for the webpage to reiterate that. It would be awkward to expect each and every webpage that requires storage to warn the user, while it should be the user agent that would properly help the user manage his/her data. Users won't completely understand what privacy mode does; what data can't be stored and what can. If you log into Gmail in privacy mode, does that mean that your saved drafts will be stored, or lost? That depends on whether they're stored on the server or in (for example) localStorage, a distinction no ordinary user can be expected to understand. If Gmail uses localStorage to save drafts (it doesn't), it should definitely be able to tell the user: warning, your saved drafts will be lost at the end of your browser session because your browser is configured not to keep this data around, or to change storage mechanisms. The alternative is ugly--users spending half an hour writing a mail, saving a draft, and having it silently lost, because they expected privacy mode to prevent their login cookie to be discarded, not their drafts. This means that even if localStorage is appropriate for a particular use, the dangers of angry, confused users may make it unacceptable. I don't like the idea of a not persistant attribute: although I don't personally find the transparency argument convincing, I'm pretty sure that even if the spec requires having such an attribute, browsers will ignore it. That seems worse than not having it at all. My first impression was that privacy mode should simply disable these interfaces (as the current Web Storage editor's draft seems to require, though as I mentioned before it's unclear), but that's no good for IndexedDB, which is very useful even if it's not persistant. I don't know the right answer in general. -- Glenn Maynard
Re: LCWD comments
On Wed, Jun 30, 2010 at 7:08 PM, Krzysztof Maczyński 198...@gmail.comwrote:
11. In [c]:
there is no way to override the type. It's always assumed to be
JavaScript.
This is a violation of orthogonality for no real benefit.
I know that the NativeClient team has experimented with supporting native
code in workers (in Chrome) in the past, using some fairly ugly hack based
on the suffix of the URL. Having some support for MIME types would enable
something like this in the future without having to resort to those hacks.
12. In [c]:
If there are any outstanding transactions that have callbacks
What's a transaction, when has it got a callback?
I believe this refers to DB APIs (WebSQLDatabase, IndexedDB [
http://www.w3.org/TR/IndexedDB/]) that might be exposed to workers.
Thus, scripts must be external files with the same scheme as the original
page: you can't load a script from a data: URL
Why impose this restriction? Is it that exceptions to same-origin policy
when it's still new would be confusing for specifiers and the audience, so
this possibility is postponed to the next version? In any case, I suggest
allowing workers to be instantiated with Function objects (whatever this may
be in language bindings, given positive resolution of 11) as well. Including
workers directly inline seems natural in many scenarios.
Agreed that data URLs would be useful. My recollection is that they are
currently prohibited because the script URL is used to derive the security
context for that worker (rather than inheriting it from the parent) which
I've never entirely understood.
I don't see how we can expose Function objects since the execution context
of workers are distinct from the execution context of the main page.
For example:
my_global = 123;
function worker_script() {
do_something(my_global);
}
new Worker(worker_script);
What does worker_script do when it accesses my_global? It certainly can't
have the global scope of the parent page in its scope chain. There's a
slightly longer discussion of that topic here:
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-December/024576.html
Re: Thoughts on WebNotification
On Fri, Jun 25, 2010 at 9:07 AM, Jeremy Orlow jor...@chromium.org wrote: Well, getting things to look would possibly take more effort on a web developer's part, but having _anything_ show up (for developers who only target browsers that support HTML) would always work...even if poorly. With Doug's proposal and the alt text proposal, if developers target a browser that only supports HTML, then things will completely break in browsers that don't support it. Maybe that's OK though? If the conversion algorithm is well specified, getting it to work in one text only browser would mean it works in all of them. (If they all follow the spec that is.) J An implicit assumption here is that a single block of HTML can both provide an attractive HTML-formatted display, and also be converted to plain text in a way that is attractive for plain text notification mechanisms (I also don't know how this addresses use cases like SVG notifications). I think that developers would inherently have to test both if they want to support both, so I'm not sure this helps. As a developer, I like the current API as it allows me to detect rich notification support via the presence of createWebNotification(), but also allows the user's preference (growl-only, for example) to be expressed even on browsers that can support web notifications by not exposing that API. I may be more blithely confident in developer's abilities to do capability detection than others in this discussion, though :) The advantage of the alt-text solution is it gracefully degrades (you won't get an exception thrown if you screw up capabilities detection) but you also can't do capability detection. I'm not 100% convinced that capabilities detection is important (offhand I'm not able to come up with any compelling use cases where I'd only want to display an HTML notification and not display any notification at all if they are not supported), so I'd support ditching the current API in favor of alt-text if that would lead to more interoperability. -atw
Re: Thoughts on WebNotification
On Thu, Jun 24, 2010 at 11:38 AM, Doug Turner doug.tur...@gmail.com wrote:
I have been thinking a bit on Desktop Notifications [1]. After reviewing
the Web Notification specification [2], I would like to propose the
following changes:
1) Factor out the permission api into a new interface and/or spec. The
ability to test for a permission without bring up a UI would improve the UX
of device access. I could imagine implementing this feature for use with
Geolocation as well as notifications. For example:
interface Permissions {
// permission values
const unsigned long PERMISSION_ALLOWED = 0;
const unsigned long PERMISSION_UNKNOWN = 1;
const unsigned long PERMISSION_DENIED = 2;
void checkPermission(in DOMString type, in Function callback);
}
Then we could do something like:
navigator.permissions.checkPermission(desktop-notification,
function(value) {});
or
navigator.permissions.checkPermission(geolocation, function(value) {});
2) Add language to the spec to indicate that the DOMStrings used
|createNotification| are not to include any mark up. Basically,
implementations are going to hand off notifications to system-level
services. For example, on the Mac, GROWL does not handle any mark up...
their API just takes plain strings. I'd like to see the API reflect this
reality. Something like the |title| and |body| arguments are to be treated
as plain text... or some such language.
Agreed. The current language reads:
The user agent may ignore any markup in this string and treat it as plain
text.
I think this is too vague, as it's sounds like a user agent could *not*
ignore markup in the string, and still be compliant with the spec. I think
we need to be very explicit that the string *must* be treated as plain text.
So if I pass in gt;bfoo/b as the body parameter to
createNotification(), the resulting notification must display the string
gt;bfoo/b, without stripping or converting any of the substrings that
might look like HTML entities.
3) Move Web notifications to a version 2 of the specification. For the
most basic use cases, this API isn't required and a web developer could use
the more base API to simulate this. Furthermore, as I mentioned above, many
system-level notification services know nothing about rendering html.
I'm not certain what moving WebNotifications to version 2 would mean,
especially since as specified, user agents already are free to leave
createWebNotification() undefined. Can you please clarify what you think, in
practice, having createWebNotification() moved to version 2 would
accomplish? Since compliant user agents are already free to *not* implement
this API, it sounds like your only goal could be to discourage other user
agents from implementing the createWebNotification() API, and I'm not at all
convinced that's either appropriate or feasible.
I hope that this is helpful,
Doug Turner
Mozilla Corp
[1] http://dougt.org/wordpress/2010/06/desktop-notifications/
[2] http://dev.w3.org/2006/webapi/WebNotifications/publish/
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).
Re: [Notifications] feedback requested on new Editor's Draft
This looks good. One thing which I suggested previously but which didn't make it into the spec is the ability for the UA to eliminate duplicate notifications. Since I've been using the existing experimental notifications API in Chrome, I've found that duplicate notifications are very common and quite irritating to the user, and there's no good way for applications to do duplicate elimination themselves (they could route notifications through a SharedWorker, but there's no good way for the SharedWorker to route click events back to the parent windows in such a way that they appear to be user gestures, so you wouldn't be able to satisfy the Go To Inbox use case described in the spec). A few notes on the spec itself: Section 4: - The definition of the onclose attribute is incorrect, and should read An event listener function corresponding to the event type '*close*', not 'error'. Section 5: - (parroting Anne's comment): It's somewhat ambiguous how the iconUrl parameter in createNotification() is processed - I'm wondering about how UAs should handle cases like HTTP auth while trying to access that resource (should they display the notification without an icon? fail the notification?). Likewise, I'm curious about how a UA should treat a non-secure iconUrl being generated from script within a secure page, although perhaps that's outside the bounds of the spec. - I'm wondering if the documentation for requestPermission() should read: If the current permission level is permission_denied, the user agent *must* take no action... (rather than may take no action). - Is the intent of the spec that an Exception is thrown if the user calls requestPermission() when the permission is already PERMISSION_ALLOWED? Section 6: - I don't understand the need for the optional mime parameter to createWebNotification(). What use case is it satisfying, that the normal resource fetching/mime-type inference mechanisms don't satisfy (i.e. +1 to Anne's comment) Section 8: - Should passing an unsupported type of web content to createWebNotification() generate an error event? - The display event is generated when the notification is passed along to the underlying notification platform - technically, since the underlying platform can also do its own queueing, it's possible that the display event is generated before the notification itself is displayed. Should this be mentioned in the spec? Section 9: - Is there any use case where an application needs to know that the system has closed the notification without user input? Currently a close event is only generated if the user explicitly dismisses a notification. -atw On Tue, Mar 23, 2010 at 3:54 AM, Robin Berjon ro...@berjon.com wrote: On Mar 23, 2010, at 11:33 , Anne van Kesteren wrote: Currently there are no processing requirements for the mime argument of createWebNotification(), do we really need it? Do we have use cases for content other than HTML or SVG? Presumably those can just work. Should we really put another interface on the global object? Can we not put these on window.navigator like other APIs that integrate with the system layer? +1, navigator is the new window :) -- Robin Berjon - http://berjon.com/
Re: Notifications
2010/2/23 Ian Fette (イアンフェッティ) ife...@google.com Am 23. Februar 2010 12:11 schrieb Anne van Kesteren ann...@opera.com: On Tue, 23 Feb 2010 20:20:13 +0100, Ian Fette (イアンフェッティ) ife...@google.com wrote: CreateInteractiveNotification(in DOMString text-fallback, [Optional] in DOMString MimeType1, [Optional] in DOMString NotificationFormat1, [Optional] in DOMString MimeType2, [Optional] NotificationFormat2, ...) forgive my broken IDL, I'm sure there's a better way to express it, but you get the idea. I don't see why it cannot be just a URL. If the user agent supports the type it will render it and it will fail otherwise. There's no need for complex multi-level fallback here in my opinion, nobody is going to bother with that anyway. video has multi-level fallback, so there is precedent for better or worse. That said, specifying a (set of) URL(s) may be fine, but I think it would still be nice for a UA to have fallback options. Is everyone going to use it? Probably not, but I think people that actually care would. E.g. if I have a property that I expect people on mobile devices to go to, I will make sure that it works on mobile devices, exactly as we do with properties today where we reasonably expect mobile users. I suspect that text fallback + a single URL would be sufficient. As a fallback/escape hatch, servers can sniff UA headers and serve up a different data type if a non-HTML-supporting device starts supporting this API. -Ian -- Anne van Kesteren http://annevankesteren.nl/
File URN lifetimes and SharedWorkers
This was recently brought to my attention by one of the web app developers in my office: http://dev.w3.org/2006/webapi/FileAPI/#lifetime User agents MUST ensure that the lifetime of File URN #dfn-fileURNs is the same as the lifetime of the Document [HTML5 #HTML5] of the origin script which spawned the File #dfn-file object on which the urn #dfn-urn attribute was called. When this Document is destroyed, implementations MUST treat requests for File URN #dfn-fileURNs created within thisDocument as 404 Not Found.[Processing Model #processing-model-urn for File URN #dfn-fileURN s] I'm curious how this should work for SharedWorkers - let's imagine that I create a File object in a document and send it to a SharedWorker via postMessage() - the SharedWorker will receive a structured clone of that File object, which it can then access. What should the lifetime of the resulting URN for that file object be? I suspect the intent is that File objects ought to be tied to an owning script context rather than to a specific Document (so, in this case, the lifetime of the resulting URN would be the lifetime of the worker)? -atw
Re: Notifications
2010/2/23 Jonas Sicking jo...@sicking.cc The same is not true for the suggest notification API. Several proposals have been put forward that do not rely on fallback. One of the reasons I stepped back from this discussion is because it seemed clear that we weren't going to make progress on solutions until we had agreement on requirements (specifically, the amount of interaction that we want to enable in these notifications). The non-fallback proposals that have been put forward aren't acceptable to me for the same reasons that Jonas is opposed to the fallback proposals - we both have a different vision for what the requirements should be. I'd like to see us focus on gaining some consensus around requirements, because I think the rest of these disagreements will mostly resolve themselves once we do that. -atw
Re: Notifications
On Fri, Feb 12, 2010 at 5:06 AM, Henri Sivonen hsivo...@iki.fi wrote: On Feb 11, 2010, at 16:07, Jeremy Orlow wrote: As has been brought up repeatedly, growl and the other notification engines are used by a SMALL FRACTION of all web users. I suspect a fraction of a percent. Why are we bending over backwards to make this system work on those platforms? More seriously though: Virtually every user of an up-to-date Ubuntu installation has the notification engine installed. As for Growl, the kind of users who install Growl are presumably the kind of users who care about notifications of multiple concurrent things the most. Furthermore, it seems that notifications are becoming more a part of operating system platfroms. For example, it looks like Windows 7 has a system API for displaying notifications: http://msdn.microsoft.com/en-us/library/ee330740%28VS.85%29.aspx This is a useful data point. It does seem like the major platforms are conforming to a simple icon + title + text interface for ambient notifications. The microsoft API seems more aligned with NotifyOSD (non-interactable notifications with a transient status tray icon provided to allow the user to click). I suspect a UA on those platforms (NotifyOSD and Microsoft) would display an icon with each notification to give the user the ability to register a click on and/or dismiss the notification. Are there other examples where we've dumbed down an API to the least common denominator for a small fraction of users? Especially when there's no technical reason why these providers could not be made more advanced (for example, embed webkit to display fully functional notifications)? It's not a given that it's an advancement in user experience terms not to force all ambient notifications into a consistent form. I think this is a reasonable point also. I also want to reiterate that your distinction between ambient and interactive notifications is an interesting one - most of the system notification frameworks are geared towards ambient notifications (it's why NotifyOSD does not support the DBUS actions array, I'm assuming). Their core use cases are things like your printer is out of paper, not You have an incoming voice call from Bob. Answer the call? Yes/No. I think the challenge here is framing our API in a way to allow developers to specify their intent (interactive vs ambient), with more restrictions on ambient content. The current spec makes one cut at this via createNotification vs createHTMLNotification, but it's not at all clear that HTML notifications are intended to be interactive rather than just pretty versions of ambient notifications (hence, Jonas' concern that developers will just create HTML notifications when what they really want is an ambient notification). One solution is only to support ambient notifications (which is essentially the thrust of the no HTML argument), but I'd be opposed to any API that does not allow for interactive notifications. I suppose that's a discussion for the requirements thread, though :) -atw
Re: Notifications
On Wed, Feb 10, 2010 at 2:17 AM, Henri Sivonen hsivo...@iki.fi wrote: On Feb 3, 2010, at 20:54, Drew Wilson wrote: Following up on breaking out createHTMLNotification() and createNotification() vs combining them into one large API - I believe the intent is that a given user agent may not support all types of notifications (for example, a mobile phone application may only support text + icon notifications, not HTML notifications). My main concern isn't mobile phones in the abstract but mapping to concrete system-wide notification mechanisms: Growl and NotifyOSD on Mac and Ubuntu respectively. I've had a few conversations about Growl and NotifyOSD, both on- and off-list, and I think it makes sense to discuss some of the underlying concerns. From these conversations, I've gotten the impression that some of the objections to HTML notifications are not entirely based in use cases (for example, it seems like the utility of being able to put markup such as bold text, or graphics, or links in a notification should be self-evident, even ignoring the various use cases around direct interaction with notifications). I haven't heard anyone claim that markup is bad - rather, the objections seem to boil down to a concern that somehow the mere existence of HTML notifications would undermine the adoption or use of Growl and NotifyOSD. I absolutely agree that Growl and NotifyOSD are important use cases to support, but I don't think they should be the tail that wags the dog (for example, I'm not sure that I agree with Henri that they should be treated as a more important use case than mobile phones, given the disparity in the size of the installed bases). And I also understand that for the users of these frameworks, having an application display notifications outside of the framework (possibly conflicting with those frameworks) would be a real problem. One of the suggestions made previously on this thread was to coalesce createNotification() and createHTMLNotification() into a single API with an optional HTML parameter - this would allow UAs on systems with Growl/NotifyOSD to ignore the HTML parameter passed in, and only display the text + icon information through the appropriate system framework. This also addresses concerns expressed on WHATWG that platforms that don't support createHTMLNotification() would break the web because web applications would fail to check for the existence of HTML support before calling these APIs - UAs would always have a useful fallback. I don't think it's in the best interest of developers or users to enforce a lowest-common-denominator approach to this API (especially since the currently dominant platform [Windows] doesn't have any native notification framework and would seem to derive great benefit from notifications with markup). Is the API change described above sufficient, or are there more things that we can do from an API standpoint to give UAs the flexibility to provide the desired user experience under Growl/NotifyOSD, without putting unnecessary restrictions on UAs running on other platforms? -atw So far, the only use case I've seen (on the WHATWG list) for HTML notifications that aren't close to the kind of notifications that Growl and NotifyOSD support has been a calendar alarm. I agree that calendar alarm is a valid use case, but I think HTML vs. not HTML isn't the right taxonomy. Rather, it seems to me that there are ambient notifications (that dismiss themselves after a moment even if unacknowledged) and notifications that are all about interrupting the user until explicitly dismissed (calendar alarms). I think the API for ambient notifications should be designed so that browsers can map all ambient notifications to Growl and NotifyOSD. As for notifications that require explicit acknowledgement, I think it would be worthwhile to collect use cases beyond calendar alarms first and not heading right away to generic HTML notifications. If it turns out that notifications that require explicit acknowledgements are virtually always calendar alarms or alarm clock notifications, it might make sense to design an API explicitly for those. For example, it could be desirable to allow a privileged calendar Web app to schedule such alarms to fire on a mobile device without having to keep a browsing context or a worker active at the notification time. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: Notifications
On Wed, Feb 10, 2010 at 2:33 PM, Robert O'Callahan rob...@ocallahan.orgwrote: On Thu, Feb 11, 2010 at 11:10 AM, Drew Wilson atwil...@google.com wrote: One of the suggestions made previously on this thread was to coalesce createNotification() and createHTMLNotification() into a single API with an optional HTML parameter - this would allow UAs on systems with Growl/NotifyOSD to ignore the HTML parameter passed in, and only display the text + icon information through the appropriate system framework. This also addresses concerns expressed on WHATWG that platforms that don't support createHTMLNotification() would break the web because web applications would fail to check for the existence of HTML support before calling these APIs - UAs would always have a useful fallback. The problem with that is that authors who test with a system that supports HTML notifications could easily provide the wrong non-HTML message, or no message at all, and not notice. It also forces authors to say things twice. Analogously, developers can (and do!) create pages that rely on javascript or images being enabled, which break if a UA does not support them. I would not use this as an argument against UAs supporting Javascript or images. You make the further point that application authors may intentionally *only* want to display HTML notifications, and would rather display nothing if HTML is not available (they pass in no message at all) - I'm not sure this is true, but if it is I'd say that's an argument in favor of supporting HTML in this API, not against it. I think a better way to go would be to support a restricted subset of HTML, and then consider how the UA should extract text for a plaintext-only notification framework (possibly opting to fall back to non-native notifications if the text extraction doesn't work). For example, you could allow only b and img elements, and for text-only notifications you would strip b and use the alt text for img, and if the author didn't provide alt text for img then and only then you would fall back to non-native notifications. It seems unusual to me that in a spec directed at HTML-based UAs, we would define some sort of domain-specific markup language rather than simply supporting HTML. Browsers know how to render HTML and can extract text appropriately if for some reason they need to down-render (for example, see the textContent and innerText element properties). Why would we define a separate markup language to allow defining marked up text that can be rendered differently depending on the display capabilities - isn't that what HTML is for? Is there an advantage to defining a subset? Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: Notifications
On Wed, Feb 10, 2010 at 3:31 PM, Robert O'Callahan rob...@ocallahan.orgwrote: On Thu, Feb 11, 2010 at 12:03 PM, Drew Wilson atwil...@google.com wrote: On Wed, Feb 10, 2010 at 2:33 PM, Robert O'Callahan rob...@ocallahan.orgwrote: I think a better way to go would be to support a restricted subset of HTML, and then consider how the UA should extract text for a plaintext-only notification framework (possibly opting to fall back to non-native notifications if the text extraction doesn't work). For example, you could allow only b and img elements, and for text-only notifications you would strip b and use the alt text for img, and if the author didn't provide alt text for img then and only then you would fall back to non-native notifications. It seems unusual to me that in a spec directed at HTML-based UAs, we would define some sort of domain-specific markup language rather than simply supporting HTML. Browsers know how to render HTML and can extract text appropriately if for some reason they need to down-render (for example, see the textContent and innerText element properties). Why would we define a separate markup language to allow defining marked up text that can be rendered differently depending on the display capabilities - isn't that what HTML is for? Is there an advantage to defining a subset? If it supports, e.g., scripting, then you have to define what the relationship is between the browsing context for the notification and the browsing context for the opener. Can a notification document navigate itself using document.location = ...? At that point, this sounds like a specialized version of window.open. If that's your intent, maybe we should just add a flag to window.open? I agree - the spec needs to define all of the implications of HTML support as well as any restrictions as to its use. On the bright side, from a security standpoint treating an HTML notification as its own browsing context ala window.open() is a well-understood model. As for using a specialized version of window.open() for notifications - that's an interesting suggestion. I think we'd still need to deal with the permission grant issue as well as having a good way to generate icon+header+body notifications from the HTML for compatibility with Growl/NotifyOSD/mobile platforms - I still think that having some way for the developer to explicitly specify a title/icon/body is superior to having the browser have to infer these pieces from a parsed DOM tree. But it's a good point that this starts to feel more like window.open(). Stepping back from the HTML issue, I note that one of the things in the NotifyOSD/DBUS API is the concept of a client-specified replace ID - the idea is that client applications can give their notifications a replace ID, and when that application displays a notification with that ID it replaces any currently displayed notification with that ID. I think that something like this would solve one of the core issues with the proposed notification API, which is avoiding duplicate notifications in the case where you have the same web page open in multiple windows. If we supported an optional replace ID parameter in createNotification(), then a page that wanted to have (say) a you have new mail notification could give that notification an ID of new_mail, so if any other page under the same origin tried to display a notification with a new_mail ID it would just replace the existing notification rather than displaying a duplicate notification. If we don't support this, apps have to jump through hoops using SharedWorkers or other methods to make sure they don't annoy the user with duplicate notifications. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: Notifications
On Wed, Feb 10, 2010 at 3:22 PM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Feb 10, 2010 at 3:03 PM, Drew Wilson atwil...@google.com wrote: On Wed, Feb 10, 2010 at 2:33 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Thu, Feb 11, 2010 at 11:10 AM, Drew Wilson atwil...@google.com wrote: One of the suggestions made previously on this thread was to coalesce createNotification() and createHTMLNotification() into a single API with an optional HTML parameter - this would allow UAs on systems with Growl/NotifyOSD to ignore the HTML parameter passed in, and only display the text + icon information through the appropriate system framework. This also addresses concerns expressed on WHATWG that platforms that don't support createHTMLNotification() would break the web because web applications would fail to check for the existence of HTML support before calling these APIs - UAs would always have a useful fallback. The problem with that is that authors who test with a system that supports HTML notifications could easily provide the wrong non-HTML message, or no message at all, and not notice. It also forces authors to say things twice. Analogously, developers can (and do!) create pages that rely on javascript or images being enabled, which break if a UA does not support them. I would not use this as an argument against UAs supporting Javascript or images. This has indeed lead to that any browser that wants to get a significant user base, or wants to be able to browse a significant part of the web has to implement a Javascript engine and the DOM. I hear you. I'm not convinced that the web would be a better place without support for Javascript or Images though, despite the burden it might put on UA developers looking for wide compatibility. The nice thing about notifications is they are *clearly* an optional addition to the core functionality of a site (since the user has to grant permission to allow them to be displayed - they don't work by default anyway) so from an end user standpoint they can merely deny notification permission to web apps that do not display useful notifications. Your original objection about the existence of createHTMLNotification() was spot-on - UAs that do not provide this API would indeed break the web because application javascript code would throw undefined method exceptions in the middle of related operations. With a coalesced API that exists regardless of platform, it seems like this argument has less force. The argument is that the same thing would happen here. Every browser would have to implement support for HTML notifications. I.e. calling it optional will likely only be true in theory after a while. I'm assuming you aren't suggesting that this would happen because HTML notifications are so much better than non-HTML that developers just want to use HTML notifications :) I think our goal for optional support for HTML should not be that this would somehow enable desktop browsers to omit support for HTML notifications (keep in mind that NotifyOSD and Growl are far from ubiquitous on their relative platforms - browsers on Linux and the Mac will still need to be able to display notifications in the absence of these frameworks). Rather, providing a text + icon fallback for the HTML parameter enables this API to work on platforms that *cannot* support HTML notifications (a good example of a platform like this would be the Palm Pre, which has a dedicated text notification bar), similar to alt-text for img tags. A related goal is to support things like NotifyOSD and Growl gracefully, but IMO the expectation should not be that desktop browsers can/should just omit HTML notification support entirely. So I think the right question to ask isn't does this force all browsers to support HTML notifications? because I think that all browsers on platforms that can support them will need to do so anyway, but rather does the presence of widespread HTML notification support make it more likely that developers will neglect text+icon notifications, to the detriment of users that want them. Anyhow, my other concern with baking in lowest-common-denominator functionality into our APIs is that platform capabilities evolve over time. To make up a hypothetical example, it would not be unthinkable for another notification framework to supplant Growl over the next 5 years (for instance, if Apple added support for WebKit-based HTML notifications to the OS), or for Growl to add support for markup in its notifications, and yet UAs would be powerless to take advantage of these new capabilities if the APIs themselves lock in the lowest-common-denominator functionality. If we can future-proof the API, we should. / Jonas
Re: Notifications
On Wed, Feb 10, 2010 at 5:49 PM, Jonas Sicking jo...@sicking.cc wrote: And I think the answer is yes. Any time someone talks about an optional web feature I get nervous. Can you give any examples of successful optional web features that exist today? I'd suggest Javascript and Images, but you've rejected them because you don't think they are examples of successful optional features (meaning that browsers that don't support them are not equally compatible with all web content) - and yet most browsers do support turning them off so there must be some value for a subset of users. The history of the web has generally been that good features spread to become ubiquitous, and if your concern is that HTML notifications will become one of those features, then I echo your concern :) I think there are some potentially conflicting goals for any of the HTML APIs: 1) Providing a single lowest-common-denominator API that we can support on every single platform to provide the maximum amount of compatibility. For notifications, pretty much every capable platform can display an icon and a single line of text, so if we wanted to be pedantic we could make that our API, but the currently proposed icon + header + body text is probably more reasonable. 2) Providing an API that is flexible enough to take advantage of the capabilities of more advanced platforms. 3) Future proofing the API (as capabilities of platforms grow, the API can continue to support them) I think we all have differing opinions over the importance of these varying goals - ideally we'd find an API that can satisfy all three, but I do agree that adding optional HTML support has a potentially negative impact on goal #1. However, that doesn't mean that we should pursue an API that *only* satisfies goal #1. I don't want to get completely focused on a single possible solution to this dilemma (i.e. supporting an optional HTML parameter), although I have to admit I personally think the idea of a fully-scriptable active notification is really compelling. Are there other solutions that would better meet those 3 goals? Maybe I'm off-base and goal #1 is the only one that matters in this case? -atw
Re: Notifications
On Fri, Feb 5, 2010 at 6:52 AM, Anne van Kesteren ann...@opera.com wrote: On Thu, 04 Feb 2010 00:36:26 +0100, John Gregg john...@google.com wrote: I'm familiar with that version of the proposal (in fact my WHATWG proposal from March '09 had the same language: untrusted notifications displayed in-browser), but considering it more I think it is too limiting. Considering widgets, mobile browsers, browser extensions, workers (already in the spec), etc., which all might want to use this API, it's potentially many different forms of UI for untrusted notifications---where do they go, how is it clear where they came from? Compare that to a single place outside the browser, with a clear source displayed, once trust is established. I prefer the latter. You probably need different permission UI regardless. E.g. on mobile browsers you might not show the notification in-tab but would only something if the user did something in response to a dialog. I've thought about this some more, and I'm not at all convinced that in-tab notification support is the right way to go. It seems that in-tab notifications are a solved problem already (in a few lines of code an app can create a floating div with whatever content it desires) with the advantage that the web app can display that notification in a way that is consistent with the UI in the site (set the notification so as not to interfere with site content, appropriately style the notification so it fits in with the look of the site, etc). I don't quite understand what browser-provided in-tab notifications would provide that would be an improvement over existing functionality. In the case the first notification from an application is an important one, that app should be able to request permission for out-of-tab notifications beforehand; Aren't notifications by nature somewhat non-important? In any event, we could expose to the application whether or not it was displayed and if it was not the application could pick an alternative route to convey the information. I'd say exactly the opposite - that's why we proactively display them to the user rather than leave them passively within the page waiting for the user to go look at them. for that reason I'm convinced requestPermission() is desirable. However beyond that, perhaps the spec should be flexible; if a UA wants to treat PERMISSION_UNKNOWN as show in-tab rather than throw exception, the spec could allow it -- but I don't think it should require it. Would that be acceptable? I'm not convinced we need a permission API and would therefore rather leave it out to see if we can do without. We do not have an API like this anymore else. We do have permissions UI in other parts of HTML5 (geolocation, for example). The difference here is that applications generally would like the user to make a permission grant *before* they actually want to display a notification - actually waiting until it's time to display a calendar reminder before the user is prompted for permission means that the user is likely to miss that first calendar event. One possible alternative to an explicit requestPermission() API would be to instead just have the browser display permissions UI the first time the user calls createNotification(). An application that wants to get permission in advance could just call createNotification(), but then never actually call show() (or, perhaps they could just display a confirmation notification like Desktop notifications are now enabled for FooMail). As someone who has integrated notifications into a web app, I have to say that I found the explicit API useful, but I'm not currently using the callback for requestPermission() so an alternate API could work so long as there was some way to initiate a permission grant without actually displaying a notification. -- Anne van Kesteren http://annevankesteren.nl/
Re: Notifications
On Fri, Feb 5, 2010 at 10:36 AM, Anne van Kesteren ann...@opera.com wrote: On Fri, 05 Feb 2010 19:19:24 +0100, Drew Wilson atwil...@google.com wrote: I've thought about this some more, and I'm not at all convinced that in-tab notification support is the right way to go. It seems that in-tab notifications are a solved problem already (in a few lines of code an app can create a floating div with whatever content it desires) with the advantage that the web app can display that notification in a way that is consistent with the UI in the site (set the notification so as not to interfere with site content, appropriately style the notification so it fits in with the look of the site, etc). I don't quite understand what browser-provided in-tab notifications would provide that would be an improvement over existing functionality. Allowing them to be displayed there and not having an active permission dialog would make it totally opaque to the application whether or not it can do system-wide notifications. This seems better for privacy and I also think it makes it less likely the user opts into something the user does not want. I'm not entirely convinced that opacity here is a good thing, especially since the alternative for apps that want this behavior would be: if (notifications.checkPermission() == PERMISSION_GRANTED) notifications.createNotification(icon, title, body); else jqueryUI.displayInTabNotification(icon, title, body); Or something similar. For an example, there is no value for something like a Calendar app to display in-tab event reminders. The whole point of event reminders is to notify the user of an upcoming event in a way that is visible when they are doing other tasks, but in a less-invasive way than an alert() but in-tab notifications would not provide this. Opacity here would work against the application's ability to provide the desired user flow which is to drive the user towards granting desktop notification permissions. I would rather have the application know that it can't display desktop notifications rather than silently defaulting to an unwanted user experience. I guess in summary, the main goal of having a notification API is to provide a way for web apps to display notifications to the user when the associated tab is not active. The application already has ways to display notifications to the user when the tab *is* active. It seems like the only reason to default to in-tab notifications is to jump through hoops to avoid an active permission grant UI (i.e. to have in-tab notifications with passive UI for making them out-of-tab) - no application actually wants in-tab notification functionality since they already have that. So I'm not convinced that avoiding an active permission grant should be a goal of this API, especially since there are a number of other APIs which implicitly have active permission grant UIs (geolocation, storage quota, etc). If a UA wants to avoid displaying active permission grants there are other ways for them to do it without in-tab notifications (they could display a pending notification icon in the tab chrome, etc) - perhaps removing requestPermission() would provide the flexibility to allow UAs to do this if that's what they want? I'm not convinced we need a permission API and would therefore rather leave it out to see if we can do without. We do not have an API like this anymore else. We do have permissions UI in other parts of HTML5 (geolocation, for example). The difference here is that applications generally would like the user to make a permission grant *before* they actually want to display a notification - actually waiting until it's time to display a calendar reminder before the user is prompted for permission means that the user is likely to miss that first calendar event. One possible alternative to an explicit requestPermission() API would be to instead just have the browser display permissions UI the first time the user calls createNotification(). An application that wants to get permission in advance could just call createNotification(), but then never actually call show() (or, perhaps they could just display a confirmation notification like Desktop notifications are now enabled for FooMail). This sounds somewhat better to me. As someone who has integrated notifications into a web app, I have to say that I found the explicit API useful, but I'm not currently using the callback for requestPermission() so an alternate API could work so long as there was some way to initiate a permission grant without actually displaying a notification. I'm still a little bit afraid of what's going to happen when we get many of these APIs that need some kind of user permission. It's going to be too confusing I think. I agree and there have been similar concerns expressed about permissions explosions elsewhere. I suspect the HTML standards community will need to look at how to bulk-manage
Re: Notifications
Following up on breaking out createHTMLNotification() and createNotification() vs combining them into one large API - I believe the intent is that a given user agent may not support all types of notifications (for example, a mobile phone application may only support text + icon notifications, not HTML notifications). Having these APIs broken out separately allows the UA to communicate whether it supports one or the other to the web app (a UA that does not support HTML notifications would leave createHTMLNotification() undefined). -atw On Wed, Feb 3, 2010 at 10:33 AM, John Gregg john...@google.com wrote: On Wed, Feb 3, 2010 at 9:55 AM, Olli Pettay olli.pet...@helsinki.fiwrote: Hi all, some random comments about http://dev.w3.org/2006/webapi/WebNotifications/publish/ (I didn't know that the draft existed until the link was mentioned in an email to @whatwg mailing list :/ ) Hi Olli, I was hoping to get some more work in on the draft before officially sending it out for feedback, but since there is interest out there it's time to start ramping it up. Thanks for the comments! NotificationCenter is a bit strange. Why do we need a separate interface for this? I'd rather added createNotification to window object, or to .screen. The idea was to have a common place to manage notification permissions as well as create notifications. That would end up with a lot of notifications-specific items on the window object. createNotification and createHTMLNotification could be merged. Based on the parameters UA could create a bit different kinds of notifications. Or depending on what kind of resources get loaded. PERMISSION_NOT_ALLOWED vs. PERMISSION_DENIED The naming should be better. Maybe PERMISSION_UNKNOWN and PERMISSION_DENIED ? That sounds reasonable to me, I'll make that change. requestPermission talks about user gesture, but doesn't define what an user gesture actually is. I thought the term was well known, but I will find a suitable reference. If createNotification would be in .screen or in window, then perhaps rename other methods to .requestNotificationPermission() and .checkNotificationPermission() those are a bit long ones, but still shorter than .notifications.requestPermission() As mentioned above, I think it's a good trade of 2 extra characters to put these things in a common place; it also makes it more easy for an author to check if (window.notifications === undefined). Why the need for notifications in a worker? In which screen would the notification show up? I would leave that out of the draft. Worker can easily send some message to window to ask for a notification. The thought is that a shared worker would be a good place to generate notifications for a multi-tab application, while avoiding duplicate alerts. If we require it to find a window, it has to keep track of which windows are open. As that set may change, I don't think it's as easy as allowing direct access to the API. How does create(HTML)Notification actually work. At which point does it load the external resources? At which point is display event dispatched? When showing the notification? But what if the external HTML file or icon file isn't loaded yet? I will make this more specific in the draft: create[HTML]Notification should not load the necessary resources until it is about to be displayed (in case of a queue). Once it is at the top of the queue, it should: - load its resources as if opening a new window - dispatch the display event - show itself on the screen The function provided in the callback parameter will be invoked when the user has responded to the permission request. The IDL doesn't show any callback parameter. Quite right -- will fix.
Re: Notifications
That's true in general about any UI the worker may display (HTTP Auth, Certificate errors, etc) - the UA generally picks a parent document on behalf of the worker and displays the UI on the associated screen. If the client cares about which screen specifically it's displaying on (because it has parent windows spread across multiple screens?), it can try to route things back through a specific window itself - providing this API from worker context does nothing to prevent that and it's a huge convenience for the overwhelming majority of uses. -atw On Wed, Feb 3, 2010 at 10:58 AM, Olli Pettay olli.pet...@helsinki.fiwrote: On 2/3/10 8:55 PM, Jeremy Orlow wrote: Agreed. Having a shared worker that doesn't need to worry about races with shutting down windows seems like a big win. Olli, do you foresee any problems with allowing access from workers? In a multiscreen environment worker can't define which screen to use. That seems to be a pretty major problem, IMO. -Olli
Re: Notifications
I'm not entirely certain I understand this suggestion - is this just a
change to the spec language, or does it impact the actual API (i.e. would
webapps still do the following):
if ('createHTMLNotifications' in window.notifications) {
...html notifications exist...
}
Or are you proposing something else?
Since these APIs are available in Chrome currently (as the experimental
window.webkitNotifications API), there's no reason for us to debate the
utility of HTML notifications in the abstract when we can get feedback from
application developers with real use cases. I've been running into some of
the limitations of the text + icon notifications in my recent work (one
example: the lack of an onclick event) which I'll try to write up sometime
in the near future.
-atw
On Wed, Feb 3, 2010 at 11:41 AM, Anne van Kesteren ann...@opera.com wrote:
On Wed, 03 Feb 2010 19:54:44 +0100, Drew Wilson atwil...@google.com
wrote:
Following up on breaking out createHTMLNotification() and
createNotification() vs combining them into one large API - I believe the
intent is that a given user agent may not support all types of
notifications
(for example, a mobile phone application may only support text + icon
notifications, not HTML notifications). Having these APIs broken out
separately allows the UA to communicate whether it supports one or the
other
to the web app (a UA that does not support HTML notifications would leave
createHTMLNotification() undefined).
If that is the idea createHTMLNotification() should be on a separate
supplemental interface that user agents on platforms that support HTML
notifications can implement to make it clear it might not be available and
that is somewhat separate. (Not sure whether I agree we need HTML
notifications though, especially for v1.)
--
Anne van Kesteren
http://annevankesteren.nl/
Re: Notifications
On Wed, Feb 3, 2010 at 1:22 PM, Anne van Kesteren ann...@opera.com wrote: On Wed, 03 Feb 2010 18:55:32 +0100, Olli Pettay olli.pet...@helsinki.fi wrote: some random comments about http://dev.w3.org/2006/webapi/WebNotifications/publish/ (I didn't know that the draft existed until the link was mentioned in an email to @whatwg mailing list :/ ) Some other thoughts on this API: * It would be nice if we could avoid the exception somehow. Maybe just have an error callback? I thought that in practice the exception was reasonable, specifically because the exception is entirely avoidable because you can check permission before calling any protected APIs. I would rather have an explicit failure in case of bugs (and calling createNotification() without getting permission first is a bug) rather than a silent failure. Perhaps I'm misunderstanding what you are suggesting - are you talking about the exception thrown from requestPermission() or the exception thrown from createNotification()? * I'm not a big fan of introducing two new ways to load resources as proposed in this API. We are not doing that elsewhere either (consider e.g. drawImage()). Passing a Document and HTMLImageElement (potentially HTMLCanvasElement and HTMLVideoElement too I suppose) would make more sense. This does create some additional burden on the developer but it does keep security-sensitive operations more limited and also gives the ability for greater control and information. (E.g. with XMLHttpRequest you get to know how fast the resource is being fetched, etc.) Libraries could provide the higher-level API. I see createHTMLNotification() as akin to window.open() - it doesn't really increase the attack surface. I'm not sure I completely understand the suggestion of passing in a Document object - what would that API look like? Since an HTML notification is (effectively) a separate window, it just seems like tracking progress for the loading of resources is a solved problem for app developers - Gmail displays a loading bar while its window loads. I suspect I'm not understanding your use case entirely though. * If we keep checkPermission() it should not be a method. But I'm not sure it is needed if there is an error callback. I think that we need some way to get the current permission but I agree that an attribute would be better than an API call. I'm not sure that an error callback from createNotification() is sufficient as you generally want to initiate the permission grant *in advance* of displaying notifications. As an example, allow me to describe the following use case: A web mail program would like to display desktop notifications when new mail arrives. Because UAs require calls to requestPermission() to be in the context of a user gesture, I need to display some UI along the lines of click here to enable desktop notifications for new mail, which, when clicked upon, results in the web app calling requestPermission() to initiate the permission grant from the UA. I only want to display this UI if the user has not already been granted/denied permission (once he's responded to the permission grant dialog, I no longer want to display this UI in future loads of the program). Without a checkPermission()-type API (or permission attribute) there's no way for me to achieve this user flow. -- Anne van Kesteren http://annevankesteren.nl/
Re: Notifications
On Wed, Feb 3, 2010 at 2:50 PM, Anne van Kesteren ann...@opera.com wrote: On Wed, 03 Feb 2010 23:40:23 +0100, John Gregg john...@google.com wrote: Yes, this makes sense; I am changing the draft spec to have a permissionLevel attribute. I think having access to the permission level is important for the same reasons as Drew gave: the site should know whether to display permissions UI in advance of having a notification to show. The design Hixie once made for notifications was much nicer I thought. Initially you would get tab-scoped in-browser notifications but the user could opt-in (maybe when the first of such notifications was shown) into system-wide notifications. The application would not have to know either way and the user is not forced to click through permission dialog in order to see something. It's still available in one of the older copies of HTML5: http://www.w3.org/TR/2008/WD-html5-20080610/web-browsers.html#notifications That's an interesting option (fallback to in-tab display if the parent context does not have permission). BTW, I'd note that supporting this would not preclude continuing to provide a way for an app to explicitly request a permission grant, as a way for guiding users to setup the app as a trusted notification source. The alternative would be for applications to have UA-specific directions directing the user to click on specific items in the UA chrome (If you want new mail notifications to appear on your desktop, click on the smiley face in the notification titlebar) which is a more clunky user flow. -atw
Re: [webworkers] SharedWorker and ApplicationCache
The specific implementation of SharedWorkers in WebKit does this currently, but that is not a feature of the spec - I have this on my todo list to resolve once I've finished the Chromium version of shared workers. -atw On Mon, Nov 9, 2009 at 10:09 AM, Alexey Proskuryakov a...@webkit.org wrote: 07.11.2009, в 10:47, Michael Nordman написал(а): I've been wondering if SharedWorkers should have a means of establishing an appcache similar to how pages can via the html manifest='x' mechanism. My mental model is that a shared worker is very much like a top-level page with respect to appcaches, but that means for a shared worker to express/establish its appcache is missing. Don't shared workers depend on HTML documents for network loading? I'm not sure how they can have independent caches, if they just ask a document to fetch a resource for them. - WBR, Alexey Proskuryakov
Re: [webworkers] SharedWorker and ApplicationCache
Yeah, I thought about this some back when I was trying to piece together a proposal for persistent workers. I suppose you could pass an optional manifest URL to the SharedWorker constructor, with appropriate restrictions on different pages creating the same SharedWorker but with different manifest URLs. Since there's already an optional name parameter, you could always require the name to be specified if you are specifying an app cache URL (so the third argument to the constructor would always be the manifest URL). -atw On Sat, Nov 7, 2009 at 10:47 AM, Michael Nordman micha...@google.comwrote: I've been wondering if SharedWorkers should have a means of establishing an appcache similar to how pages can via the html manifest='x' mechanism. My mental model is that a shared worker is very much like a top-level page with respect to appcaches, but that means for a shared worker to express/establish its appcache is missing. On Sat, Nov 7, 2009 at 9:14 AM, Drew Wilson atwil...@google.com wrote: You may have two separate pages running from different app caches (or version), each of which is trying to access the same shared worker, so we don't want to tie it explicitly to a specific parent's app cache/version. It does seem a bit wonky, though - if you have one parent who has an app cache that has two resources in it (a.js and b.js) and another parent who has an app cache that has a different two resources in it (a.js and c.js), it's non-deterministic which app cache the shared worker would be associated with, and this could break apps. I'm not sure that there's a good solution for this, given that manifests can only be associated with an HTML resource. -atw On Sat, Nov 7, 2009 at 8:57 AM, Anne van Kesteren ann...@opera.comwrote: We were wondering why there is a quite complicated resolution algorithm to determine the ApplicationCache that belongs to the SharedWorker rather than just passing the ApplicationCache to the SharedWorker at creation time (i.e. as constructor argument). Is there anything that is gained by the current model? -- Anne van Kesteren http://annevankesteren.nl/
