I'll mention that the Chrome team is experimenting with something like this
(as a Chrome extensions API) - certain extensions will be able to do:
window.open(my_bg_page.html, name, background);
...and the associated window will be opened offscreen. They share a process
with other pages under
Hi all,
Jonas brought up an interesting point regarding SharedWorkers in an
unrelated thread that I wanted to clarify here.
His contention is that the current SharedWorker spec specifies that the
lifecycle of a SharedWorker is currently tied to the GC behavior of the
underlying VM -
I would recommend that people review this thread:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-February/025254.htmlto
understand the objections previously raised to this idea.
-atw
On Fri, Jan 7, 2011 at 4:08 PM, Glenn Maynard gl...@zewt.org wrote:
On Fri, Jan 7, 2011 at 6:22 PM,
I believe it's a security feature.
Imagine that you download foo.html into your C:/ - according to the logic
below, script running in foo.html should be able to read *any file on your
C:/ drive*. That seems scary to me.
FWIW, chrome allows passing the --allow-file-access-from-files command line
On Wed, Jul 21, 2010 at 1:11 PM, Ryan Heise r...@ryanheise.com wrote:
For all of the reasons above, I would like to see something like threads
in Javascript. Yes, threads give rise to race conditions and deadlocks,
but this seems to be in line with Javascript's apparent philosophy of
doing
How does the GC-initiated close() event work in Firefox, in the case of a
fire-and-forget worker?
For example:
foo.html:
script
new Worker(forget.js);
/script
forget.js:
self.setInterval(function() { ...do something...}, 1000);
In this case, it seems incorrect to ever fire a close() event
I'll note that the spec gives the UA an significant amount of latitude about
its behavior after close() is called:
User agents may invoke the kill a worker #kill-a-worker processing model
on a worker at any time, e.g. in response to user requests, in response to
CPU quota management, or when a
Agreed, there's not a good way to determine that a port is
disentangled. Currently the main solution I know of is to have your document
post a message to your shared worker in their onunload handler.
I think some kind of MessagePort.onclose event or entangled attribute
could be useful - this was
On Mon, Feb 22, 2010 at 11:13 AM, David Levin le...@google.com wrote:
I've talked with some other folks on WebKit (Maciej and Oliver) about
having a canvas that is available to workers. They suggested some nice
modifications to make it an offscreen canvas, which may be used in the
Document or
BTW, I would highly recommend that we move this conversation to the
public-webapps list. I'm not sure about the best way to do this other than
to stop posting here, starting...um...right after my reply :)
Anyhow, your question below outlines is why there are two exposed
notification APIs - one is
Apps on the iphone using SQL data storage might disagree with you about the
value of optional web features :) But I do understand your point, and
perhaps there's a better way to achieve the goals of the notification API.
The goals as I understand them are:
1) Support simple text + icon
I ran into this early last year when I was first investigating MessagePorts:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-March/018893.html
I dimly recall that the response I got off-list (via IRC?) was that this was
expected behavior (the intended use for window.postMessage() is for
That was my point earlier - for this to work, if you post getX and setX over
separately, they need to share a closure otherwise they don't work.
Realistically, given Javascript's dynamic nature, you need to copy
everything reachable via the function's scope chain, and recursively copy
everything
I'm not certain what a deep copy of the function means - would you need to
copy the entire lexical scope of the function? For example, let's say you do
this:
var foo = 1;
function setFoo(val) { foo = val; }
function getFoo() { return foo; }
worker.postMessage(setFoo);
We discussed this previously (
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-July/020865.html) -
the consensus was that since the Worker APIs are inherently asynchronous,
user agents were free to impose limits on worker creation (and queue up new
creation requests when the limit has
FWIW, I've usually looked at self.postMessage when trying to determine
whether running in dedicated or shared worker context, although Anne's
suggestion (using in) is better.
-atw
On Mon, Oct 26, 2009 at 7:00 AM, Anne van Kesteren ann...@opera.com wrote:
On Mon, 26 Oct 2009 13:57:10 +0100,
As a data point, the WebKit implementation (used by Safari and Chrome)
doesn't currently enforce any limits (other than those imposed by running
out of memory).
-atw
On Fri, Oct 23, 2009 at 12:02 AM, Ian Hickson i...@hixie.ch wrote:
On Thu, 22 Oct 2009, Brian Kuhn wrote:
Is there any limit
On Wed, Oct 14, 2009 at 3:33 AM, Ian Hickson i...@hixie.ch wrote:
There's no start() to call, since there's no explicit pointer to the
MessagePort in dedicated workers.
The example in the worker spec refers to shared workers, which *do* have an
explicit port, and do not automatically start
To be absolutely clear (since there's some confusion about whether we are
talking about explicit MessagePorts, or about implicit ports for dedicated
workers).
Are you saying that this:
var channel = new MessageChannel();
channel.port1.postMessage(hi mom);
channel.port2.addEventListener(message,
The intent of the spec is fairly clear that addEventListener(message)
should not start the message queue dispatch - only setting the onmessage
attribute does that:
The first time a MessagePort #messageport object's
onmessage#handler-messageport-onmessage IDL
attribute is set, the port's port
Are you saying that if I load a script via a script tag in a web page,
then load it via importScripts() in a worker, that the result of loading
that script in those two cases should/could be different because of
different decoding mechanisms?
If that's what's being proposed, that seems bad.
-atw
ann...@opera.comwrote:
On Fri, 25 Sep 2009 18:39:48 +0200, Drew Wilson atwil...@google.com
wrote:
Are you saying that if I load a script via a script tag in a web page,
then load it via importScripts() in a worker, that the result of loading
that script in those two cases should/could
, string resources) with the appropriate charset header will
find it fails when loaded into workers.
Again, apologies if I'm misunderstanding the suggestion.
-atw
On Fri, Sep 25, 2009 at 10:21 AM, Anne van Kesteren ann...@opera.comwrote:
On Fri, 25 Sep 2009 19:16:47 +0200, Drew Wilson atwil
Jeremy, what's the use case here - do developers want workers to have access
to shared local storage with pages? Or do they just want workers to have
access to their own non-shared local storage?
Because we could just give workers their own separate WorkerLocalStorage and
let them have at it. A
...@google.comwrote:
On Wed, Sep 16, 2009 at 10:53 AM, Michael Nordman micha...@google.comwrote:
On Wed, Sep 16, 2009 at 9:58 AM, Drew Wilson atwil...@google.comwrote:
Jeremy, what's the use case here - do developers want workers to have
access to shared local storage with pages? Or do they just want
Thanks, Robert - I didn't want to second my own proposal :)
I think that #4 is probably a reasonable bridge API until we come up with a
consensus API for #3. For myself, I see this API as being very useful for
persistent workers (yes, I'm still banging that drum :).
-atw
On Wed, Sep 16, 2009 at
Agreed - I've always felt like having to have a reference to a window would
be an obstacle.
I feel obliged to point out that cross-domain SharedWorkers might be another
option for two completely unrelated windows to interact, although the
suggestions I've heard for APIs for x-domain access seem to
I think the canonical racy case is the page wants to keep a counter for the
number of times event X occurs in a cookie or local storage.
It doesn't seem to be possible to achieve this without the mutex - the
proposal below would break down if two pages tried to increment the cookie
value
On Thu, Sep 3, 2009 at 1:32 PM, Benjamin Smedberg bsmedb...@mozilla.comwrote:
On 9/3/09 4:24 PM, Drew Wilson wrote:
I think the canonical racy case is the page wants to keep a counter for
the number of times event X occurs in a cookie or local storage.
It doesn't seem to be possible
To be clear, I'm not trying to reopen the topic of giving cookie access to
workers - I'm happy to restrict cookie access to document context (I
probably shouldn't have brought it up again).
I do agree with Jeremy that we should rethink the spec language around
cookie consistency to reflect what
When we had this discussion last, there was significant pushback on this -
the argument was basically we have no evidence that cookie-based race
conditions *aren't* causing sporadic breakages, which is true. It's
inherently difficult to measure.
As an aside, I'll note that the majority of pushback
and so you can't send messages via
it. Re-sending a cloned port is an error, and we should treat it as such.
-atw
On Fri, Aug 28, 2009 at 12:11 PM, Ian Hickson i...@hixie.ch wrote:
On Mon, 17 Aug 2009, Drew Wilson wrote:
Following up on this issue:
Currently, the checks specified
My recollection is that we prohibit worker access to cookies for exactly
this reason (WorkerGlobalScope does not expose a cookies attribute).
-atw
On Wed, Aug 26, 2009 at 2:05 PM, Jens Alfke s...@google.com wrote:
I know that one of the design issues with worker threads and local storage
has
On Wed, Aug 26, 2009 at 2:21 PM, Jens Alfke s...@google.com wrote:
On Aug 26, 2009, at 2:11 PM, Drew Wilson wrote:
My recollection is that we prohibit worker access to cookies for exactly
this reason (WorkerGlobalScope does not expose a cookies attribute).
Looks like you're right; section 5
This is one of those times when I *really* wish that the application
developer community was more active on this list. I absolutely understand
Linus' point of view, but I also feel like we are really hamstringing
applications when we make choices like this and I wish that those developers
were
On Tue, Aug 25, 2009 at 11:51 AM, Jeremy Orlow jor...@chromium.org wrote:
On Sun, Aug 23, 2009 at 11:33 PM, Robert O'Callahan
rob...@ocallahan.orgwrote:
On Sat, Aug 22, 2009 at 10:22 PM, Jeremy Orlow jor...@chromium.orgwrote:
On Sat, Aug 22, 2009 at 5:54 AM, Robert O'Callahan
BTW, the WorkerGlobalScope.importScript() API blocks the current thread of
execution, which is probably not acceptable for code executed from page
context. So for globalscripts we'll need some way to do async notifications
when the loading is complete, and report errors. We may also want to have
An alternative would be to make the name parameter optional, where
omitting the name would create an unnamed worker that is identified/shared
only by its url.
So pages would only specify the name in cases where they actually want to
have multiple instances of a shared worker.
-atw
On Tue, Aug
is to throw an INVALID_STATE_ERR in this case,
while still allowing closed ports to be sent, which I believe is the
intended behavior based on previous discussions. If this is correct, we
should update the spec to prohibit resending cloned ports.
-atw
On Thu, Jun 4, 2009 at 10:30 AM, Drew Wilson
That suggestion has also been floating around in some internal discussions.
I'd have to objections to this approach either, although I'm not familiar
enough with URL semantics to know if this is a valid use of URL fragments.
-atw
On Sat, Aug 15, 2009 at 5:29 PM, Jim Jewett jimjjew...@gmail.com
On Sun, Aug 16, 2009 at 12:51 PM, Michael Nordman micha...@google.comwrote:
I'd have to objections to this
Did you mean to say i'd have no objectsion to this?
Yes, I have *no* objections to either approach. Apparently the coffee hadn't
quite hit my fingers yet.
-atw
Currently, SharedWorkers accept both a url parameter and a name
parameter - the purpose is to let pages run multiple SharedWorkers using the
same script resource without having to load separate resources from the
server.
Per section 4.8.3 of the SharedWorkers spec, if a page loads a shared worker
On Thu, Aug 13, 2009 at 4:07 AM, Ian Hickson i...@hixie.ch wrote:
Sure, although I'd say that persistent storage is addressed by the Web
Storage and Web Database features. Shared state is also addressed, but
that's not the primary goal. If I have a tree of objects that I'd like
to share
On Thu, Aug 13, 2009 at 5:13 AM, Mike Wilson mike...@hotmail.com wrote:
Maybe I'm mistaken, but I think Drew wanted handling of
live objects, where each window gets access to the same
concrete objects (possibly protected by private proxy
objects) so the graph can be walked without cloning.
2009/8/7 Michael Kozakewich mkozakew...@icosidodecahedron.com
TO SUMMARIZE:
-There are many other existing ways to notify
-I'd suggest browsers have a Notification process with which open tabs
register.
-Registered open tabs could tell the browser to pop up a notification,
perhaps with
I was writing some unit tests for SharedWorkers, and I saw some behavior
that seems to be spec compliant, but which was counter-intuitive from a
developer standpoint.
Let's say that you have two message ports - some other window or a shared
worker owns the other end of those ports.
You then do
On Mon, Aug 3, 2009 at 8:58 PM, Ian Hickson i...@hixie.ch wrote:
It seems like a direct solution to these would be to have a way for Web
pages to expose a service that clients could subscribe to, which could
send up database updates and notifications. That way, no script runs on
the client,
On Tue, Aug 4, 2009 at 10:47 AM, Jeremy Orlow jor...@chromium.org wrote:
Which use case is this related to? If the shared worker is creating UI
elements for the page, then composing HTML and sicking it into a div's
.innerHTML is actually (sadly) the fastest way to go at the moment. Besides
On Mon, Aug 3, 2009 at 10:34 AM, Daniel Gredler daniel.gred...@gmail.comwrote:
I know Anne VK (Opera) and ROC (Mozilla) appear to read this list... any
comments, guys? Should I just file bugs? Any Safari / Chrome / IE guys out
there with comments?
I've often had the same thought (that
I think the error here is viewing this as a UX issue - if it were just a UX
issue, then the responses from people would be along the lines of Oh, this
sounds dangerous - make sure you wrap it with the same permissions UI that
we have for extensions, plugins, and binary downloads.
The realization I
On Wed, Jul 29, 2009 at 7:19 AM, Tab Atkins Jr. jackalm...@gmail.comwrote:
Firefox's Jetpack addon (essentially Greasemonkey turned up to 11)
exposes a super-convenient jetpack.notifications.show() function for
doing exactly that. It pops up an attractive notification in the
lower
On Wed, Jul 29, 2009 at 6:32 AM, Michael Kozakewich
mkozakew...@icosidodecahedron.com wrote:
It sounds like the hidden page idea is just the solution you thought up
to the problem of keeping a page running. How many other reasons are there
for it?
Not sure what other motivations there may
with
that. The question (as with native apps) is whether we can mitigate those
vulnerabilities, and whether the functionality that persistence provides is
worth the larger attack surface.
On Tue, Jul 28, 2009 at 10:58 PM, Maciej Stachowiak m...@apple.com wrote:
On Jul 28, 2009, at 10:01 AM, Drew Wilson
My understanding (when I looked at Prism a while back) was that it was
essentially no different than a desktop shortcut that ran the page in a
separate profile. Has this changed?
-atw
On Wed, Jul 29, 2009 at 10:21 AM, timeless timel...@gmail.com wrote:
On Wed, Jul 29, 2009 at 7:56 PM, Drew
). Those services usually involve some combination of
multiple affirmative steps, vetting, reputation and revocation.
Linus
On Tue, Jul 28, 2009 at 10:58 PM, Maciej Stachowiak m...@apple.com wrote:
On Jul 28, 2009, at 10:01 AM, Drew Wilson wrote:
I've been kicking around some ideas
On Wed, Jul 29, 2009 at 1:33 AM, Ian Hickson i...@hixie.ch wrote:
Yes. But that's the case anyway -- events are asynchronous, so consider
the case of receiving two messages. Both are queued up, then eventually
the first is dispatched. If in response to that you close the connection,
that
I've been kicking around some ideas in this area. One thing you could do
with persistent workers is restrict network access to the domain of that
worker if you were concerned about botnets. That doesn't address the I
installed something in my browser and now it's constantly sucking up my CPU
To clarify - I said that *persistent workers* could restrict x-domain
network access. I didn't mean to imply that you could apply this same
reasoning to hidden pages - I haven't thought about hidden pages enough to
comment about the implications of that, since as you mention there are many
more
On Mon, Jul 27, 2009 at 1:14 PM, Alexey Proskuryakov a...@webkit.org wrote:
27.07.2009, в 12:35, Maciej Stachowiak написал(а):
However, I do not think that raising an exception is an appropriate
answer. Often, the TCP implementation takes a part of data given to it, and
asks to resubmit
.
This sounds like the best approach to me.
27.07.2009, в 13:27, Drew Wilson написал(а):
I would suggest that the solution to this situation is an appropriate
application-level protocol (i.e. acks) to allow the application to have no
more than (say) 1MB of data outstanding.
I'm just afraid
On Mon, Jul 27, 2009 at 2:02 PM, Jeremy Orlow jor...@chromium.org wrote:
On Mon, Jul 27, 2009 at 1:44 PM, Drew Wilson atwil...@google.com wrote:
On Mon, Jul 27, 2009 at 1:36 PM, Alexey Proskuryakov a...@webkit.orgwrote:
27.07.2009, в 13:20, Jeremy Orlow написал(а):
I agree
This sounds really powerful, and seems like a natural evolution of some of
the stuff we've discussed previously for persistent workers. A few
comments/notes:
1) It sounds like this background page would act like any other web page
with respect to its processing model (i.e. like other pages, script
I noticed that Section 4.6 of the Web Workers spec still refers to the
close event which has been removed:
If the script gets aborted by the kill a
worker#122aa363b1e6e893_kill-a-worker
algorithm, then that same algorithm will cause there to only be a singletask in
the event loop at the next
Not sure what you are suggesting, Anne - it sounds like they want to tie the
AppCache to a specific cookie/value combination, which I don't believe is
supported by the current spec.
-atw
On Wed, Jul 22, 2009 at 3:32 AM, Anne van Kesteren ann...@opera.com wrote:
On Wed, 15 Jul 2009 00:30:05
On Wed, Jul 22, 2009 at 9:46 AM, Anne van Kesteren ann...@opera.com wrote:
On Wed, 22 Jul 2009 18:10:52 +0200, Drew Wilson atwil...@google.com
wrote:
Not sure what you are suggesting, Anne - it sounds like they want to tie
the AppCache to a specific cookie/value combination, which I don't
On Fri, Jun 26, 2009 at 9:18 AM, James Robinson jam...@google.com wrote:
However, users can't usefully check the readyState to see if the WebSocket
is still open because there are not and cannot be any
synchronization guarantees about when the WebSocket may close.
Is this true? Based on our
is closed, but that's true regardless due
to the asynchronous nature of the networking protocol.
-atw
On Fri, Jun 26, 2009 at 9:52 AM, Darin Fisher da...@chromium.org wrote:
On Fri, Jun 26, 2009 at 9:46 AM, Drew Wilson atwil...@google.com wrote:
On Fri, Jun 26, 2009 at 9:18 AM, James Robinson
On Fri, Jun 26, 2009 at 1:14 PM, Kelly Norton knor...@google.com wrote:
One thing about postMessage that I'm curious about. Since it has to report
failure synchronously by throwing an INVALID_STATE_ERR, that seems to imply
that all data must be written to a socket before returning and cannot
On Fri, Jun 26, 2009 at 2:11 PM, James Robinson jam...@google.com wrote:
Forcing applications to build their own send/ack functionality would be
pretty tragic considering that WebSockets are built on top of TCP.
- James
Every time I've written a response/reply protocol on TCP I've needed
On Fri, Jun 26, 2009 at 3:25 PM, Michael Nordman micha...@google.comwrote:
On Fri, Jun 26, 2009 at 3:16 PM, Drew Wilson atwil...@google.com wrote:
On Fri, Jun 26, 2009 at 2:11 PM, James Robinson jam...@google.comwrote:
Forcing applications to build their own send/ack functionality
On Fri, Jun 26, 2009 at 3:47 PM, Michael Nordman micha...@google.comwrote:
No. But the difference is each XHR tells you when its been sent and gives
you the response when its received. With this info, apps can rate limit
things. WebSocket.postMessage doesn't tell you when that message has
That's a great approach. Is the pool of OS threads per-domain, or per
browser instance (i.e. can a domain DoS the workers of other domains by
firing off several infinite-loop workers)? Seems like having a per-domain
thread pool is an ideal solution to this problem.
-atw
On Tue, Jun 9, 2009 at
This is a bit of an aside, but section 4.5 of the Web Workers spec no longer
makes any guarantees regarding GC of workers. I would expect user agents to
make some kind of best effort to detect unreachability in the simplest
cases, but supporting MessagePorts and SharedWorkers makes authoritatively
It occurs to me that my statement was a bit stronger than I intended - the
spec *does* indeed make guarantees regarding GC of workers, but they are
fairly loose and typically tied to the parent Document becoming inactive.
-atw
On Tue, Jun 9, 2009 at 6:42 PM, Drew Wilson atwil...@google.com wrote
Hi all,
I'd like to propose a change to the spec for postMessage(). Currently the
spec reads:
Throws an
INVALID_STATE_ERRhttp://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#invalid_state_err
if
the ports array is not null and it contains either null entries, duplicate
On Thu, May 28, 2009 at 7:47 PM, Maciej Stachowiak m...@apple.com wrote:
On May 28, 2009, at 5:17 PM, Ian Hickson wrote:
On Thu, 28 May 2009, Maciej Stachowiak wrote:
On May 28, 2009, at 1:08 PM, Ian Hickson wrote:
On Thu, 28 May 2009, Maciej Stachowiak wrote:
If so, that seems like
On Thu, May 28, 2009 at 1:11 AM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, May 27, 2009 at 6:15 PM, Drew Wilson atwil...@google.com wrote:
Along the same lines, I'm wondering why we require a same-domain check
for
initial worker URLs, but not for script imported via importScripts
Is your concern that an ill-behaved app could leak ports (since obviously an
ill-behaved app could leak ports anyway just by stuffing them in some
array), or is it that a well-behaved app can't release ports? Still need to
review the new spec in detail, but from previous conversations I'd assumed
of the MessageChannel are dropped. That
seems unacceptable to me, unless I misunderstood.
The requirement is actually indistinguishable from the UA using the other
alternative and just having a really slow garbage collector that only runs
at page-closing time.
On Thu, 28 May 2009, Drew Wilson
Along the same lines, I'm wondering why we require a same-domain check for
initial worker URLs, but not for script imported via importScripts(). Seems
like we ought to have workers inherit the origin of the script context that
invoked the Worker constructor, but allow the script URL passed to the
Hi all,
I've been hashing through a bunch of the design issues around using
MessagePorts within Workers with IanH and the Chrome/WebKit teams and I
wanted to follow up with the list with my progress.
The problems we've encountered are all solveable, but I've been surprised at
the amount of work
of MessagePorts
for things like cross-window and cross-iframe communication, but it seems
like the use cases for external access to workers are far more obscure.
-atw
On Thu, May 7, 2009 at 2:47 PM, Ian Hickson i...@hixie.ch wrote:
On Thu, 7 May 2009, Drew Wilson wrote:
Having MessagePorts
that I'm not
properly translating from spec language into actual behavior, and perhaps
the intended behavior is not as complex as the spec implies.
-atw
On Fri, Apr 10, 2009 at 6:32 PM, Drew Wilson atwil...@google.com wrote:
Hi all,
A couple of quick questions about the lifecycle of workers
Hi all,
A couple of quick questions about the lifecycle of workers - specifically
I'm trying to grok the body of text at section 4.5 of the Web Workers spec.
It seems like it's saying that if I create a shared worker, then hand off
its port to another window, that shared worker will be orphaned
I know I said I would stay out of this conversation, but I feel obliged to
share a data point that's pertinent to our API design.
The structured storage spec has an asynchronous API currently. There are no
shortage of experienced javascript programmers at Google, and yet the single
biggest piece
On Mon, Mar 30, 2009 at 6:45 PM, Robert O'Callahan rob...@ocallahan.orgwrote:
We have no way of knowing how much trouble this has caused so far;
non-reproducibility means you probably won't get a good bug report for any
given incident.
It's even plausible that people are getting lucky with
On Tue, Mar 31, 2009 at 6:25 PM, Robert O'Callahan rob...@ocallahan.orgwrote:
We know for sure it's possible to write scripts with racy behaviour, so the
question is whether this ever occurs in the wild. You're claiming it does
not, and I'm questioning whether you really have that data.
I'm
On Fri, Mar 27, 2009 at 6:23 PM, Ian Hickson i...@hixie.ch wrote:
Another use case would be keeping track of what has been done so far, for
this I guess it would make sense to have a localStorage API for shared
workers (scoped to their name). I haven't added this yet, though.
On a related
On Thu, Mar 26, 2009 at 3:58 AM, Alexey Proskuryakov a...@webkit.org wrote:
Letting faceless background processes update themselves without user
consent is not necessarily desirable. I think that they need browser UI for
this, and/or associated HTML configuration pages that could (among other
On Thu, Mar 26, 2009 at 1:19 PM, Alexey Proskuryakov a...@webkit.org wrote:
But I was looking at this in terms of a model for users, not any specific
security threats - if we think of persistent workers as an equivalent of
native applications that need installation, then we should consider
On Wed, Mar 25, 2009 at 2:11 PM, Michael Nordman micha...@google.comwrote:
The appcache spec has changed since the ian and i sent these old messages.
Child browsing contexts (nested iframes) no longer inherit the appcache of
their parent context (frame) by default.
How's this for a starting
to restart the nested worker, though :)
-atw
On Wed, Mar 25, 2009 at 5:09 PM, David Levin le...@google.com wrote:
On Wed, Mar 25, 2009 at 3:01 PM, Drew Wilson atwil...@google.com wrote:
On Wed, Mar 25, 2009 at 2:11 PM, Michael Nordman micha...@google.comwrote:
The appcache spec has changed
I'm trying to understand the ApplicationCache spec as it applies to workers,
but I didn't find anything promising when I searched the archives. Is
ApplicationCache intended to apply to workers? The application cache API
isn't available to workers, but I'm guessing the intent is that if an
The problem is that .length is basically useless without some kind of
immutability guarantees.
I've thought about this more, and I'm afraid that if you start making the
API cumbersome (forcing only async access) then apps are just going to use
document.cookies instead of localStorage. I'd hate to
If you deny workers, you can enforce exclusive access to localStorage by
applying a lock that extends from the first access of localStorage until the
script re-enters the event loop. Page script is guaranteed to re-enter the
event loop fairly quickly (lest it trigger the browser's this script is
:
On Sat, 7 Mar 2009, Jonas Sicking wrote:
document.cookies can't change in the middle of an execution. I.e. a
script like:
a = document.cookie;
b = document.cookie;
alert(a === b);
will always show 'true'.
On Mon, 9 Mar 2009, Drew Wilson wrote:
Following up on this. I
That might work. Is it feasible for user agents to enforce limits on how
long a callback is allowed to run holding the lock? That way workers can't
starve normal pages from accessing their local storage.
-atw
On Sat, Mar 21, 2009 at 12:48 AM, Jonas Sicking jo...@sicking.cc wrote:
On Fri, Mar
I agree with Jeremy that the spec is currently unimplementable if we give
localStorage access to workers. I'd like to point out that workers who want
to access localStorage just need to send a message to their main window
breaks down for persistent workers (where you don't necessarily have an open
Thanks, Ian - this was great feedback.
On Fri, Mar 20, 2009 at 3:29 PM, Ian Hickson i...@hixie.ch wrote:
It is unclear to me why you would need access to the cookies from script
to do cookie-based authentication. Isn't the server the one that sets the
cookie and the one that uses it when it
, Mar 13, 2009 at 2:06 PM, Mark S. Miller erig...@google.com wrote:
On Wed, Mar 11, 2009 at 2:30 PM, Drew Wilson atwil...@google.com wrote:
Mark, I won't pretend to completely understand the use cases you're
describing as I'm not familiar with the prior work you've cited. But my
understanding
1 - 100 of 113 matches
Mail list logo
