Re: [whatwg] Notifications and service workers
On Sat, Oct 4, 2014 at 4:42 AM, Jonas Sicking jo...@sicking.cc wrote: Another thing we could do here is to simply not address this use case. Does gmail for android do the same thing? I wasn't able to reproduce it though I might have done something wrong. AFAICT, no - gmail for android doesn't use web notifications. In general the mobile versions of gmail are kind of bare-boned fallbacks in favor of the native apps. I'm not sure that we should pay too much attention to the use case of apps like gmail that want to do lots of hands-on control of their notifications - I think that's pretty much a rare case. I do think it's useful to have some guidelines for how platforms handle notifications, though, just to make sure that some web developer doesn't just test on one platform, and get unexpected behavior on others. So, trying to encourage auto-close behavior (maybe via SHOULD language in the spec) would be good for consistency's sake. Clarifying what should happen when the user clicks on a notification would also be good (should it bring the tab to the foreground? Should it leave it up to the app? Should it provide a default, but allow apps to override it?) - I think all three of these behaviors are currently implemented (or have been in the past) by different UAs.
Re: [whatwg] Notifications and service workers
On Mon, Oct 6, 2014 at 9:15 AM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Oct 6, 2014 at 12:05 AM, Andrew Wilson atwil...@google.com wrote: On Sat, Oct 4, 2014 at 4:42 AM, Jonas Sicking jo...@sicking.cc wrote: Another thing we could do here is to simply not address this use case. Does gmail for android do the same thing? I wasn't able to reproduce it though I might have done something wrong. AFAICT, no - gmail for android doesn't use web notifications. In general the mobile versions of gmail are kind of bare-boned fallbacks in favor of the native apps. Actually, my question was in regards to the native gmail app. Not web content of any sort. Ah, sorry, didn't understand. From what I can tell, gmail on android aggregates multiple messages into a single notification (like the list notification type you suggested). I'm assuming this is done by gmail itself and not the OS, but my Android-fu is a bit limited so I'm not positive. I note that the native gmail app does different things depending on what type of notification is visible. If there's just one new email in the notification, the notification lets you archive/reply to the email right from the notification, and just clicking the notification brings up the email in the native app. If there are more than one email in the notification (list notification) then there are no extra UI options, and clicking the notification just launches the app and brings up your inbox.
Re: [whatwg] Notifications and service workers
On Mon, Sep 29, 2014 at 9:14 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Sep 29, 2014 at 6:09 AM, Andrew Wilson atwil...@google.com wrote: OK, looked back into the Gmail code (since it'd been a couple of years since I was really down in that notification code). There are two places where we listen for close events currently: 1) When closing an email notification - gmail keeps its own queue of pending notifications (so if several emails arrive at once, we don't display seven notifications simultaneously, but instead we display one at a time, cycling through them after 5-6 seconds). If the user closes a notification, then we clear out our queue of pending notifications, because the expectation is that the user doesn't want any more email notifications (the experience before we did that was really annoying). Ah, so the fact that the user close one notification is seen as an indicator that the user doesn't want more notifications right now. This definitely seems like the best use case for the close event so far. Though it doesn't seem like you'd actually want a service worker, or indeed the full app, to be started up in order to handle that event. For an app that wants to do something like this, but the app uses persistent notifications, I think using Notification.get() is the best solution. This way the application can catch closing of notifications whenever they happen, but the app still doesn't need to be woken up if it's not running when a notification is closed. For an app that uses non-persistent notifications, such as gmail, I think we have two options. Either use Notification.get() here too. Or we allow close events to be fired for non-persistent notifications. 2) When closing a chat notification, we tell the chat subsystem that the notification has gone away so that it can clear its reference to the Notification. The chat subsystem keeps a reference to the notification so it can close a chat notification if the user clicks on a chat frame, but this might no longer be necessary if we implement Notification.get(). Anyhow, our reference to the chat subsystem is a reference to an object and that object isn't structured-cloneable because it has a bunch of reference to DOM elements, etc. Interesting. Yeah, Notification.get() seems like it would help you solve this. Though potentially the API should also have a function like Notification.close(DOMString tag). Seems like a common use case of wanting to close a notification when the user engages with a piece of UI, and it seems silly to have to instantiate a Notification instance through .get() to do so. The other reason we handle the close event is that gmail has this idea of a chat notification that the user hasn't seen yet - the chat frame has a visual highlight. But if the notification is dismissed by the user, we can clear this highlight, under the assumption that the user has seen this notification. This functionality may be somewhat broken on platforms that auto-close notifications though. Yeah, this is the case that Jake brought up. Though Tab pointed out that other chat systems generally does not treat close as an hint for user has read. Interesting to hear that gmail does. On what platforms do non-persistent notifications not close after a timeout? My test on mac and linux chrome just showed that notifications never close on those platforms.
Re: [whatwg] Notifications and service workers
On Tue, Sep 30, 2014 at 10:15 AM, Jonas Sicking jo...@sicking.cc wrote: On Sep 30, 2014 12:48 AM, Andrew Wilson atwil...@google.com wrote: On Mon, Sep 29, 2014 at 9:14 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Sep 29, 2014 at 6:09 AM, Andrew Wilson atwil...@google.com wrote: OK, looked back into the Gmail code (since it'd been a couple of years since I was really down in that notification code). There are two places where we listen for close events currently: 1) When closing an email notification - gmail keeps its own queue of pending notifications (so if several emails arrive at once, we don't display seven notifications simultaneously, but instead we display one at a time, cycling through them after 5-6 seconds). If the user closes a notification, then we clear out our queue of pending notifications, because the expectation is that the user doesn't want any more email notifications (the experience before we did that was really annoying). Ah, so the fact that the user close one notification is seen as an indicator that the user doesn't want more notifications right now. This definitely seems like the best use case for the close event so far. Though it doesn't seem like you'd actually want a service worker, or indeed the full app, to be started up in order to handle that event. For an app that wants to do something like this, but the app uses persistent notifications, I think using Notification.get() is the best solution. This way the application can catch closing of notifications whenever they happen, but the app still doesn't need to be woken up if it's not running when a notification is closed. For an app that uses non-persistent notifications, such as gmail, I think we have two options. Either use Notification.get() here too. Or we allow close events to be fired for non-persistent notifications. 2) When closing a chat notification, we tell the chat subsystem that the notification has gone away so that it can clear its reference to the Notification. The chat subsystem keeps a reference to the notification so it can close a chat notification if the user clicks on a chat frame, but this might no longer be necessary if we implement Notification.get(). Anyhow, our reference to the chat subsystem is a reference to an object and that object isn't structured-cloneable because it has a bunch of reference to DOM elements, etc. Interesting. Yeah, Notification.get() seems like it would help you solve this. Though potentially the API should also have a function like Notification.close(DOMString tag). Seems like a common use case of wanting to close a notification when the user engages with a piece of UI, and it seems silly to have to instantiate a Notification instance through .get() to do so. The other reason we handle the close event is that gmail has this idea of a chat notification that the user hasn't seen yet - the chat frame has a visual highlight. But if the notification is dismissed by the user, we can clear this highlight, under the assumption that the user has seen this notification. This functionality may be somewhat broken on platforms that auto-close notifications though. Yeah, this is the case that Jake brought up. Though Tab pointed out that other chat systems generally does not treat close as an hint for user has read. Interesting to hear that gmail does. On what platforms do non-persistent notifications not close after a timeout? My test on mac and linux chrome just showed that notifications never close on those platforms. I guess I don't know enough about the ins and outs of osx notifications. But all my other osx apps remove notifications after a few seconds. But it is of course chrome's choice what UI to display. Chrome on OSX isn't using the native notification framework (at least, not on my laptop). In any case it sounds like gmail would not notify properly on platforms where notifications do dissappear after a few seconds, which seems problematic, no? I think that Chrome doesn't generate a close event in the case that the notification is hidden, but agreed, it's a problem. It's frankly one of the major flaws of the original spec that behavior like this isn't well specified, because it really prevents applications from doing anything particularly sophisticated around notification management, because you can't keep notifications on-screen if the notification platform wants to close them, and you can't easily differentiate between user-close and system-close. The thing to remember is that gmail's notification functionality was written back when Chrome was the only browser that supported notifications, and there were no system notification platforms (at least, none that were used by any UAs). So some of the behavior in Gmail only makes sense on platforms where Chrome's original notification
Re: [whatwg] Notifications and service workers
Apologies if I miss some subtleties in the preceding discussion - I've
scanned the thread, but I haven't been following closely.
On Fri, Sep 26, 2014 at 4:36 PM, Peter Beverloo bever...@google.com wrote:
Let me reply to a few points mentioned in this thread -- it's quite
overloaded :-).
I've also added Andrew, who might know some historical reasons for the
events. (Andrew: most of this is in context of persistent notifications.)
* Life-time of existing notifications.
Chrome currently treats Web Notifications as persistent ones. When the
page goes away, the notification stays. Interaction with the notification
is not going to trigger anything anymore. While I'm in favor of changing
this, we have to be very cautious to not break user expectations of
existing users of the Web Notification API, for example in calendar
applications.
I suspect it's OK to change this, especially since (for Chrome, at least)
most platforms are moving to a model where notifications don't stay on the
screen anyway (they move to a notification center). That said, I've never
really understood the interest in auto-closing notifications, since if a
web page wants to close its notifications, it's trivial to do so in an
onclose handler - I guess the issue might be notifications coming from a
worker, where the worker doesn't get notified that it's going away? Maybe
the right fix is that workers should get a close event also :)
In any case, agreed with Jonas that if we're going to build non-persistent
notifications, then perhaps they should have a fixed time limit (possibly
UA-adjustable) and not be tied explicitly to a source's lifetime.
* Dropping the close event.
I've been wondering myself whether it's valuable to support this. Like
Tab, I'm not aware of any messaging application actually using the close
event as an indication that the message has been read. There is the
dismiss all button on most platforms, which definitely does not imply
having read the message. It's actually an interesting privacy question as
well, for example, if a user dismisses a Facebook notification in their
notification center without actually starting the app, should the sender be
informed about them having at least looked at their phone?
Gmail tracks information internally about all open notifications so it
knows what chat window, email, etc to display when the user clicks on one.
It cleans up those data structures as notifications are closed, so if we
stop generating close events, then gmail will leak even more memory than it
currently does :)
Synchronizing closing of the notification on all the user's devices is an
interesting one, but opt-in would be sufficient for this.
Given the cost of starting up a Service Worker, I'm interested in
exploring opt-in. One potential optimization a UA could do is detect the
events bound on a Service Worker's global when it starts, and check whether
notificationclose is part of this for future invocations.
* Dropping the show event.
There is one scenario in which Chrome doesn't fire the show event, and
that's when no permission has been granted to show notifications (in which
case we fire the error event). One theoretical concern with this property
is that if we choose to support delayed notifications, it could be used to
set precise timers. Depending on how we're going to deal with
(asynchronous) errors for persistent notifications, I'm fine with dropping
this for them.
I'm not aware of any particular use cases here. Gmail isn't listening to
show events, AFAICT.
* Supporting non-persistent notifications in Service Workers.
I'd prefer not to, especially if we would auto-close the notifications.
There seems to be little point beyond indicating to the user that the
Service Worker is running, which feels more like a UA thing if they choose
to do so.
* Supporting non-persistent notifications in Shared and Dedicated Workers.
As long as we continue to support non-persistent notifications, I see no
reason not to do this. The globals of both kinds of workers have well
defined lifetimes, making the notifications as reliable as in-page ones,
most notably on desktop.
* Not using the constructor for persistent notifications.
There is one more argument to make in favor of creating a promise
somewhere, and that's consistency with other Service Worker based APIs. As
I understand it, both Web Push and Background Sync are planning to expose
their creation methods on the ServiceWorkerRegistration object. If we were
to do something analogous, it'd be:
navigator.serviceWorker.ready.then(function (registration) {
registration.createNotification('Title', { ... });
});
Instead of:
navigator.serviceWorker.ready.then(function (registration) {
new Notification('Title', { serviceWorker: registration });
});
I have no strong feelings here either, and think it's fine to continue
using the constructor with the serviceWorker property set. Both would still
Re: [whatwg] Notifications and service workers
That only works if 'data' is a structured-cloneable data structure. I mean, typically in a full-featured web app, you have a large, complex data structure and you typically want to keep references into that data structure - you can't typically just copy pieces out and expect to perform operations on them. On Mon, Sep 29, 2014 at 11:54 AM, Robert Bîndar robertbin...@gmail.com wrote: Sounds exactly like an use case of the 'data' attribute. 2014-09-29 12:23 GMT+03:00 Jonas Sicking jo...@sicking.cc: On Sun, Sep 28, 2014 at 11:15 PM, Andrew Wilson atwil...@google.com wrote: * Dropping the close event. I've been wondering myself whether it's valuable to support this. Like Tab, I'm not aware of any messaging application actually using the close event as an indication that the message has been read. There is the dismiss all button on most platforms, which definitely does not imply having read the message. It's actually an interesting privacy question as well, for example, if a user dismisses a Facebook notification in their notification center without actually starting the app, should the sender be informed about them having at least looked at their phone? Gmail tracks information internally about all open notifications so it knows what chat window, email, etc to display when the user clicks on one. It cleans up those data structures as notifications are closed, so if we stop generating close events, then gmail will leak even more memory than it currently does :) Could this be solved by using the 'data' attribute when creating a Notification? / Jonas
Re: [whatwg] Notifications and service workers
I'm sorry, I meant that you can only use the 'data' attribute, if the data you want to associate with the notification is structured-cloneable. Which precludes lots of interesting stuff, like objects with attached methods, memoized functions, etc. I'm aware that 'data' is structured-cloneable - I'm saying that's not sufficient for many uses. -atw On Mon, Sep 29, 2014 at 12:34 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Sep 29, 2014 at 3:10 AM, Andrew Wilson atwil...@google.com wrote: That only works if 'data' is a structured-cloneable data structure. Per spec it is yes. / Jonas
Re: [whatwg] Notifications and service workers
OK, looked back into the Gmail code (since it'd been a couple of years since I was really down in that notification code). There are two places where we listen for close events currently: 1) When closing an email notification - gmail keeps its own queue of pending notifications (so if several emails arrive at once, we don't display seven notifications simultaneously, but instead we display one at a time, cycling through them after 5-6 seconds). If the user closes a notification, then we clear out our queue of pending notifications, because the expectation is that the user doesn't want any more email notifications (the experience before we did that was really annoying). 2) When closing a chat notification, we tell the chat subsystem that the notification has gone away so that it can clear its reference to the Notification. The chat subsystem keeps a reference to the notification so it can close a chat notification if the user clicks on a chat frame, but this might no longer be necessary if we implement Notification.get(). Anyhow, our reference to the chat subsystem is a reference to an object and that object isn't structured-cloneable because it has a bunch of reference to DOM elements, etc. The other reason we handle the close event is that gmail has this idea of a chat notification that the user hasn't seen yet - the chat frame has a visual highlight. But if the notification is dismissed by the user, we can clear this highlight, under the assumption that the user has seen this notification. This functionality may be somewhat broken on platforms that auto-close notifications though. On Mon, Sep 29, 2014 at 2:15 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Sep 29, 2014 at 4:55 AM, Andrew Wilson atwil...@google.com wrote: On Mon, Sep 29, 2014 at 1:40 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Sep 29, 2014 at 4:35 AM, Andrew Wilson atwil...@google.com wrote: I'm sorry, I meant that you can only use the 'data' attribute, if the data you want to associate with the notification is structured-cloneable. Which precludes lots of interesting stuff, like objects with attached methods, memoized functions, etc. I'm aware that 'data' is structured-cloneable - I'm saying that's not sufficient for many uses. But if the data that you want to associate with the notification isn't structured clonable, how are you going to make that data survive a page reload? Keep in mind that for persistent notifications, the notification often outlives the page that created the notification. OK, I get it - we're talking about different models. I'm talking about the current Gmail use case, where I don't want notifications to live forever (in fact, I close them all when you close the main Gmail pane). I understand that for persistent notifications, the uses are different. And again, apologies if I missed the context and the idea was to only remove the close event for persistent notifications - it's the danger of dropping into the middle of a thread :) Hopefully the plan is to continue enabling web properties that want to go the Gmail route to continue doing so, and for those pages, I think a 'close' event is useful. I think we're talking about both. But I wanted to point out that the code flow you were talking about didn't seem to work for persistent notifications. I'd rather keep persistent and non-persistent notifications as similar as possible. Though as possible being key. I.e. I think it's ok for them to be different when that makes sense. I still don't understand the use case you are talking about though. Could you perhaps provide an example of the features that gmail is building and which needs these non-clonable data structures? / Jonas
Re: [whatwg] Notifications improvements
On Fri, Aug 8, 2014 at 2:48 PM, Peter Beverloo bever...@google.com wrote: Hi Andrew, On Wed, Aug 6, 2014 at 12:59 PM, Andrew Wilson atwil...@google.com wrote: On Wed, Aug 6, 2014 at 12:48 PM, Anne van Kesteren ann...@annevk.nl wrote: On Wed, Aug 6, 2014 at 10:08 AM, Andrew Wilson atwil...@google.com wrote: I understand your concern that is driving this proposal: you don't want to provide rich APIs that can't be well implemented on every platform, and thereby fragment the web platform. I just don't want to see us go down this path of adding these new notification types that are so limited in ability that people will just keep using general notifications anyway - I'd rather just stick with the existing API. Are you unenthusiastic about any of the proposed additions (what about those already added?) or is this more about the more complex features such as indication of progress? I'm (somewhat) unenthusiastic about the new semantic types, because I'm not sure they'd get enough uptake to be worth the effort to implement (note that this is just my personal opinion - I'm no longer as heavily involved in the notification work within Chromium, so Peter B's opinion carries much more weight than mine when it comes to determining what we'd implement). I find myself being in favor of the semantic types. The primary reason for this is that it allows us to provide a much more consistent user experience, especially on platforms where we don't control rendering of the notification, compared to HTML notifications. On Chrome for Android we want to provide for a consistent user experience, where notifications should be visually indistinguishable (aside from clarifying the origin) from those created by native apps. The proposed semantic types would get us there. Furthermore, support for HTML notifications will be much more difficult to implement across the board. Some mobile OSes, notably Firefox OS and iOS, wouldn't support this at all. Others, such as Android, theoretically could support it, but won't because it means creating an entire WebView -- causing very significant memory pressure on already resource constrained devices. To be clear, I'm not arguing for HTML notifications - as I said in my original post to this thread, HTML notifications were removed from the spec for various good reasons. But I think it's a mistake to just bake in canned notification types. What if a developer wants a progress bar with a cancel button? A progress bar with a timestamp? A list notification that contains an event with timestamp? Or some other different notification that doesn't specifically match one of your curated templates, but could easily be built if you gave him a lower-level set of primitives? Implementation wise, Chrome recently switched to rendering Notifications using a new message center implementation, which already supports rich data such as progress bars, timestamps, lists and buttons. On Android many of these features will come down to calling an extra method on the Java Notification.Builder. I am quite enthusiastic about adding support in the API around allowing users to interact with notifications after the parent page has closed, however. Having a new field timestamp that carries a particular point in time related to the message seems quite useful for instance and not very intrusive. Perhaps I'm not understanding how this would be used. What would such a notification look like for (say) a calendar event (Your 1PM meeting starts in 5 minutes) versus a countdown timer (In 73 seconds, your hard boiled egg will be done cooking)? Would we have to provide a format string so the UA knows where to inject the time remaining, or would it always have to be put at the end? Do we need to specify granularity of updates (i.e. if I have a stopwatch app, I probably want to update every second, but for a calendar app, updating every 5 minutes is probably sufficient, until we get down to the last 5 minutes)? I would argue that this is a feature that should be defined by the UA or platform. I'm not sure whether using a counting notification is the right way to implement a count-down -- I would expect normal, foreground UI displaying a counter, and a notification if that UI was moved to the background and the counter expired. The timestamp doesn't necessarily need to be in the future either. At least for me, a calendar notification that is constantly updating its countdown every minute but has no snooze functionality is actually a mis-feature, because it's distracting. The notification wouldn't visually re-announce itself on every update. Again, I don't want to be overly negative about this - maybe there are use cases like list notifications where the new API would be really useful, but as soon as I start thinking about more complex display scenarios, I immediately want to start having more control over the formatting of the text
Re: [whatwg] Notifications improvements
On Tue, Aug 5, 2014 at 11:44 PM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Jul 11, 2014 at 12:57 AM, Andrew Wilson atwil...@google.com wrote: On Fri, Jul 11, 2014 at 2:30 AM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Jul 10, 2014 at 1:04 AM, Andrew Wilson atwil...@google.com wrote: On Thu, Jul 10, 2014 at 5:44 AM, Jonas Sicking jo...@sicking.cc wrote: Hi All, We've on and off discussed various features added to notifications. It'd be great to move forward with some of these improvements. I think the most low hanging fruit would be to add the following as data that can be displayed in a notification: * Progress bar * Lists of title/body pairs * Date (for things like event will happen in 10 minutes) So, many of these cases were what the original HTMLNotification API was supposed to address. This was eventually shot down for a number of (good) reasons: too much complexity on the implementation side, and more importantly, the fact that these more complex notifications aren't compatible with various platform notification frameworks and so this would be a source of platform/UA incompatibility. It's not clear to me that re-adding support for these use cases one at a time as distinct notification types is really a good path forward, or that it's necessarily low-hanging fruit unless we have a good idea for how to deal with the platform-compatibility issue. Actually, given that the UA has a very high degree of semantic understanding of these properties, I think it should be doable to implement on top of all existing platform notification systems. In all of the above cases you can come up with a reasonable string to add to the end to render the content. This is what pages have to do right now anyway. I had assumed from the examples you gave that the goal of these new notification types was to have dynamically updating notifications (progress bar, timestamps that update with a countdown to an event, etc), which it wasn't clear could be cleanly implemented across all platform notification systems without significant jank. For dates the idea is definitely to enable the notifications to be dynamically updated by the platform. For progress bars my expectation was not that it would be automatically updated. Instead it would be updated using the exact same mechanism that we have for notifications today, i.e. using the tag mechanism. So the jank would be the same whether OS notifications supports rendering progress bars or if they are just able to render text. OK, so the idea is that you'd display a new progress bar notification with the same tag as an existing progress bar notification, and the browser would see that they are the same and just update the progress bar? Or would we pull down and re-display a new progress bar? If we're just updating the existing progress bar, then I guess for compatibility, the old notification would still get the normal events as if it had been replaced? For lists the idea is not to update them any more or less than for plain text content. Just like with text content pages will likely want to update them occasionally, but that's not a core aspect of the feature. The intent for things like progress bars would be that they have greater visibility than your typical 5 seconds and then hidden email notification, which also may not be doable with many notification frameworks. This is a quite interesting idea. I hadn't thought of that. I'm slightly dubious about adding new semantic notification types (I'd still rather give app developers the tools to build their own richer notifications instead of giving them a canned set), but it's definitely worth discussing further. I'm not sure I understand this argument. If you are concerned about having poor fallback on platforms that can't render the UI components discussed above, then surely that concern is even greater if we enable pages to build their own rich notifications? I have a couple of concerns: 1) Anything more than plain text + icon notifications won't map well to native notification platforms. If we're going to build support in the API for something that isn't well supported by native notification platforms, then we should get the most bang for our buck and build something that's flexible enough to meet many use cases. 2) I don't feel like the limitations with the current API are addressed by adding 3-4 pre-canned notification types. I feel like the current notification API addresses a broad swath of use cases, and there's a long tail of unaddressed cases that we can't serve well with any pre-canned notification types - if we want to try to address those long-tail cases, then I'd rather have us address them with a flexible API that gives developers more control over the notification content rather than cherry-picking individual use cases. I understand your concern that is driving this proposal: you don't want to provide
Re: [whatwg] Notifications improvements
On Wed, Aug 6, 2014 at 12:48 PM, Anne van Kesteren ann...@annevk.nl wrote: On Wed, Aug 6, 2014 at 10:08 AM, Andrew Wilson atwil...@google.com wrote: I understand your concern that is driving this proposal: you don't want to provide rich APIs that can't be well implemented on every platform, and thereby fragment the web platform. I just don't want to see us go down this path of adding these new notification types that are so limited in ability that people will just keep using general notifications anyway - I'd rather just stick with the existing API. Are you unenthusiastic about any of the proposed additions (what about those already added?) or is this more about the more complex features such as indication of progress? I'm (somewhat) unenthusiastic about the new semantic types, because I'm not sure they'd get enough uptake to be worth the effort to implement (note that this is just my personal opinion - I'm no longer as heavily involved in the notification work within Chromium, so Peter B's opinion carries much more weight than mine when it comes to determining what we'd implement). I am quite enthusiastic about adding support in the API around allowing users to interact with notifications after the parent page has closed, however. Having a new field timestamp that carries a particular point in time related to the message seems quite useful for instance and not very intrusive. Perhaps I'm not understanding how this would be used. What would such a notification look like for (say) a calendar event (Your 1PM meeting starts in 5 minutes) versus a countdown timer (In 73 seconds, your hard boiled egg will be done cooking)? Would we have to provide a format string so the UA knows where to inject the time remaining, or would it always have to be put at the end? Do we need to specify granularity of updates (i.e. if I have a stopwatch app, I probably want to update every second, but for a calendar app, updating every 5 minutes is probably sufficient, until we get down to the last 5 minutes)? At least for me, a calendar notification that is constantly updating its countdown every minute but has no snooze functionality is actually a mis-feature, because it's distracting. Again, I don't want to be overly negative about this - maybe there are use cases like list notifications where the new API would be really useful, but as soon as I start thinking about more complex display scenarios, I immediately want to start having more control over the formatting of the text being displayed, and i wouldn't get that with this proposal.
Re: [whatwg] Notifications improvements
On Fri, Jul 11, 2014 at 2:30 AM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Jul 10, 2014 at 1:04 AM, Andrew Wilson atwil...@google.com wrote: On Thu, Jul 10, 2014 at 5:44 AM, Jonas Sicking jo...@sicking.cc wrote: Hi All, We've on and off discussed various features added to notifications. It'd be great to move forward with some of these improvements. I think the most low hanging fruit would be to add the following as data that can be displayed in a notification: * Progress bar * Lists of title/body pairs * Date (for things like event will happen in 10 minutes) So, many of these cases were what the original HTMLNotification API was supposed to address. This was eventually shot down for a number of (good) reasons: too much complexity on the implementation side, and more importantly, the fact that these more complex notifications aren't compatible with various platform notification frameworks and so this would be a source of platform/UA incompatibility. It's not clear to me that re-adding support for these use cases one at a time as distinct notification types is really a good path forward, or that it's necessarily low-hanging fruit unless we have a good idea for how to deal with the platform-compatibility issue. Actually, given that the UA has a very high degree of semantic understanding of these properties, I think it should be doable to implement on top of all existing platform notification systems. In all of the above cases you can come up with a reasonable string to add to the end to render the content. This is what pages have to do right now anyway. I had assumed from the examples you gave that the goal of these new notification types was to have dynamically updating notifications (progress bar, timestamps that update with a countdown to an event, etc), which it wasn't clear could be cleanly implemented across all platform notification systems without significant jank. The intent for things like progress bars would be that they have greater visibility than your typical 5 seconds and then hidden email notification, which also may not be doable with many notification frameworks. Anyhow, I'm very supportive of any efforts to deal with the whole notifications-for-closed-windows issue. I'm slightly dubious about adding new semantic notification types (I'd still rather give app developers the tools to build their own richer notifications instead of giving them a canned set), but it's definitely worth discussing further. This is different from generic HTML-text conversion I think, since HTML is very rich and there's a bigger risk of generating unuseful text. One thing that we *could* do is to add API for detecting which of these properties will be rendered natively, and which ones will use some form of UA-provided fallback. This way an advanced page could compensate for lacking capabilities in more advanced ways, whereas less advanced authors would get reasonably good automatic fallback. Second, we really need to figure out the story around handling user clicking notifications after the user has closed the original page. At the very least we need the ability to send a message to a ServiceWorker when the user clicks a notification. This way the SW can decide if UI should be shown, and if so if an existing window can be reused or not. SW integration will require some other changes too. We need to change the GC behavior. Right now it seems like if a Notification object is created, but no event listeners are attached, because the page is expecting to use the SW event to listen for clicks, the notification won't be kept alive and so the SW can't get to any of its data. We also need to keep state on the Notification object if the user has clicked the notification or not. We should also consider enabling passing a URL to the Notification constructor which is opened when the user clicks the notification. Probably this should attempt to reuse an existing tab with said URL if one is open. Third, we should look at enabling minimal user input through the Notification. It's very common for notifications to support having one or more buttons that the user can click. It would also be good to enable putting a simple text-input in the notification. This area is definitely more complex though so happy to put this last. I think if we want to address the more complex data type use cases above, then this needs to be part of that proposal - for example, I'm not sure how valuable having something like a Date/Event notification would be without a Snooze button. I'm not sure that's true. Notifying that an event is going to happen in 10 minutes would still be useful even if the user can't snooze that notification. That's a fair point - I guess I was thinking that these new notification types were a natural fit for canned new buttons/input elements (i.e. snooze for events
Re: [whatwg] Notifications improvements
On Thu, Jul 10, 2014 at 5:44 AM, Jonas Sicking jo...@sicking.cc wrote: Hi All, We've on and off discussed various features added to notifications. It'd be great to move forward with some of these improvements. I think the most low hanging fruit would be to add the following as data that can be displayed in a notification: * Progress bar * Lists of title/body pairs * Date (for things like event will happen in 10 minutes) So, many of these cases were what the original HTMLNotification API was supposed to address. This was eventually shot down for a number of (good) reasons: too much complexity on the implementation side, and more importantly, the fact that these more complex notifications aren't compatible with various platform notification frameworks and so this would be a source of platform/UA incompatibility. It's not clear to me that re-adding support for these use cases one at a time as distinct notification types is really a good path forward, or that it's necessarily low-hanging fruit unless we have a good idea for how to deal with the platform-compatibility issue. Second, we really need to figure out the story around handling user clicking notifications after the user has closed the original page. At the very least we need the ability to send a message to a ServiceWorker when the user clicks a notification. This way the SW can decide if UI should be shown, and if so if an existing window can be reused or not. SW integration will require some other changes too. We need to change the GC behavior. Right now it seems like if a Notification object is created, but no event listeners are attached, because the page is expecting to use the SW event to listen for clicks, the notification won't be kept alive and so the SW can't get to any of its data. We also need to keep state on the Notification object if the user has clicked the notification or not. We should also consider enabling passing a URL to the Notification constructor which is opened when the user clicks the notification. Probably this should attempt to reuse an existing tab with said URL if one is open. Third, we should look at enabling minimal user input through the Notification. It's very common for notifications to support having one or more buttons that the user can click. It would also be good to enable putting a simple text-input in the notification. This area is definitely more complex though so happy to put this last. I think if we want to address the more complex data type use cases above, then this needs to be part of that proposal - for example, I'm not sure how valuable having something like a Date/Event notification would be without a Snooze button.
Re: [whatwg] [notifications][editorial] tweaking the Activating a notification window.focus() note
The problem here is that the platform's notification design has no way to understand what the application wants to happen when the user clicks on a notification. As a great example - Gmail uses desktop notifications to notify the user about chat events and new emails. When the user clicks on a chat notification, gmail uses window.focus() to focus itself so the user can view the chat (which is displayed in the main gmail window via a div overlay). When the user clicks on an email notification, we don't want to bring up that email in the main gmail window because the user may be in the middle of some other operation (like composing an email) - in fact, we don't want to focus the gmail tab at all. Instead we pop up that email in a separate popup window. In that case, having the UA auto-focus the tab is a mistake. I'm OK if you somehow want to make auto-focus a default property of the notification and have the app determine a-priori whether a given notification should trigger auto-focus at the time the notification is created, but it seems less flexible than the current behavior that Chrome has, which is that notifications don't auto-focus, and that applications have full control over what they want to happen when a click occurs. I suppose you can make the argument that auto-focus is so overwhelmingly common that we should just make it the default as a developer convenience - do you have any data to back up this assertion? In any case, I'm OK with the status quo, which is that UAs either auto-focus (if they want to force consistent click-on-notification functionality regardless of app intent) or they should support window.focus(). Actively prohibiting window.focus() seems like a bad step. -atw On Thu, Apr 17, 2014 at 1:45 AM, Glenn Maynard gl...@zewt.org wrote: On Wed, Apr 16, 2014 at 6:10 PM, Edward O'Connor eocon...@apple.com wrote: Hi, In §4.6 Activating a notification, there's a note that currently reads User agents are strongly encouraged to make window.focus() work from within the event listener for the event named click as a means of focusing the browsing context related to the notification. This note assumes that the UA doesn't automatically focus the browsing context when a notification is activated. (Safari on OS X is one example of a UA which does this.) The note should be adjusted so that readers understand that calling window.focus() may not be necessary on some combinations of UA and system notification service. Rather, pages should never be allowed to window.focus() when a notification is activated. If the platform's notification design wants that to happen, it's the platform's job to do that, and pages shouldn't all be required to call window.focus() to make this happen consistently. (If for some reason the platform doesn't want that to happen, the page shouldn't be able to override that, either.) If there are notifications that don't want to focus a page when activated, that should be a setting on the notification. -- Glenn Maynard
Re: [whatwg] onclose events for MessagePort
On Sat, Dec 7, 2013 at 2:22 AM, Ian Hickson i...@hixie.ch wrote: On Fri, 11 Oct 2013, Andrew Wilson wrote: Interesting. Section 5.3.1 of the MessagePort spec (BTW, I really recommend using the WHATWG HTML spec rather than the MessagePort spec, especially the version on the TR/ page. The W3C version on the TR/ page is about 18 months old, which in this space is _ancient_.) Good to know. I'll look there from now on. states that the ports should only be GC'd if there are no references to either side and if there are no pending messages for either port (basically, meaning that neither port is reachable), but this channeldropped API provides a new way of access. In what sense? Here's my point - let's say you have two UA implementations, one that GCs aggressively when two ports are not reachable and are idle, and one that never GCs entangled ports. Two documents (A and B) are connected via entangled ports, but the ports themselves are no longer reachable. However, document A has registered a channeldropped handler on its port. In the aggressive UA implementation, the ports have been GC'd. Now, document B crashes. In this case, only one UA gets a channeldropped notification, which seems like a source of incompatibilities - if you do something in this error case, you're basically exposing GC behavior. You can argue that this is OK since document B crashes is something that can't happen on-demand (although I'd disagree in the case that an OOM can cause the document to crash) - it's a dangerous precedent and I'm not sure this new |error| event is useful enough to motivate this change (especially since you're not generating this event in the case of things like page navigation or user closing the document). A page could already detect crashed documents by polling if it wanted. If the port is GC'ed before the other side is destroyed, then you miss the message, but so what? If the port is not GC'ed before the other side is destroyed, but could have been, then it exposes GC behaviour, but that seems like a very minor concern in this case, as noted in my response to Jonas above. I think we disagree about whether exposing GC behavior is a very minor concern. But I don't want to be too dogmatic about it if the consensus is that being able to detect crashed port owners without the latency/overhead of polling is incredibly valuable. If the port is not GC'ed before the other side is destroyed, and could not have been, then it's the same as if you had a reference, so it seems like a non-issue. On Fri, 11 Oct 2013, Anne van Kesteren wrote: On Fri, Oct 11, 2013 at 9:38 AM, Andrew Wilson atwil...@google.com wrote: *or while there exists an event listener on either port for the channeldropped event.* Once you do that you basically rely on the developer to handle GC and you'll end up with memory leaks instead. Yeah. On Fri, 11 Oct 2013, Andrew Wilson wrote: Agreed. I'm just pointing out that language/behavior like this is basically required if you're going to support a channeldropped event that can be spontaneously generated even on ports that have no live external references. Presumably the only case that this can matter is if the event is dispatched. If it gets GC'ed before then, then it didn't matter. I've made sure the spec says that while the event (any event, actually) is queued, the object can't go away. On Fri, 18 Oct 2013, Jonas Sicking wrote: I thought the proposal was to not fire channeldropped when the channel is GCed. Thus allowing channels with both message and channeldropped event listeners on either side to still be GCed. Is that correct? It's what the spec says. If so, that exposes GC behavior. If at some point both pages that hold on to an endpoint of a message channel drop their references the channel can get GCed. If it is GCed no events fire. However if the page holding on to either port crashes before the GC happens, then the channeldropped event is fired on the other port. Hence the timing of the GC affects whether channeldropped is fired. Hence GC behavior is exposed. The GC behaviour is exposed _if one of the sides crashes_. As noted above, that's a case where even if we do expose GC behaviour, we're not likely to really constrain ourselves. On Mon, 21 Oct 2013, Andrew Wilson wrote: Makes sense, although I'm a bit fuzzy about the rules around MessagePorts and window navigation (for example, if I navigate a window, is all content in that window now shutdown/discarded, even though I could in theory get back to the window by immediately clicking back)? No, nothing is discarded, because of, as you say, the bfcache. On Mon, 21 Oct 2013, Ehsan Akhgari wrote: I think we may need to mandate that a channeldropped eventis fired when you register a handler on a port with the other side having already crashed. That would be very weird behaviour for an event
Re: [whatwg] Implementation question about Notifications
On Mon, Nov 18, 2013 at 1:01 PM, Anne van Kesteren ann...@annevk.nl wrote:
On Thu, Nov 14, 2013 at 10:45 PM, Andrew Wilson atwil...@google.com
wrote:
var n1 = new Notification(title);
var n2 = new Notification(title, {icon: invalid_icon_url});
var n3 = new Notification(title, {icon: http://non-existent-icon.com
});
I think that it should be:
n1.dir == auto
n1.lang ==
n1.body === undefined
n1.tag === undefined
n1.icon === undefined
Do you agree? Or should it map to something different?
If we want to treat empty string different from missing for
body/tag/icon we could make them nullable. Not sure that's worth it
though. Shall I clarify the specification that they should be the
empty string as well?
I think having them return the empty string would be fine (and would,
coincidentally, match our current implementation in Chrome).
My one concern is that according to the current spec, is a valid |tag|
and so Notification(title, { tag: }) is different than
Notification(title) because the latter has no tag, while the former has an
empty tag (and so can be fetched via Notification.get())
Since these two notifications are different, I'd say that the |tag|
attribute should reflect that difference:
var n1 = Notification(title, {tag: })
assert(n1.tag == );
var n2 = Notification(title);
assert(n2.tag === undefined);
Either that, or we should update the spec to treat empty strings the same
as undefined in NotificationOptions.
What about n2.icon and n3.icon - what should they read? I'm curious,
given
that section 4.9.1 reads:
Well, invalid_icon_url is not an invalid URL, but if you had used
e.g. http://test:test/; it would have to return the same as n1.
n3.icon should return http://non-existent-icon.com/; per
http://notifications.spec.whatwg.org/#dom-notification-icon
Yes, makes sense, taking into account my inability to form an ill-formed
URL :)
I'm not certain if set notification's icon refers to just the visible
image within the notification, or to the *Notification.icon* attribute
itself - I'm assuming the former (since we don't want to wait for a
network
fetch before setting the Notification.icon attribute) so perhaps we
should
rephrase this as set notification's icon image to the decoded resource?
Done.
--
http://annevankesteren.nl/
[whatwg] Implementation question about Notifications
The notification spec (http://notifications.spec.whatwg.org/#api) says that
the Notification object has the following readonly attributes: title, dir,
lang, body, tag, icon.
Let's say I make the following calls:
var n1 = new Notification(title);
var n2 = new Notification(title, {icon: invalid_icon_url});
var n3 = new Notification(title, {icon: http://non-existent-icon.com});
What should:
n1.dir
n1.lang
n1.body
n1.tag
n1.icon
resolve to? I think that it should be:
n1.dir == auto
n1.lang ==
n1.body === undefined
n1.tag === undefined
n1.icon === undefined
Do you agree? Or should it map to something different?
What about n2.icon and n3.icon - what should they read? I'm curious, given
that section 4.9.1 reads:
If the notification platform supports icons, notification's icon URL is set
and has not yet been fetched, fetch it and wait for the resource to be
fully downloaded.
Once fetching has finished and the image format is supported, set
notification's icon to the decoded resource. (Otherwise notification has no
icon.)
I'm not certain if set notification's icon refers to just the visible
image within the notification, or to the *Notification.icon* attribute
itself - I'm assuming the former (since we don't want to wait for a network
fetch before setting the Notification.icon attribute) so perhaps we should
rephrase this as set notification's icon image to the decoded resource?
Also, step 8 in the constructor description says:
If options's icon is present, parse icon using the API base URL specified
by the entry settings object, and if that does not return failure, set
notification's icon URL to the return value. (Otherwise icon URL is not
set.)
...so it seems pretty clear that Notification.icon should be undefined if
the passed NotificationOptions.icon attribute is unparseable. Agreed?
-atw
Re: [whatwg] The behaviour of Notification.requestPermission() in Workers
Agreed with Anne - I don't see the value in exposing a non-functional requestPermission(). Certainly on Chrome (which only allows invoking requestPermission in the context of user input to prevent abuse) we would be unlikely to support requestPermission() from workers, at least unless we decide to change that behavior. On Thu, Oct 24, 2013 at 11:05 AM, Anne van Kesteren ann...@annevk.nlwrote: On Thu, Oct 24, 2013 at 2:19 AM, Nikhil Marathe nsm.nik...@gmail.com wrote: The easiest solution for implementors and authors is to make the requestPermission() call in a HTML page before spawning a worker or registering a service worker. Inside the Worker scope we then have two options: 1) requestPermission() is not defined. 2) requestPermission() does not ask the user, but uses the permission associated with that origin, or denied. I believe option 2 is better in terms of having a complete API. Feedback is appreciated about what the right approach should be. Given that Notificaiton.permission exists, I'm not sure what the additional value of Notification.requestPermission() in a worker context would be. -- http://annevankesteren.nl/
Re: [whatwg] onclose events for MessagePort
On Sat, Oct 19, 2013 at 2:26 AM, Jonas Sicking jo...@sicking.cc wrote: What I think might work is to say that as long as a channeldropped event listener is registered with a port, that is equivalent to holding a strong reference to the port. I.e. that prevents the channel from being GCed. Even if no references are held to either port. In other words, we'd give up 3, but only when 2 is actively used. Agreed - this was my proposal here: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-October/041068.html in response to your earlier email. We would also need to define that the channeldropped event is never fired on a port if that port's *owning* window has been navigated away from. Otherwise we could *never* GC a channel between two windows that has channeldropped registered on either side. Makes sense, although I'm a bit fuzzy about the rules around MessagePorts and window navigation (for example, if I navigate a window, is all content in that window now shutdown/discarded, even though I could in theory get back to the window by immediately clicking back)? So the expectation is that a caller should only register a channeldropped event if it's actively waiting for a response from that thread. It's not something that you should register when creating the port and then never unregister. Having a channeldropped event listener registered can cause a whole worker thread to be kept alive longer than it otherwise would. How does this work - imagine that I have a reference to a MessagePort, but I'm not actively waiting for any response on the port so I don't have a channeldropped event listener. Now, the remote side of the port crashes. I send a message on the port and add a channeldropped event handler - are you saying that adding a channeldropped event handler should trigger a channeldropped event if the other side has already crashed? If not, then how do I find out that the channel has been dropped if I don't keep the event handler registered all the time?
Re: [whatwg] onclose events for MessagePort
On Thu, Oct 10, 2013 at 11:52 PM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Oct 10, 2013 at 8:26 AM, Ehsan Akhgari eh...@mozilla.com wrote: On Thu, Oct 10, 2013 at 2:58 AM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Oct 9, 2013 at 3:06 PM, Ehsan Akhgari eh...@mozilla.com wrote: OK, so I gave this some thought and I and Olli managed to convince each other that finding a solution to the problem of dispatching a generic onclose event is impossible since there is no deterministic point in time before a worker is GCed when we know that it will be GCed soon. So with that behind us, how about we add an explicit event to be fired when the other side of a message channel gets destroyed in a catastrophic way which is not observable from the web content code running on that side, such as a process crash for example? The basic idea behind why this more restricted proposal is useful is that barring the catastrophic failure case, applications can detect the other cases why further communication may be impossible (such as navigating away from the page) themselves and notify the other side of the channel as desired -- it is only the catastrophic termination case which is not detectable from content script. How about we add another event named channeldropped (pending bikeshedding) which is fired on a message port if the owner global context of its entangled port is terminated in a catastrophic way? Needless to say, the event will be queued asynchronously with the termination of the other side, and it will not be affected by garbage collection. I could see the GC case not being solvable. But is there a reason that we couldn't also fire the event if the other side is forcefully terminated through a navigation or a Worker.terminate() call? The reason I did not extend this to navigation and Worker.terminate() is that at least in theory the authors should be able to detect those in their application and use postMessage() to communicate that information if desired (assuming that you can handle window.onunload and have control over the code calling terminate(), respectively.) Although perhaps my argument is a bit weaker about terminate() than navigation. Do you see a good reason why we should not leave those cases to authors? While technically possible for a webpage to handle ports that were passed to a worker and send a signal before the worker is terminated, it is really hard. First off it means that you have to create a separate MessageChannel just for the close-signal. You can't get the worker to to send the message without first finishing both the currently running task, and also processing all the tasks on the workers task queue. This would defeat the whole purpose of terminate(). So you need to keep a separate channel specifically to send the close message. Second, you need to track all the ports that are own by a specific worker so that you know which channels to send a close message for. Third, since the close message comes from a separate channel than other messages, it means that you have to deal with races. When you get a message from the separate channel that the main channel is dying, there might still be message in the pipe for the main channel. But there is no way to know when you got the last one. Timeouts are probably the only way, and that's obviously racy/slow. In short: The pain! It is burning! For navigation things are better since the caller can always use an onpagehide/onunload send a signal saying that the port is going away. It occurs to me that all of the proposals here does expose some amount of GC behavior. Even a channeldropped message which is sent only when the other side crashes exposes GC behavior. If GC happens to run before the crash and then collect the MessageChannel ports, then no channel exists at the time of crash, and thus no event is sent. However if the GC runs later, or if it doesn't successfully collect the MessageChannel ports, then the channeldropped event does fire. Interesting. Section 5.3.1 of the MessagePort spec states that the ports should only be GC'd if there are no references to either side and if there are no pending messages for either port (basically, meaning that neither port is reachable), but this channeldropped API provides a new way of access. So we'd need to update this part of the spec: *Furthermore, a MessagePort http://www.w3.org/TR/webmessaging/#messageport object must not be garbage collected while there exists a message in a task queue that is to be dispatched on that MessagePorthttp://www.w3.org/TR/webmessaging/#messageport object, or while the MessagePort http://www.w3.org/TR/webmessaging/#messageport object's port message queuehttp://www.w3.org/TR/webmessaging/#port-message-queue is open and there exists a messagehttp://www.w3.org/TR/webmessaging/#event-message event in
Re: [whatwg] onclose events for MessagePort
On Fri, Oct 11, 2013 at 10:18 AM, Anne van Kesteren ann...@annevk.nlwrote: On Fri, Oct 11, 2013 at 9:38 AM, Andrew Wilson atwil...@google.com wrote: *or while there exists an event listener on either port for the channeldropped event.* Once you do that you basically rely on the developer to handle GC and you'll end up with memory leaks instead. Agreed. I'm just pointing out that language/behavior like this is basically required if you're going to support a channeldropped event that can be spontaneously generated even on ports that have no live external references. To ameliorate this, you could say that the ports are only kept alive in the case that they have different owners (if I create a port and keep both ends with the same owner, then you'll never need to generate a channeldropped event and you can freely free them whenever there are no active references/pending events). As a data point/implementation note: Chrome already leaks ports whose entangled endpoints live in separate processes. It's just too hard to do the cross-process GC required to guarantee that both sides are unreachable. That's one reason why the spec states that it's best practice to explicitly close MessagePorts: Authors are strongly encouraged to explicitly close MessagePorthttp://www.w3.org/TR/webmessaging/#messageport objects to disentangle them, so that their resources can be recollected. Creating many MessagePort http://www.w3.org/TR/webmessaging/#messageport objects and discarding them without closing them can lead to high memory usage.
Re: [whatwg] onclose events for MessagePort
On Thu, Oct 10, 2013 at 8:58 AM, Jonas Sicking jo...@sicking.cc wrote: I could see the GC case not being solvable. But is there a reason that we couldn't also fire the event if the other side is forcefully terminated through a navigation or a Worker.terminate() call? I still have the concerns I expressed earlier about figuring out who the owner is of the port in the case where you've passed a reference around to multiple contexts. What does other side is forcefully terminated mean in the case where you may have multiple iframes with references to the same port? i.e. if my iframe does this: channel = new MessageChannel(); window.parent.port = channel.port1; sharedWorker.port.postMessage(port, [channel.port2]); window.location.href = some other url What happens? Does the sharedWorker get channeldropped on it's cloned port? I suspect this would be confusing to developers, who might otherwise expect that merely handing a reference to port to its same-origin parent would be sufficient to keep it alive.
Re: [whatwg] Possible bug in the way the spec about worker GC behavior
Can you be more specific about what in the spec is incorrect? I guess you're saying that Gecko shuts down the worker as soon as the parent document is no longer active (when the worker transitions to suspendable), so the worker is generally shutdown before the document is discarded? I think that behavior is a reasonable interpretation of the spec, and I don't think the language you cite implies otherwise - did you want to suggest an alternate wording that is clearer? I think implicit in the quote you described is that it only applies to workers that are still running, not to workers that have previously been shutdown. On Thu, Oct 10, 2013 at 12:12 AM, Ehsan Akhgari eh...@mozilla.com wrote: Right now the spec says[1] Whenever a Document object is discarded, it must be removed from the list of the worker's Documents of each worker whose list contains that Document.. If I'm reading this correctly, this implies that the worker object should be alive by the time that the document gets discarded, which is not what Gecko implements. Should this be fixed in the spec? [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html#the-worker%27s-lifetime Cheers, -- Ehsan http://ehsanakhgari.org/
Re: [whatwg] onclose events for MessagePort
On Thu, Oct 10, 2013 at 5:20 PM, Ehsan Akhgari eh...@mozilla.com wrote: Why would they expect that? Storing a reference to a port object on a parent doesn't change the owner of the port. (I agree that this can be a bit confusing if authors are not familiar with MessagePorts, but this is part of the semantics of the ports as currently specified, and I don't think the channeldropped event proposal changes the amount of confusion here. Chrome, at the very least, doesn't do this currently (doesn't disentangle the port when the owner is navigated) and I think it would surprise developers that a reference to a port is insufficient to keep it alive (and that you have to explicitly window.postMessage() that port to a window/iframe to hand off ownership instead of doing it through Javascript). However, I don't feel that strongly about this - it's a reasonable (and, perhaps, even technically correct) interpretation of the spec ; I just wanted to point out that this entails a change in the current behavior, at least in some UAs. On Thu, Oct 10, 2013 at 5:43 PM, David Barrett-Kahn d...@google.com wrote: Why is revealing when garbage collection happens such a terrible thing anyway? Java does it... Because it's a source of cross-browser incompatibility since the GC behavior of different user agents differs greatly. In fact, there's no requirement in any spec that a browser ever do GC. As an example, there are cases in Chrome currently where we explicitly leak MessagePorts because it's too difficult to determine reachability of entangled ports with JS VMs running across multiple processes, so apps that were expecting onchanneldropped events based on GC would break in Chrome in these cases. I recognize that there's value in tracking connected status - I'm just saying we need to be careful not to tie it to something unreliable like GC. Tying it to something else (like when the owning document/worker is discarded, or the associated process shuts down/crashes) is more deterministic.
Re: [whatwg] Possible bug in the way the spec about worker GC behavior
On Thu, Oct 10, 2013 at 5:06 PM, Ehsan Akhgari eh...@mozilla.com wrote: On Thu, Oct 10, 2013 at 7:58 AM, Andrew Wilson atwil...@google.comwrote: Can you be more specific about what in the spec is incorrect? I guess you're saying that Gecko shuts down the worker as soon as the parent document is no longer active (when the worker transitions to suspendable), so the worker is generally shutdown before the document is discarded? It's even worse than that, we GC the worker object if we can prove that it will not have any outstanding work to do in the future. I suspect that would break in the case of SharedWorkers. If I have a document that creates a shared worker, throws away the reference to the worker, then later that document creates a new SharedWorker object with the same URL, I should get *the same instance of the SharedWorker*, not a new instance. So closing down shared workers just because the owning documents don't currently have an active reference is bad, because it exposes GC specifics. Agreed that the worker lifetime language is complex, but it's complex because it needs to correctly and precisely specify behavior in cases like this. But your described behavior would probably be OK in the case of dedicated workers (where OK = has no visible behavioral difference from a spec-compliant implementation). I think that behavior is a reasonable interpretation of the spec, and I don't think the language you cite implies otherwise - did you want to suggest an alternate wording that is clearer? I think implicit in the quote you described is that it only applies to workers that are still running, not to workers that have previously been shutdown. Well, removing a document from the worker's list of documents to me implies that the worker object is not GCed, which implies that UAs cannot GC worker objects until the document is discarded. This is a bit tied into the worker lifetime language in the spec, so I don't think that a simple rewording fixes this, and honestly the worker lifetime prose in the spec is very difficult to understand. But I'm more interested to know whether I'm just reading too much into that sentence, or if this is actually what the spec means to say first. Again, I think that language is intended to refer only to workers that have not yet been shutdown. Once a worker has been shutdown, it no longer exists from the standpoint of the spec, so Whenever a Document object is discarded, it must be removed from the list of the worker's Documents of each worker whose list contains that Document inherently does not include workers that are shut down, because they no longer have a document list. Cheers, -- Ehsan http://ehsanakhgari.org/ On Thu, Oct 10, 2013 at 12:12 AM, Ehsan Akhgari eh...@mozilla.comwrote: Right now the spec says[1] Whenever a Document object is discarded, it must be removed from the list of the worker's Documents of each worker whose list contains that Document.. If I'm reading this correctly, this implies that the worker object should be alive by the time that the document gets discarded, which is not what Gecko implements. Should this be fixed in the spec? [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html#the-worker%27s-lifetime Cheers, -- Ehsan http://ehsanakhgari.org/
Re: [whatwg] onclose events for MessagePort
On Tue, Oct 1, 2013 at 7:01 PM, Olli Pettay olli.pet...@helsinki.fi wrote: I don't understand what the lifetime of MessagePorts to the lifetime of their owner document means in case of workers. And we sure want to delete MessagePort objects if nothing from JS side is keeping it, or the port it is connected to alive. Definitely no, in the former case (nothing on JS side is keeping it) - we definitely shouldn't fire a close event in that case since it exposes GC. I think that it's pretty clear what the owner is in the case of workers - the worker itself, which has a defined lifetime that is not necessarily tied to the lifetime of any specific document. I don't have any objections to adding some kind of close event to detect cases where an owner goes away, but I agree we need to be careful about what constitutes an owner and when precisely ownership is transferred, in the cases like: a) iframe creates a MessageChannel, posts port1 off to some SharedWorker, then hands a reference to port2 off to a bunch of other iframes, or popup windows, or whatever, then closes itself. At what point does a close event get generated on port1? It seems like we have to fire the onclose after the last window/iframe is destroyed, and it seems tricky to precisely track when a window becomes a co-owner of a port (since we don't want to expose GC specifics, we can't use reference chains to determine this). b) iframe creates a port, posts it to another port's queue, then posts that port to another window, we need to make sure we also transfer ownership of all of the nested ports that are sitting in the various nested port queues. I think the existing port cloning specification already handles this ownership transfer, but it's worth keeping in mind as it further complicates the implementation. -Olli [1] https://www.w3.org/Bugs/**Public/show_bug.cgi?id=23327https://www.w3.org/Bugs/Public/show_bug.cgi?id=23327 Thanks! -- Ehsan http://ehsanakhgari.org/
Re: [whatwg] Notifications: usage feedback
So, I'm not entirely sure how many lessons taken from the FirefoxOS
implementation are applicable to the API for web pages in general, but I
agree that what do we do if the user clicks on a notification after the
parent page has been closed is a bit of an unsolved/unsolveable problem
with the current API.
I dimly recall seeing an email thread proposing adding some kind of click
URL to a notification (and my search-fu is not strong enough to find a link
to it, sadly), which seems like it would address some of the issues you
have with the current API (encoding data that can be passed back to the app
on a notification click, even if the app has been closed in the meantime).
The solution I've seen implemented on the web (shutdown notifications when
a web page is closed) clearly doesn't work for a platform like FirefoxOS
which does memory management and app shutdown behind the scenes.
On Fri, Sep 27, 2013 at 3:15 AM, James Burke jrbu...@gmail.com wrote:
This Notifications feedback comes from using them in FirefoxOS for the
email web app. It uses an alarm API to periodically wake up, do an
email sync, and if new messages, creates some Notifications. The web
app may also shut itself down if it was not already opened in a
visible state. The OS may also decide to kill it to use the memory for
some other app.
1) Ability to pass data with the Notification
Right now, we URL-encode some args to the iconURL to pass data to the
handler function that is registered via
navigator.mozSetMessageHandler('notification', function(){}) [1].
It would be better if I could just pass a JSON-friendly data object to
Notification instance and then have access to that data in the
notification callbacks that are triggered.
We cannot depend on notification.onclick to work since the app can be
closed after the notification is fired. It also seemed very unreliable
to depend on it, given garbage collection possibilities. So we cannot
reliably capture state using a function closure.
2) General notification callback entry point
We are avoiding use of notification.onclick/onclose and would prefer
to have a generic entry point to receive notification events. Right
now we use navigator.mozSetMessageHandler('notification',
function(){}).
but I would prefer to see a more official entry point in the spec. I
would go so far as to want to deprecate the .onclick and .onclose as
in practice they are not reliable, given that the app may be closed
down after firing the Notification but before it is clicked.
3) onclick fires onclose too?
It seemed a bit unclear in the spec, but right now FirefoxOS fires
onclose too for onclick actions, as the onclick pathway removes the
notification from the list of notifications.
This seems counterintuitive to me, I would have only expected one
event. Perhaps clarifying the onclick behavior would be good.
I would prefer to just see one event fired in this case, if
onclick/onclose are kept around. If the general notification callback
entry point is established, then just firing it once with the
event.clicked property set to true for the clicked route.
4) onclick does not bring web app to front
This may be part of just further defining the steps for the click
pathway in the spec, but at least in FirefoxOS right now, the
notification onclick pathway does not bring the app to the visible
front in all cases. The email app has to do some extra document.hidden
checking and try to bring itself to the front.
What I would rather see is by default the web page is brought to the
visible front, and then perhaps allow the app a way to cancel that
behavior perhaps via a preventDefault() type of mechanism on any
notification click event.
This would also reduce the need for an API that the app could call to
bring itself to the visible front. Right now, there is an
app.launch() API in FirefoxOS for this, but there are concerns that
giving apps the ability to launch themselves to the front could lead
to an abuse of that API.
5) Ability to set notification modes.
This one is a bit less defined. I would rather this one is discarded
than spending too much time on it if it meant losing track of the
points above:
For email notifications, we did not necessarily want the phone to
light up the screen on every notification and make a sound or vibrate
(particularly at night), but rather just register the notification and
have it show up in the notification count and listing.
While ideally there is UI for the user to control notification
behavior for all web apps, I can also see the case for allowing
notifications the ability to opt in to the notification modes it
prefers.
Any user settings would override the modes specified in the
notification, but for apps that did want to be nice, it would be a way
to avoid a very annoying first notification behavior, in the case of
email, not disturbing the user unless they did an explicit override.
This may be too tricky
Re: [whatwg] Notifications: in workers
On Thu, May 16, 2013 at 5:45 PM, Anne van Kesteren ann...@annevk.nl wrote: On Wed, May 15, 2013 at 8:24 AM, Andrew Wilson atwil...@google.com wrote: On Tue, May 14, 2013 at 9:19 PM, Anne van Kesteren ann...@annevk.nl wrote: Chrome currently does not seem to do any of this particularly well, but when you click a notification from say the notification center there should be some going to the relevant site going on. E.g. via focusing a particular browsing context that spawned the notification. I'm not sure that's true - as I said, the specification says nothing about this, and the page that displays the notification is free to focus itself via an onclick handler if it likes. As an example, if you click on a gmail new-mail notification, instead of focusing gmail (which might be in the middle of some other operation such as composing an email, or you might be viewing a different message thread) we open the associated email in a new window. So in this case, we actively do *not* want to focus the source browsing context. So the chrome behavior is intentional. Fair enough. Trying to brain storm as to what should be done when you click a notification of a site that is no longer there. Navigating to a URL was one idea. Starting up an event worker as outlined (roughly) in http://annevankesteren.nl/2013/05/applifying might be a better idea. That's not a bad idea - as you know from my separate email with you, I'm less enamored with using Workers for these kinds of on-demand/background footprint tasks, because they are limited in so many ways (can't display a visible browsing context, for example). I prefer having instead a page that is loaded off-screen, albeit perhaps with a limited lifetime as you describe in that page. So how would that work if open gmail.com twice, in two distinct browsing contexts? Long term we want those to be able to use distinct threads I think, but they should be able to share a single event page/worker. I'll have to ping the gmail team to ask what they did there in their prototype. Not having the ability to focus (draw attention to) and open windows does seem like something we should solve. (The cross-origin loading case you mentioned should really be solved using WebSocket or CORS. I heard from at least one guy from your app team that they want to move to something like that long term and the iframe thing is mostly a intermediate hack.) The iframe thing (and other script-based solutions like JSONP) are definitely hacks, but they are hacks with a fairly long history in the web world. Agreed about CORS, although we've been talking about CORS support in workers for a while now with no implementations AFAIK - maybe we just need a compelling feature like this to drive teams to actually build it. Agreed that there's nothing stopping us from building whatever APIs we think we need into workers (window.open, window.focus, etc) to support the use cases that are already supported by the main browsing contexts, if there's a compelling reason to use workers instead. Yeah, that's currently not described. You think we should leave that to developers? That might work, although that leaves the questions about the site being closed. Yeah, it does. Currently in Chrome we basically punt on this, with the expectation that well-behaved pages close their notifications via an document.onclose handler. I hadn't really considered the case of the app developer wanting their notifications to hang around after the window closes and still have some action undertaken when the user clicks on them. That seems like something we want to support, no? E.g. you get a push message, so you open the event page/worker, and that dispatches a notification, but then you want to kill the event page/worker so it doesn't continue to use system resources. Couple days later the user might click the notification and then you'd open the event page/worker again. Agreed, I think this is a valid use case once you support event pages/workers as targets for notifications (it also probably has some uses for things like server-initiated notifications, where the server can specify a URL to navigate to when the user clicks, although I've never really paid attention to the server-initiated notification discussions so I don't quite follow their use cases). -- http://annevankesteren.nl/
Re: [whatwg] Notifications: in workers
On Tue, May 14, 2013 at 9:19 PM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, May 14, 2013 at 8:51 AM, Andrew Wilson atwil...@google.com wrote: On Sun, Mar 31, 2013 at 4:40 PM, Anne van Kesteren ann...@annevk.nl wrote: This seems problematic for shared workers as it is not clear which window the notification would be for. For normal workers this seems like less of a concern. Not sure what you mean - why does it matter which window the notification is for? Maybe this is only important for the permission prompt, but not for the notifications themselves which live outside any specific window? Chrome currently does not seem to do any of this particularly well, but when you click a notification from say the notification center there should be some going to the relevant site going on. E.g. via focusing a particular browsing context that spawned the notification. I'm not sure that's true - as I said, the specification says nothing about this, and the page that displays the notification is free to focus itself via an onclick handler if it likes. As an example, if you click on a gmail new-mail notification, instead of focusing gmail (which might be in the middle of some other operation such as composing an email, or you might be viewing a different message thread) we open the associated email in a new window. So in this case, we actively do *not* want to focus the source browsing context. So the chrome behavior is intentional. We also want to enhance the API to support the scenario of the site being closed but the notification still being alive, with the notification being able to revive the site in some way and the site being aware which notification was clicked (note that currently it would no longer have a reference to that object). If we go with the idea of exposing a URL on Notification objects and allow that to be set we might be able to address the shared worker issue, but it is not entirely clear to me which semantics are desirable there. Maybe if we made it a URL prefix it could work. E.g. you create a notification with a URL http://example.org/mail/ If that origin is allowed to display notifications that will all go well. SharedWorkers already have an inherent domain, inherited from their creating documents, correct? Why would we need to specify one when creating notifications? Trying to brain storm as to what should be done when you click a notification of a site that is no longer there. Navigating to a URL was one idea. Starting up an event worker as outlined (roughly) in http://annevankesteren.nl/2013/05/applifying might be a better idea. That's not a bad idea - as you know from my separate email with you, I'm less enamored with using Workers for these kinds of on-demand/background footprint tasks, because they are limited in so many ways (can't display a visible browsing context, for example). I prefer having instead a page that is loaded off-screen, albeit perhaps with a limited lifetime as you describe in that page. Not sure what you mean - are you expecting clicks on a notification to focus the initiating window (I don't see this behavior described in the notification spec)? Typically, this would be done via an onclick() handler, so in that case it would be up to the SharedWorker to proxy that event to a window if it wanted to focus one and not something the browser itself would do. Yeah, that's currently not described. You think we should leave that to developers? That might work, although that leaves the questions about the site being closed. Yeah, it does. Currently in Chrome we basically punt on this, with the expectation that well-behaved pages close their notifications via an document.onclose handler. I hadn't really considered the case of the app developer wanting their notifications to hang around after the window closes and still have some action undertaken when the user clicks on them. I feel like I'm misunderstanding the proposal though - sorry if I'm missing some context here. No worries, your input is much appreciated :-) -- http://annevankesteren.nl/
Re: [whatwg] Notifications: in workers
Sorry, missed this the first time through: On Sun, Mar 31, 2013 at 4:40 PM, Anne van Kesteren ann...@annevk.nl wrote: There is some interest in exposing Notification objects in a worker so creating one does not require a postMessage() roundtrip. This seems problematic for shared workers as it is not clear which window the notification would be for. For normal workers this seems like less of a concern. Not sure what you mean - why does it matter which window the notification is for? Maybe this is only important for the permission prompt, but not for the notifications themselves which live outside any specific window? If we go with the idea of exposing a URL on Notification objects and allow that to be set we might be able to address the shared worker issue, but it is not entirely clear to me which semantics are desirable there. Maybe if we made it a URL prefix it could work. E.g. you create a notification with a URL http://example.org/mail/ If that origin is allowed to display notifications that will all go well. SharedWorkers already have an inherent domain, inherited from their creating documents, correct? Why would we need to specify one when creating notifications? If there's a window open with that URL as prefix it can be focused once the user activates the notification. If there's no window open a window can be opened with that URL (no longer a prefix in this scenario). However, if there's several windows with that URL it's not clear what the best way would be. The last window the user interacted with maybe? Not sure what you mean - are you expecting clicks on a notification to focus the initiating window (I don't see this behavior described in the notification spec)? Typically, this would be done via an onclick() handler, so in that case it would be up to the SharedWorker to proxy that event to a window if it wanted to focus one and not something the browser itself would do. I feel like I'm misunderstanding the proposal though - sorry if I'm missing some context here. -- http://annevankesteren.nl/
Re: [whatwg] suggestions for the Notifications API (http://notifications.spec.whatwg.org/)
On Fri, May 3, 2013 at 6:49 PM, Nils Dagsson Moskopp n...@dieweltistgarnichtso.net wrote: alonn alonis...@gmail.com schrieb am Fri, 3 May 2013 18:50:36 +0300: 1. Having a way to check for the current permission without initiating a new Notification object first. something like webkit has (I'm not sure it's not deprecated) window.webkitNotification.checkPermission() I saw this isn't in the api, and I think having this would be a great Scenario: “You need to enable notifications to view this web site.” With less sarcasm: I think this can and will be horribly abused. To be clear, this capability exists in the current API. We've basically discussed this permission flow to death already, and have come to consensus around why having an explicit permission flow is needed to address key use cases. Do you have a new use (or abuse) scenario that this group has not considered previously? -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net --- Google Germany GmbH Dienerstr. 12 80331 München Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Katherine Stephens
Re: [whatwg] Declarative web worker creation and communication?
On Mon, Nov 5, 2012 at 10:24 AM, Fred Andrews freda...@live.com wrote: Hi Simon, The use I have in mind is a work-in-progress, see: http://www.w3.org/community/pua/wiki/Draft#Examples However the HTML standard already permits a UA to disable JS, and there is the iframe sandbox, or CSP, or browser extensions, to disable JS. I would like to make any extensions as widely applicable as possible in the hope of building support for them, and think there is a good case for a web application with document JS disabled that can still communicate with web workers to implement AJAX style designs. I guess I'm not convinced that a web worker (which has an architecture designed for asynchronous background processing) is the right vehicle for your shared context idea. My concern is that you're looking at the limited APIs currently available to web workers, and concluding that this makes them similar to shared contexts, when in reality the primary driver behind the limited worker APIs is thread safety, not UA privacy. The aim is not to work around JS being disabled, but to allow web pages to be designed with document JS disabled that still support a lot of features that are currently handled by the document JS. After giving it some more thought it would seem best to add new attributes for communication with web workers so that the existing attributes could implement a backup using a HTTP request - this might help support backwards compatibility or allow content to degrade gracefully if web workers are not supported. For example, if a form is declared to be submitted to a web work via a message post then it could also have a backup 'method' and 'action' to make a HTTP request to a server. The best path for supporting DOM updates from received web worker messages is not so clear to me. Perhaps an iframe, or a more general element extension that allows an innerHTML update to be received from web worker messages and perhaps from server sent events. cheers Fred To: wha...@whatwg.org; freda...@live.com ... On Sat, 03 Nov 2012 03:29:10 +0200, Fred Andrews freda...@live.com wrote: ... 1. Declarative web worker creation. Feedback and suggestions for appropriate markup to declare web workers would be appreciated. The use case is a document with JS disabled or restricted so that it can not create web workers, yet still wants to create web workers to process page input and to update the document. Can you give some concrete examples where JS is disabled or restricted? -- Simon Pieters Opera Software
Re: [whatwg] Declarative web worker creation and communication?
On Tue, Nov 6, 2012 at 2:21 AM, Fred Andrews freda...@live.com wrote: Hi Andrew, Thank you for the feedback. The PUA 'shared context' will likely need to be a distinct web worker variant to cater for any required restrictions and also to ensure it does not entangle its specific requirements with other innovations to web workers. However the message API may be reusable, and trying to avoid gratuitous differences seems a worthy goal. I'd encourage you to look at the MessagePort APIs, if you have not already. Agreed that using messages to pass data between different contexts is a powerful mechanism. Some concerns (lack of understanding) I have with the Web Worker spec. at: http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html 9.2.3 The worker's lifetime ... Otherwise, o is a Window object, and the relevant Document is just the Document that is the active document of the Window object o. Does this mean that the Document object of the caller is made available to be web worker? I can't see an interface to it? The Document is not made available - really, this section is just describing when it's safe to shutdown a worker (which can be quite complex when you have workers that create other workers, and shared workers). 9.2.4 Processing model ... 5. A new script is now created, as follows. ... Set the script's browsing context to owner browsing context. ... Set the script's document to owner document. There does not appear to be an API to actually effect the owner browsing context or document? Is this just laying a foundation for future work? Are web workers expected to someday be able to cause navigation of the creators browsing context etc? I don't think the plan is to allow navigation of the browsing context - I've always understood this section to mean that the worker shares a browsing context with the creating document for the purposes of cross-site XHR access, cookies, etc. I'm not at all sure what set the script's document means, but I'm not particularly fluent in spec-speak - I'm sure someone else on the list can explain the ramifications of that. 9.3 APIs available to workers ... The DOM APIs (Node objects, Document objects, etc) are not available to workers in this version of this specification. Are there plans to allow web workers access to the DOM of their creator? There have been discussions about some aspects of this (you can check the list archives - some people have wanted to be able to pass portions of the DOM back and forth to workers) but fundamentally the DOM provides a non-thread-safe API so I don't see how this would ever be possible. Does this apply to documents created by the web worker, such as via XHR? Looking at the source code for some implementations will help clarify the current state, but it would also be of interest to know of planned web workers extensions? I know there has been discussion about more efficient ways to pass/share data between documents and workers - this would enable things like background rendering to canvas, etc. Some of the discussion has happened on the W3C lists (such as http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0744.html) so I'd suggest looking at those archives also. cheers Fred Date: Mon, 5 Nov 2012 10:41:00 +0100 From: atwil...@google.com To: freda...@live.com CC: wha...@whatwg.org; sim...@opera.com Subject: Re: [whatwg] Declarative web worker creation and communication? On Mon, Nov 5, 2012 at 10:24 AM, Fred Andrews freda...@live.com wrote: Hi Simon, The use I have in mind is a work-in-progress, see: http://www.w3.org/community/pua/wiki/Draft#Examples However the HTML standard already permits a UA to disable JS, and there is the iframe sandbox, or CSP, or browser extensions, to disable JS. I would like to make any extensions as widely applicable as possible in the hope of building support for them, and think there is a good case for a web application with document JS disabled that can still communicate with web workers to implement AJAX style designs. I guess I'm not convinced that a web worker (which has an architecture designed for asynchronous background processing) is the right vehicle for your shared context idea. My concern is that you're looking at the limited APIs currently available to web workers, and concluding that this makes them similar to shared contexts, when in reality the primary driver behind the limited worker APIs is thread safety, not UA privacy. The aim is not to work around JS being disabled, but to allow web pages to be designed with document JS disabled that still support a lot of features that are currently handled by the document JS. After giving it some more thought it would seem best to add new attributes for communication with web workers so that the existing attributes could implement a backup using a HTTP
