This discussion reminds me of a similar issue with MessagePorts. The
original MessagePort spec exposed GC behavior through the use of onclose
events/closed attributes on MessagePorts. It turns out that on Chromium,
there are situations where it's very difficult for us to GC MessagePorts (a
port's
On Wed, Feb 9, 2011 at 11:20 AM, Jeremy Orlow jor...@chromium.org wrote:
On Wed, Feb 9, 2011 at 11:05 AM, Drew Wilson atwil...@google.com wrote:
This discussion reminds me of a similar issue with MessagePorts. The
original MessagePort spec exposed GC behavior through the use of onclose
at 12:56 PM, Glenn Maynard gl...@zewt.org wrote:
On Wed, Feb 9, 2011 at 2:05 PM, Drew Wilson atwil...@google.com wrote:
This discussion reminds me of a similar issue with MessagePorts. The
original MessagePort spec exposed GC behavior through the use of onclose
events/closed attributes
On Wed, Feb 9, 2011 at 2:03 PM, Jonas Sicking jo...@sicking.cc wrote:
For what it's worth, shared workers already expose GC behavior. You'll
get a already-existing shared worker, or a new one will be created,
depending on if GC has collected the worker or not.
Hmmm. That was certainly not
I'm also curious about this - I wrote a set of tests for SharedWorkers for
WebKit that cover some of the subtler points around worker lifetime that I'm
suspecting other implementations would find useful, and I'm guessing that
there are tests from other implementations that would expose bugs in
FWIW, the Chrome team has come down pretty hard on the side of not ever
leaking to apps that the user is in incognito mode, for precisely the
reasons described previously. Incognito mode loses much of its utility if
pages are able to screen for it and block access.
I do think there's a user
On Wed, Jun 30, 2010 at 7:08 PM, Krzysztof Maczyński 198...@gmail.comwrote:
11. In [c]:
there is no way to override the type. It's always assumed to be
JavaScript.
This is a violation of orthogonality for no real benefit.
I know that the NativeClient team has experimented with supporting
On Fri, Jun 25, 2010 at 9:07 AM, Jeremy Orlow jor...@chromium.org wrote:
Well, getting things to look would possibly take more effort on a web
developer's part, but having _anything_ show up (for developers who only
target browsers that support HTML) would always work...even if poorly. With
On Thu, Jun 24, 2010 at 11:38 AM, Doug Turner doug.tur...@gmail.com wrote:
I have been thinking a bit on Desktop Notifications [1]. After reviewing
the Web Notification specification [2], I would like to propose the
following changes:
1) Factor out the permission api into a new interface
This is great stuff - I have a few obscure comments/questions below, but
overall this is looking very cool!
Section 8:
Should passing an unsupported type of web content to
createWebNotification() generate an error event?
I think it should throw an exception. Since there is no
This looks good. One thing which I suggested previously but which didn't
make it into the spec is the ability for the UA to eliminate duplicate
notifications. Since I've been using the existing experimental notifications
API in Chrome, I've found that duplicate notifications are very common and
2010/2/23 Ian Fette (イアンフェッティ) ife...@google.com
Am 23. Februar 2010 12:11 schrieb Anne van Kesteren ann...@opera.com:
On Tue, 23 Feb 2010 20:20:13 +0100, Ian Fette (イアンフェッティ)
ife...@google.com wrote:
CreateInteractiveNotification(in DOMString text-fallback, [Optional] in
DOMString
This was recently brought to my attention by one of the web app developers
in my office:
http://dev.w3.org/2006/webapi/FileAPI/#lifetime
User agents MUST ensure that the lifetime of File URN #dfn-fileURNs is the
same as the lifetime of the Document [HTML5 #HTML5] of the origin script
which
2010/2/23 Jonas Sicking jo...@sicking.cc
The same is not true for the suggest notification API. Several
proposals have been put forward that do not rely on fallback.
One of the reasons I stepped back from this discussion is because it seemed
clear that we weren't going to make progress on
On Fri, Feb 12, 2010 at 5:06 AM, Henri Sivonen hsivo...@iki.fi wrote:
On Feb 11, 2010, at 16:07, Jeremy Orlow wrote:
As has been brought up repeatedly, growl and the other notification
engines are used by a SMALL FRACTION of all web users. I suspect a fraction
of a percent. Why are we
On Wed, Feb 10, 2010 at 2:17 AM, Henri Sivonen hsivo...@iki.fi wrote:
On Feb 3, 2010, at 20:54, Drew Wilson wrote:
Following up on breaking out createHTMLNotification() and
createNotification() vs combining them into one large API - I believe the
intent is that a given user agent may
On Wed, Feb 10, 2010 at 2:33 PM, Robert O'Callahan rob...@ocallahan.orgwrote:
On Thu, Feb 11, 2010 at 11:10 AM, Drew Wilson atwil...@google.com wrote:
One of the suggestions made previously on this thread was to coalesce
createNotification() and createHTMLNotification() into a single API
On Wed, Feb 10, 2010 at 3:31 PM, Robert O'Callahan rob...@ocallahan.orgwrote:
On Thu, Feb 11, 2010 at 12:03 PM, Drew Wilson atwil...@google.com wrote:
On Wed, Feb 10, 2010 at 2:33 PM, Robert O'Callahan
rob...@ocallahan.orgwrote:
I think a better way to go would be to support a restricted
On Wed, Feb 10, 2010 at 3:22 PM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Feb 10, 2010 at 3:03 PM, Drew Wilson atwil...@google.com wrote:
On Wed, Feb 10, 2010 at 2:33 PM, Robert O'Callahan rob...@ocallahan.org
wrote:
On Thu, Feb 11, 2010 at 11:10 AM, Drew Wilson atwil
On Wed, Feb 10, 2010 at 5:49 PM, Jonas Sicking jo...@sicking.cc wrote:
And I think the answer is yes. Any time someone talks about an
optional web feature I get nervous. Can you give any examples of
successful optional web features that exist today?
I'd suggest Javascript and Images, but
On Fri, Feb 5, 2010 at 6:52 AM, Anne van Kesteren ann...@opera.com wrote:
On Thu, 04 Feb 2010 00:36:26 +0100, John Gregg john...@google.com wrote:
I'm familiar with that version of the proposal (in fact my WHATWG proposal
from March '09 had the same language: untrusted notifications displayed
On Fri, Feb 5, 2010 at 10:36 AM, Anne van Kesteren ann...@opera.com wrote:
On Fri, 05 Feb 2010 19:19:24 +0100, Drew Wilson atwil...@google.com
wrote:
I've thought about this some more, and I'm not at all convinced that
in-tab notification support is the right way to go. It seems that in-tab
Following up on breaking out createHTMLNotification() and
createNotification() vs combining them into one large API - I believe the
intent is that a given user agent may not support all types of notifications
(for example, a mobile phone application may only support text + icon
notifications, not
That's true in general about any UI the worker may display (HTTP Auth,
Certificate errors, etc) - the UA generally picks a parent document on
behalf of the worker and displays the UI on the associated screen.
If the client cares about which screen specifically it's displaying on
(because it has
into some of
the limitations of the text + icon notifications in my recent work (one
example: the lack of an onclick event) which I'll try to write up sometime
in the near future.
-atw
On Wed, Feb 3, 2010 at 11:41 AM, Anne van Kesteren ann...@opera.com wrote:
On Wed, 03 Feb 2010 19:54:44 +0100, Drew
On Wed, Feb 3, 2010 at 1:22 PM, Anne van Kesteren ann...@opera.com wrote:
On Wed, 03 Feb 2010 18:55:32 +0100, Olli Pettay olli.pet...@helsinki.fi
wrote:
some random comments about
http://dev.w3.org/2006/webapi/WebNotifications/publish/
(I didn't know that the draft existed until the link
On Wed, Feb 3, 2010 at 2:50 PM, Anne van Kesteren ann...@opera.com wrote:
On Wed, 03 Feb 2010 23:40:23 +0100, John Gregg john...@google.com wrote:
Yes, this makes sense; I am changing the draft spec to have a
permissionLevel attribute. I think having access to the permission level
is
The specific implementation of SharedWorkers in WebKit does this currently,
but that is not a feature of the spec - I have this on my todo list to
resolve once I've finished the Chromium version of shared workers.
-atw
On Mon, Nov 9, 2009 at 10:09 AM, Alexey Proskuryakov a...@webkit.org wrote:
to
express/establish its appcache is missing.
On Sat, Nov 7, 2009 at 9:14 AM, Drew Wilson atwil...@google.com wrote:
You may have two separate pages running from different app caches (or
version), each of which is trying to access the same shared worker, so we
don't want to tie it explicitly
29 matches
Mail list logo
