Re: [whatwg] [Workers] CSP and SharedWorkers

[Jonas Sicking]

On Wed, Sep 25, 2013 at 8:00 PM, Kyle Huey  wrote:
> It's unclear how SharedWorkers should interact with Content Security
> Policies.  This came up during code review of the SharedWorker
> implementation in Gecko[0].  There was a public-webappsec thread[1] on this
> back in May that didn't really reach a conclusion and I'd like to drive
> towards one here.

For both Shared Workers and Service Workers is seems pretty clear that
we can't "inherit" the policy of the loading document. Any such
constructs would feel non-sensical in too many situations. So here I
think we should let the worker get its CSP from the script load
itself.

With Dedicated Workers we could in theory inherit the policy of
loading document, but it feels like that creates a lot of
inconsistency with Shared/Service Workers.

So my off-the-top-of-my-head suggestion would be to always let workers
get the CSP from the script load.

Though one question is what to do for workers loaded from blob:, data:
or filesystem:.

Maybe we should disallow shared/service workers from those types of
URLs, and make dedicated workers inherit the CSP when loaded from
those URLs. Though I could see shared workers from filesystem: being
useful.

What do implementations do with regards to linking 

Re: [whatwg] [Workers] CSP and SharedWorkers

[Jake Archibald]

On 26 September 2013 14:57, Jake Archibald  wrote:

> Note, this only covers registration. If http://example.com allows
> controllers from http://example.co.uk, and successfully calls
> registerServiceWorker("/*", "http://example.co.uk/service.js";), that
> controller will be used for all top-level fetches on http://example.com,
> and all fetches originating from documents on http://example.com,
> regardless of their CSP headers.
>

Oops, that's misleading, I mean the existing worker will be used for all
fetches even if the CSP rule of the page has changed to disallow
registering of that worker. The CSP of the page will still govern script
loading, XHR etc. If the page's CSP disallows a resource from a particular
URL, it won't consult the worker at all.

If the page requests an allowed url, and the worker serves up a response
(cached or otherwise) from a not-allowed url, CSP should block it.

(apologies for saying "controller" when I mean "service worker")

Re: [whatwg] [Workers] CSP and SharedWorkers

[Jake Archibald]

The registration of a Service Worker is currently only possible via DOM
call from an HTML document, so it makes sense for registration to be
governed by CSP.

There was some discussion here
https://github.com/slightlyoff/ServiceWorker/issues/46

So script-src would cover registration, but there was also suggestion that
x-domain controllers would be disallowed be default, and enabled by
script-src or perhaps an additional controller-src CSP directive.

Note, this only covers registration. If http://example.com allows
controllers from http://example.co.uk, and successfully calls
registerServiceWorker("/*", "http://example.co.uk/service.js";), that
controller will be used for all top-level fetches on http://example.com,
and all fetches originating from documents on http://example.com,
regardless of their CSP headers.

The browser will re-fetch (ugrade) and continue to use
http://example.co.uk/service.js even if the CSP rules are changed to
disallow controllers from that url. But if a page attempts to register a
new controller, the url must be allowed by CSP.

Does script-src apply to importScripts in Workers currently? The spec
doesn't explicitly mention it, feels like it should. I don't have a strong
opinion on whether Workers should have their own CSP.

Seems sensible for SharedWorkers to obey their own CSP headers and ignore
those of the constructing/registering page (except for the actual
constructing/registering of course). script-src should apply for
importScripts and imported scripts would use the rules of the top-level
SharedWorker. connect-src should also apply to fetch (
https://github.com/slightlyoff/ServiceWorker/blob/master/service_worker.ts#L193
).


On 26 September 2013 13:53, Anne van Kesteren  wrote:

> On Wed, Sep 25, 2013 at 11:00 PM, Kyle Huey  wrote:
> > Thoughts?
>
> What happens today for ? The load itself seems to be governed
> by the parent. Does the policy inherit into it? I feel like workers
> should work like  as they're essentially their own global
> objects.
>
>
> --
> http://annevankesteren.nl/
>

Re: [whatwg] [Workers] CSP and SharedWorkers

[Anne van Kesteren]

On Wed, Sep 25, 2013 at 11:00 PM, Kyle Huey  wrote:
> Thoughts?

What happens today for ? The load itself seems to be governed
by the parent. Does the policy inherit into it? I feel like workers
should work like  as they're essentially their own global
objects.


-- 
http://annevankesteren.nl/

[whatwg] [Workers] CSP and SharedWorkers

[Kyle Huey]

It's unclear how SharedWorkers should interact with Content Security
Policies.  This came up during code review of the SharedWorker
implementation in Gecko[0].  There was a public-webappsec thread[1] on this
back in May that didn't really reach a conclusion and I'd like to drive
towards one here.

Because CSPs are associated with a document, and multiple documents can
connect to the same SharedWorker, it is unclear which CSP should be used by
a SharedWorker.  Furthermore, there are plans to introduce Service Workers (
*née* Event Pages) which come into existence before any document exists for
the origin at all.

It seems like the best solution to this problem is to associate a CSP
directly with the worker from the headers served when the JS file for the
worker is shipped down.  Giving them their own CSP solves the "what CSP do
I use" problem.  I don't have strong feelings about whether or not we
should deny a page with a more liberal CSP from connecting to a
SharedWorker with a more strict CSP, but I suspect others might.

If we choose to do this we should also think about whether we should do the
same for regular workers.  The same JS file and the same headers being run
under different policies if you do Worker(foo.js) and SharedWorker(foo.js)
seems unexpected.  We could make regular workers default to the document
CSP if nothing is specified for backwards compatibility.

Thoughts?

- Kyle

[0] https://bugzilla.mozilla.org/show_bug.cgi?id=643325
[1] http://lists.w3.org/Archives/Public/public-webappsec/2013May/0054.html

Re: [whatwg] Workers feedback

[Ian Hickson]

On Fri, 4 Feb 2011, Glenn Maynard wrote:
> On Fri, Feb 4, 2011 at 6:43 PM, Ian Hickson  wrote:
> > 
> > All workers should run soon, not maybe in the future. Not running a 
> > worker should be an unusual circumstance. Errors that occur in unusual 
> > circumstances aren't errors that authors will check for.
> >
> > This dicussion comes from Chrome having a very small limit currently. 
> > It is my understanding that this limit is temporary and not 
> > representative of what the API will be like once widely implemented.
> 
> There will probably always be some limit, even if it's very high (eg. 
> 1024).

Well certainly there comes a point where there are simply too many workers 
for it to make sense.


> I think reasonable behavior when you exceed it is to throw an exception, 
> but the spec seems to disallow this.  Maybe that's why Chrome has the 
> queueing behavior in the first place.

Implementations are essentially allowed to do whatever they want in the 
face of hardware limitations like this; we refer to this as the hardware 
limitations clause:

   
http://www.whatwg.org/specs/web-apps/current-work/complete.html#hardwareLimitations


> >> Non-looping 0ms timers are common, to run code when the current call 
> >> finishes.
> >
> > Yeah, spec allows those fine.
> 
> I should have said "non-recursive".  That is, you can run a 0ms timer 
> from another timer without causing recursion, but you'll receive the 4ms 
> clamping unnecessarily.  It might be possible to avoid this while still 
> preventing 0ms looping timers from busy looping, but the spec prohibits 
> that.  (I could give an example of how this would happen, but I don't 
> think it's important enough to go into further for now.)

What's the use case?


On Sat, 5 Feb 2011, Samuel Ytterbrink wrote:
> 2011/2/5 Ian Hickson 
> > On Sat, 16 Oct 2010, Samuel Ytterbrink wrote:
> > >
> > > *What is the problem you are trying to solve?*
> > > To create sophisticated single file webpages.
> >
> > That's maybe a bit vaguer than I was hoping for when asking the 
> > question. :-)
> >
> > Why does it have to be a single file? Would multipart MIME be 
> > acceptable?
> >
> > A single file is a solution, not a problem. What is the problem?
> 
> Okey, I see the (implementation of the) web standards as the ultimate 
> framework. This makes it a great tool to create OS independent software 
> (if a browser is implementing the specs the same on both platforms). 
> Therefore its great if it supports as much of the usual behavior of 
> programs. I understand that this is a long process but.. almost every 
> thing is possible to inline with data-urls (wrote a simple script to do 
> this for me) but not web workers. And if you want to hand over a program 
> to a customer you want it to be 1 file, in many cases.

These standards are intended for the Web. You don't have to hand anything 
over other than a URL.


> The user case for my program is for a user that is a student that sits 
> at his/her schools computer. Having a DAISY book and needs to read it 
> with this app. The problem is:
> 
> that the user are not allowed to install new software therefor can't 
> install a 'real' player.
>
> that the user cant play it online because a book is to large
>
> that the File API right now you cant get hold of a whole folder 
> structure.

Ah. This isn't really a use case I think we should try to solve at the 
WHATWG. The WHATWG is specifically about improving the Web.


> > > [...] trying to build a more optimal standalone DAISY player (would 
> > > be nice if i could rewrite it with web workers).
> >
> > Now that's a problem. :-)
> >
> > It seems like what you need is a package mechanism, not necessarily a 
> > way to run workers without an external script.
>
> if i understand you correctly you suggests a module system for 
> javascript? That would be nice but still web workers are needed fore 
> more then that. And you can do module systems with a macro-compiler with 
> out changing the specs.

I just mean zip up all the files and give that to the user.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Workers feedback

[Glenn Maynard]

On Mon, Feb 14, 2011 at 5:02 AM, Ian Hickson  wrote:

> On Mon, 14 Feb 2011, Gregg Tavares (wrk) wrote:
> > > > >
> > > > > Web pages do not run in a different thread.
> > > >
> > > > Oh, sorry. I meant they run in a different process. At least in some
> > > > browsers.
> > >
> > > The goal here is interoperability with all browsers, not just some.
> >
> > I guess I don't understand. There are lots of things all browsers didn't
> > do at some point in the past. The video tag. CSS animation. The canvas
> > tag. Etc. We don't say because it hasn't been done yet therefore we
> > can't try or can't spec it.
>
> We do when one or more browser vendors say "we will not implement this",
> which is what happened here.
>

And having every *thread* running in a separate process wouldn't exactly be
a sane model, anyway, and that's what this would actually require.

-- 
Glenn Maynard

Re: [whatwg] Workers feedback

[Ian Hickson]

On Mon, 14 Feb 2011, Gregg Tavares (wrk) wrote:
> > > >
> > > > Web pages do not run in a different thread.
> > >
> > > Oh, sorry. I meant they run in a different process. At least in some 
> > > browsers.
> >
> > The goal here is interoperability with all browsers, not just some.
> 
> I guess I don't understand. There are lots of things all browsers didn't 
> do at some point in the past. The video tag. CSS animation. The canvas 
> tag. Etc. We don't say because it hasn't been done yet therefore we 
> can't try or can't spec it.

We do when one or more browser vendors say "we will not implement this", 
which is what happened here.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Workers feedback

[Gregg Tavares (wrk)]

On Mon, Feb 14, 2011 at 1:37 AM, Ian Hickson  wrote:

> On Fri, 11 Feb 2011, Gregg Tavares (wrk) wrote:
> > On Fri, Feb 11, 2011 at 5:45 PM, Ian Hickson  wrote:
> > > On Fri, 11 Feb 2011, Gregg Tavares (wrk) wrote:
> > > > > On Fri, 7 Jan 2011, Berend-Jan Wever wrote:
> > > > > >
> > > > > > 1) To give WebWorkers access to the DOM API so they can create
> their
> > > > > > own elements such as img, canvas, etc...?
> > > > >
> > > > > It's the API itself that isn't thread-safe, unfortunately.
> > > >
> > > > I didn't see the original thread but how is a WebWorker any different
> > > > from another webpage? Those run just fine in other threads and use
> the
> > > > DOM API.
> > >
> > > Web pages do not run in a different thread.
> >
> > Oh, sorry. I meant they run in a different process. At least in some
> > browsers.
>
> The goal here is interoperability with all browsers, not just some.
>

I guess I don't understand. There are lots of things all browsers didn't do
at some point in the past. The video tag. CSS animation. The canvas tag.
Etc. We don't say because it hasn't been done yet therefore we can't try or
can't spec it.


>
> --
> Ian Hickson   U+1047E)\._.,--,'``.fL
> http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>

Re: [whatwg] Workers feedback

[Ian Hickson]

On Fri, 11 Feb 2011, Gregg Tavares (wrk) wrote:
> On Fri, Feb 11, 2011 at 5:45 PM, Ian Hickson  wrote:
> > On Fri, 11 Feb 2011, Gregg Tavares (wrk) wrote:
> > > > On Fri, 7 Jan 2011, Berend-Jan Wever wrote:
> > > > >
> > > > > 1) To give WebWorkers access to the DOM API so they can create their
> > > > > own elements such as img, canvas, etc...?
> > > >
> > > > It's the API itself that isn't thread-safe, unfortunately.
> > >
> > > I didn't see the original thread but how is a WebWorker any different
> > > from another webpage? Those run just fine in other threads and use the
> > > DOM API.
> >
> > Web pages do not run in a different thread.
> 
> Oh, sorry. I meant they run in a different process. At least in some 
> browsers.

The goal here is interoperability with all browsers, not just some.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Workers feedback

[Drew Wilson]

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 that domain which means they can't be used as a
worker (doing long-lived operations). But I agree, there's some value in
having the full set of page APIs available.

-atw

On Fri, Feb 11, 2011 at 5:58 PM, Gregg Tavares (wrk) wrote:

> On Fri, Feb 11, 2011 at 5:45 PM, Ian Hickson  wrote:
>
> > On Fri, 11 Feb 2011, Gregg Tavares (wrk) wrote:
> > > > On Fri, 7 Jan 2011, Berend-Jan Wever wrote:
> > > > >
> > > > > 1) To give WebWorkers access to the DOM API so they can create
> their
> > > > > own elements such as img, canvas, etc...?
> > > >
> > > > It's the API itself that isn't thread-safe, unfortunately.
> > >
> > > I didn't see the original thread but how is a WebWorker any different
> > > from another webpage? Those run just fine in other threads and use the
> > > DOM API.
> >
> > Web pages do not run in a different thread.
> >
>
> Oh, sorry. I meant they run in a different process. At least in some
> browsers.
>
>
> >
> > --
> > Ian Hickson   U+1047E)\._.,--,'``.fL
> > http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
> > Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
> >
>

Re: [whatwg] Workers feedback

[Gregg Tavares (wrk)]

On Fri, Feb 11, 2011 at 5:45 PM, Ian Hickson  wrote:

> On Fri, 11 Feb 2011, Gregg Tavares (wrk) wrote:
> > > On Fri, 7 Jan 2011, Berend-Jan Wever wrote:
> > > >
> > > > 1) To give WebWorkers access to the DOM API so they can create their
> > > > own elements such as img, canvas, etc...?
> > >
> > > It's the API itself that isn't thread-safe, unfortunately.
> >
> > I didn't see the original thread but how is a WebWorker any different
> > from another webpage? Those run just fine in other threads and use the
> > DOM API.
>
> Web pages do not run in a different thread.
>

Oh, sorry. I meant they run in a different process. At least in some
browsers.


>
> --
> Ian Hickson   U+1047E)\._.,--,'``.fL
> http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>

Re: [whatwg] Workers feedback

[Ian Hickson]

On Fri, 11 Feb 2011, Gregg Tavares (wrk) wrote:
> > On Fri, 7 Jan 2011, Berend-Jan Wever wrote:
> > >
> > > 1) To give WebWorkers access to the DOM API so they can create their 
> > > own elements such as img, canvas, etc...?
> >
> > It's the API itself that isn't thread-safe, unfortunately.
> 
> I didn't see the original thread but how is a WebWorker any different 
> from another webpage? Those run just fine in other threads and use the 
> DOM API.

Web pages do not run in a different thread.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Workers feedback

[Gregg Tavares (wrk)]

On Fri, Feb 4, 2011 at 3:43 PM, Ian Hickson  wrote:

> On Sat, 16 Oct 2010, Samuel Ytterbrink wrote:
> >
> > *What is the problem you are trying to solve?*
> > To create sophisticated single file webpages.
>
> That's maybe a bit vaguer than I was hoping for when asking the question.
> :-)
>
> Why does it have to be a single file? Would multipart MIME be acceptable?
>
> A single file is a solution, not a problem. What is the problem?
>
>
> > [...] trying to build a more optimal standalone DAISY player (would be
> > nice if i could rewrite it with web workers).
>
> Now that's a problem. :-)
>
> It seems like what you need is a package mechanism, not necessarily a way
> to run workers without an external script.
>
>
> On Fri, 15 Oct 2010, Jonas Sicking wrote:
> >
> > Allowing both blob URLs and data URLs for workers sounds like a great
> > idea.
>
> I expect we'll add these in due course, probably around the same time we
> add cross-origin workers. (We didn't add them before because exactly how
> we do them depends on how we determine origins.)
>
>
> On Sat, 16 Oct 2010, Samuel Ytterbrink wrote:
> >
> > But then i got another problem, why is not
> > "file:///some_directory_where_the_html_are/" not the same domain as
> >
> "file:///some_directory_where_the_html_are/child_directory_with_ajax_stuff/".
> > I understand if it was not okay to go closer to root when ajax,
> > "file:///where_all_secrete_stuff_are/" or "/../../".
>
> That's not a Web problem. I recommend contacting your browser vendor about
> it. (It's probably security-related.)
>
>
> On Thu, 30 Dec 2010, Glenn Maynard wrote:
> > On Thu, Dec 30, 2010 at 7:11 PM, Ian Hickson  wrote:
> > >
> > > Unfortunately we can't really require immediate failure, since there'd
> > > be no way to test it or to prove that it wasn't implemented -- a user
> > > agent could always just say "oh, it's just that we take a long time to
> > > launch the worker sometimes". (Performance can be another hardware
> > > limitation.)
> >
> > Preferably, if a Worker is successfully created, the worker thread
> > starting must not block on user code taking certain actions, like
> > closing other threads.
>
> How can you tell the difference between "the thread takes 3 seconds to
> start" and "the thread waits for the user to close a thread", if it takes
> 3 seconds for the user to close a thread?
>
> My point is from a black-box perspective, one can never firmly say that
> it's not just the browser being slow to start the thread. And we can't
> disallow the browser from being slow.
>
>
> > That doesn't mean it needs to start immediately, but if I start a thread
> > and then do nothing, it's very bad for the thread to sit in limbo
> > forever because the browser expects me to take some action, without
> > anything to tell me so.
>
> I don't disagree that it's bad. Hopefully browser vendors will agree and
> this problem will go away.
>
>
> > If queuing is really necessary, please at least give us a way to query
> > whether a worker is queued.
>
> It's queued if you asked it to start and it hasn't yet started.
>
>
> On Fri, 31 Dec 2010, Aryeh Gregor wrote:
> >
> > I've long thought that HTML5 should specify hardware limitations more
> > precisely.
>
> We can't, because it depends on the hardware. For example, we can't say
> "you must be able to allocate a 1GB string" because the system might only
> have 500MB of storage.
>
>
> > Clearly it can't cover all cases, and some sort of general escape clause
> > will always be needed -- but in cases where limits are likely to be low
> > enough that authors might run into them, the limit should really be
> > standardized.
>
> It's not much of a standardised limit if there's still an escape clause.
>
> I'm happy to put recommendations in if we have data showing certain
> specific limits are needed for interop with real content.
>
>
> > > Unfortunately we can't really require immediate failure, since there'd
> > > be no way to test it or to prove that it wasn't implemented -- a user
> > > agent could always just say "oh, it's just that we take a long time to
> > > launch the worker sometimes". (Performance can be another hardware
> > > limitation.)
> >
> > In principle this is so, but in practice it's not.  In real life, you
> > can easily tell an algorithm that runs the first sixteen workers and
> > then stalls any further ones until one of the early ones exit, from an
> > algorithm that just takes a while to launch workers sometimes.  I think
> > it would be entirely reasonable and would help interoperability in
> > practice if HTML5 were to require that the UA must run all pending
> > workers in some manner that doesn't allow starvation, and that if it
> > can't do so, it must return an error rather than accepting a new worker.
> > Failure to return an error should mean that the worker can be run soon,
> > in a predictable timeframe, not maybe at some indefinite point in the
> > future.
>
> All workers should run soon, not maybe in the future. 

Re: [whatwg] Workers feedback

[Glenn Maynard]

On Fri, Feb 4, 2011 at 6:43 PM, Ian Hickson  wrote:
> My point is from a black-box perspective, one can never firmly say that
> it's not just the browser being slow to start the thread. And we can't
> disallow the browser from being slow.

I don't think a black-box test suite can ever generally prove compliance
against a dishonest vendor.

> All workers should run soon, not maybe in the future. Not running a
> worker should be an unusual circumstance. Errors that occur in unusual
> circumstances aren't errors that authors will check for.
>
> This dicussion comes from Chrome having a very small limit currently. It
> is my understanding that this limit is temporary and not representative
> of what the API will be like once widely implemented.

There will probably always be some limit, even if it's very high (eg.
1024).  I think reasonable behavior when you exceed it is to throw an
exception, but the spec seems to disallow this.  Maybe that's why Chrome has
the queueing behavior in the first place.

Should there be a step early in 4.7.2/4.7.3 to permit browsers to throw an
exception if the thread creation isn't allowed for any reason (without
having any requirement to do so)?

>> Non-looping 0ms timers are common, to run code when the current call
>> finishes.
>
> Yeah, spec allows those fine.

I should have said "non-recursive".  That is, you can run a 0ms timer from
another timer without causing recursion, but you'll receive the 4ms clamping
unnecessarily.  It might be possible to avoid this while still preventing
0ms looping timers from busy looping, but the spec prohibits that.  (I could
give an example of how this would happen, but I don't think it's important
enough to go into further for now.)

-- 
Glenn Maynard

[whatwg] Workers feedback

[Ian Hickson]

On Sat, 16 Oct 2010, Samuel Ytterbrink wrote:
>
> *What is the problem you are trying to solve?*
> To create sophisticated single file webpages.

That's maybe a bit vaguer than I was hoping for when asking the question. :-)

Why does it have to be a single file? Would multipart MIME be acceptable?

A single file is a solution, not a problem. What is the problem?


> [...] trying to build a more optimal standalone DAISY player (would be 
> nice if i could rewrite it with web workers).

Now that's a problem. :-)

It seems like what you need is a package mechanism, not necessarily a way 
to run workers without an external script.


On Fri, 15 Oct 2010, Jonas Sicking wrote:
>
> Allowing both blob URLs and data URLs for workers sounds like a great 
> idea.

I expect we'll add these in due course, probably around the same time we 
add cross-origin workers. (We didn't add them before because exactly how 
we do them depends on how we determine origins.)


On Sat, 16 Oct 2010, Samuel Ytterbrink wrote:
> 
> But then i got another problem, why is not
> "file:///some_directory_where_the_html_are/" not the same domain as
> "file:///some_directory_where_the_html_are/child_directory_with_ajax_stuff/".
> I understand if it was not okay to go closer to root when ajax,
> "file:///where_all_secrete_stuff_are/" or "/../../".

That's not a Web problem. I recommend contacting your browser vendor about 
it. (It's probably security-related.)


On Thu, 30 Dec 2010, Glenn Maynard wrote:
> On Thu, Dec 30, 2010 at 7:11 PM, Ian Hickson  wrote:
> > 
> > Unfortunately we can't really require immediate failure, since there'd 
> > be no way to test it or to prove that it wasn't implemented -- a user 
> > agent could always just say "oh, it's just that we take a long time to 
> > launch the worker sometimes". (Performance can be another hardware 
> > limitation.)
> 
> Preferably, if a Worker is successfully created, the worker thread 
> starting must not block on user code taking certain actions, like 
> closing other threads.

How can you tell the difference between "the thread takes 3 seconds to 
start" and "the thread waits for the user to close a thread", if it takes 
3 seconds for the user to close a thread?

My point is from a black-box perspective, one can never firmly say that 
it's not just the browser being slow to start the thread. And we can't 
disallow the browser from being slow.


> That doesn't mean it needs to start immediately, but if I start a thread 
> and then do nothing, it's very bad for the thread to sit in limbo 
> forever because the browser expects me to take some action, without 
> anything to tell me so.

I don't disagree that it's bad. Hopefully browser vendors will agree and 
this problem will go away.


> If queuing is really necessary, please at least give us a way to query 
> whether a worker is queued.

It's queued if you asked it to start and it hasn't yet started.


On Fri, 31 Dec 2010, Aryeh Gregor wrote:
> 
> I've long thought that HTML5 should specify hardware limitations more 
> precisely.

We can't, because it depends on the hardware. For example, we can't say 
"you must be able to allocate a 1GB string" because the system might only 
have 500MB of storage.


> Clearly it can't cover all cases, and some sort of general escape clause 
> will always be needed -- but in cases where limits are likely to be low 
> enough that authors might run into them, the limit should really be 
> standardized.

It's not much of a standardised limit if there's still an escape clause.

I'm happy to put recommendations in if we have data showing certain 
specific limits are needed for interop with real content.


> > Unfortunately we can't really require immediate failure, since there'd 
> > be no way to test it or to prove that it wasn't implemented -- a user 
> > agent could always just say "oh, it's just that we take a long time to 
> > launch the worker sometimes". (Performance can be another hardware 
> > limitation.)
> 
> In principle this is so, but in practice it's not.  In real life, you 
> can easily tell an algorithm that runs the first sixteen workers and 
> then stalls any further ones until one of the early ones exit, from an 
> algorithm that just takes a while to launch workers sometimes.  I think 
> it would be entirely reasonable and would help interoperability in 
> practice if HTML5 were to require that the UA must run all pending 
> workers in some manner that doesn't allow starvation, and that if it 
> can't do so, it must return an error rather than accepting a new worker.  
> Failure to return an error should mean that the worker can be run soon, 
> in a predictable timeframe, not maybe at some indefinite point in the 
> future.

All workers should run soon, not maybe in the future. Not running a 
worker should be an unusual circumstance. Errors that occur in unusual 
circumstances aren't errors that authors will check for.

This dicussion comes from Chrome having a very small limit currently. I

Re: [whatwg] Workers: what should happen when exceeding worker limit?

[Aryeh Gregor]

On Thu, Dec 30, 2010 at 7:11 PM, Ian Hickson  wrote:
> That's a hardware limitation, and as such is something we tend to leave up
> to the user agents. In practice, it's often the case that user agents are
> very constrained in how they can deal with hardware limitations (e.g. if
> the user agent cannot allocate more memory, then it might not be able to
> allocate memory to fire an exception, or to keep track of the worker to
> run it later), and therefore we tend to leave that open. So long as the
> limitations are big enough that most pages don't run into them, it doesn't
> really matter -- a user agent with a compatibility issue can almost
> always just increase the limits if pages would otherwise break!

That doesn't help authors whose pages break unpredictably.  I've long
thought that HTML5 should specify hardware limitations more precisely.
 Clearly it can't cover all cases, and some sort of general escape
clause will always be needed -- but in cases where limits are likely
to be low enough that authors might run into them, the limit should
really be standardized.  Compare to UAX #9's limit of 61 for explicit
embedding depth.  Similarly, there's no reason UAs shouldn't
standardize on maximum URL length -- inconsistency there has caused
interoperability problems (mainly IE being too low).  The goal should
be the same code working the same in all browsers, without authors
having to learn how each browser behaves in corner cases like lots of
workers.

> Unfortunately we can't really require immediate failure, since there'd be
> no way to test it or to prove that it wasn't implemented -- a user agent
> could always just say "oh, it's just that we take a long time to launch
> the worker sometimes". (Performance can be another hardware limitation.)

In principle this is so, but in practice it's not.  In real life, you
can easily tell an algorithm that runs the first sixteen workers and
then stalls any further ones until one of the early ones exit, from an
algorithm that just takes a while to launch workers sometimes.  I
think it would be entirely reasonable and would help interoperability
in practice if HTML5 were to require that the UA must run all pending
workers in some manner that doesn't allow starvation, and that if it
can't do so, it must return an error rather than accepting a new
worker.  Failure to return an error should mean that the worker can be
run soon, in a predictable timeframe, not maybe at some indefinite
point in the future.

Re: [whatwg] Workers: what should happen when exceeding worker limit?

[Glenn Maynard]

On Thu, Dec 30, 2010 at 7:11 PM, Ian Hickson  wrote:
> I guess the simplest answer is "don't use more than 16 workers". There's
> really not much point in doing so anyway, since most systems don't have 16
> cores today. (This will naturally change in the future, but then so will
> the limits.)

This logic is only valid if threads are exclusively used for pushing
CPU-bound work to other cores.  They're not; it's perfectly normal to
create more threads than CPU cores, both for disk I/O-bounds threads
and network-bound threads.

> Unfortunately we can't really require immediate failure, since there'd be
> no way to test it or to prove that it wasn't implemented -- a user agent
> could always just say "oh, it's just that we take a long time to launch
> the worker sometimes". (Performance can be another hardware limitation.)

Preferably, if a Worker is successfully created, the worker thread
starting must not block on user code taking certain actions, like
closing other threads.  That doesn't mean it needs to start
immediately, but if I start a thread and then do nothing, it's very
bad for the thread to sit in limbo forever because the browser expects
me to take some action, without anything to tell me so.

Timeouts are an ugly, brittle workaround.  They'd have to be
implemented for every created thread--even if you aren't creating many
threads, another component on the page may be.  Timeouts would need to
be high enough to not cause false positives even during swapping,
which means a delay long enough to be visible to the user.  I'd also
expect unpredictable behavior on mobile browsers; if the whole browser
is suspended after creating a thread, timeouts may expire even though
the thread was starting normally.

We need sensible, predictable error detection, not silent queuing.  I
can't think of any case where workers being queued is preferable to
failing outright.  If queuing is really necessary, please at least
give us a way to query whether a worker is queued.  That's far from
ideal--it would be hard to test user code properly--but at least we
could wrap worker creation to throw an exception if our worker threads
are being queued.

-- 
Glenn Maynard

Re: [whatwg] Workers: what should happen when exceeding worker limit?

[Ian Hickson]

On Thu, 23 Sep 2010, Ivan Kozik wrote:
>
> What should happen when instantiating a Worker that cannot be started 
> because of the limit on the number of workers?

That's a hardware limitation, and as such is something we tend to leave up 
to the user agents. In practice, it's often the case that user agents are 
very constrained in how they can deal with hardware limitations (e.g. if 
the user agent cannot allocate more memory, then it might not be able to 
allocate memory to fire an exception, or to keep track of the worker to 
run it later), and therefore we tend to leave that open. So long as the 
limitations are big enough that most pages don't run into them, it doesn't 
really matter -- a user agent with a compatibility issue can almost 
always just increase the limits if pages would otherwise break!


> Chrome 6 and Chromium 7.0.532.0 (60255) put the 17th worker in a queue, 
> to be created when some existing worker terminates.  This queue seems to 
> be limitless in size (or at least it is large).  In Opera 10.70 (9049), 
> instantiating the 17th Worker throws "Error: QUOTA_EXCEEDED_ERR".

I guess the simplest answer is "don't use more than 16 workers". There's 
really not much point in doing so anyway, since most systems don't have 16 
cores today. (This will naturally change in the future, but then so will 
the limits.)


> I'd much prefer that it failed immediately, rather than being put in a 
> queue.

Unfortunately we can't really require immediate failure, since there'd be 
no way to test it or to prove that it wasn't implemented -- a user agent 
could always just say "oh, it's just that we take a long time to launch 
the worker sometimes". (Performance can be another hardware limitation.)


> I use a SharedWorker as an enhancement, and I don't want to implement a 
> timeout for the Worker spawning (I'd rather have it fail, so that I can 
> immediately do something else).  I can avoid spawning more than 16 
> workers, but I never know if another tab has already created enough 
> workers to exhaust the global worker limit (64 in Chrome, ~118 in 
> Opera).  And if I really want to spawn the worker, I can always try 
> spawning it again soon.

If you have performance constraints, then you should just use timeouts to 
test whether the worker started -- that way you'll do the worker-less 
fallback behaviour regardless of whether the timeout fired because workers 
are just slow on the user's computer or because there are no more worker 
slots available.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Workers: what should happen when exceeding worker limit?

[Dmitry Titov]

Thanks for the feedback! I'd love to know more about your use case (if
possible), since it may motivate further thinking on these limits...

Indeed, the option of immediately throwing was also considered. It didn't
look obviously better for the following reasons (I may forget something, but
that's what I remember):

1. Workers are asynchronous so even a successful (not-queued) start will
incur some unspecified delay - the Worker object will be created instantly
but actual initial script or postMessage handlers won't be invoked for some
time. This time varies (can be seconds on a netbook with many opened tabs)
so the page can not build expectations on "instant start" anyways. This
reduces the benefit of "knowing right away that worker can not start".  In
your case, for example, you might want a timer anyways, to close the worker
and use the alternative route that you seem to have.

2. There are use cases which would use workers to perform
certain operation and then close the workers. Typical example would be some
operation that is longer then "instant" so the page UI would like to be
responsive with Cancel button ready. Once the operation completes, the
workers are left to terminate and die. This can take a moment and the page
does not know when previous workers actually terminate. If the page can not
create new workers during this finalization time, it creates more complexity
for it. Having a queue solves those edge conditions nicely.

3. The current Chrome limits of 16 per page and 64 total are much lower then
we would like them to be, due to implementation limits we hope to remove in
the future. These limits should be high enough to realistically never prompt
app developers to consider coding around them. Basically creating multiple
workers should only have a limit related to memory. It might happen that
current queues will happen to be an implementation detail of Chrome for some
time and does not need to be reflected in the spec.

4. If we are to create a mechanism that provides useful guarantees around
timely execution in multi-thread environment, I believe we'd have
to specify much more complex api, providing fair scheduling, guarantee
against starvation, some real-time support etc - but we are not there yet
:-)

5. Normally, the JS APIs that can return "quota exceeded" errors typically
imply mechanisms for granting/monitoring/revoking the said quotas, perhaps
with UI for the user, as Database API does for example. No matter how
initial quotas are set, there will be the app that legitimately needs a lot
of resources while we also don't want to give the same to any random page.
I think we don't have enough evidence yet to consider worker creation in the
same category, but if it comes to that at some point, the exception from
Workers constructor probably won't be enough.

Again, knowing your use case in more details can help in the future design
steps here.

Dmitry

On Thu, Sep 23, 2010 at 2:06 AM, Ivan Kozik  wrote:

> What should happen when instantiating a Worker that cannot be started
> because of the limit on the number of workers?  Chrome 6 and Chromium
> 7.0.532.0 (60255) put the 17th worker in a queue, to be created when
> some existing worker terminates.  This queue seems to be limitless in
> size (or at least it is large).  In Opera 10.70 (9049), instantiating
> the 17th Worker throws "Error: QUOTA_EXCEEDED_ERR".
>
> I'd much prefer that it failed immediately, rather than being put in a
> queue.  I use a SharedWorker as an enhancement, and I don't want to
> implement a timeout for the Worker spawning (I'd rather have it fail,
> so that I can immediately do something else).  I can avoid spawning
> more than 16 workers, but I never know if another tab has already
> created enough workers to exhaust the global worker limit (64 in
> Chrome, ~118 in Opera).  And if I really want to spawn the worker, I
> can always try spawning it again soon.
>
> This message describes why Chromium queues up excessive workers:
> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-July/020865.html
>
> I'm not sure that making it work like a "sea of XHRs" is the right
> thing, for two reasons:
> 1) Workers often stay running for a long time; XHRs are usually
> short-lived.
> 2) Most web applications don't expect to definitely have access to a
> Worker, so they work around it by running code in the page instead of
> the worker.  This same code path could be used when the worker limit
> is exhausted.  With XHRs, there's generally no workaround: you need
> the data, no matter what.
>
> Here's a crude test page that instantiates 17 workers:
> 
> 
> 
> var workers = [];
> for(var i=0; i < 17; i++) {
>  try {
>workers.push(new Worker('empty.js'));
>document.getElementById('log').innerHTML +=
>'Worker #' + i + ' instantiated.
';
>  } catch(e) {
>document.getElementById('log').innerHTML += e.toString() + '
';
>  }
> }
> 
>
> Any thoughts would be appreciated.
>
> Thanks,
>
> Ivan
>

[whatwg] Workers: what should happen when exceeding worker limit?

[Ivan Kozik]

What should happen when instantiating a Worker that cannot be started
because of the limit on the number of workers?  Chrome 6 and Chromium
7.0.532.0 (60255) put the 17th worker in a queue, to be created when
some existing worker terminates.  This queue seems to be limitless in
size (or at least it is large).  In Opera 10.70 (9049), instantiating
the 17th Worker throws "Error: QUOTA_EXCEEDED_ERR".

I'd much prefer that it failed immediately, rather than being put in a
queue.  I use a SharedWorker as an enhancement, and I don't want to
implement a timeout for the Worker spawning (I'd rather have it fail,
so that I can immediately do something else).  I can avoid spawning
more than 16 workers, but I never know if another tab has already
created enough workers to exhaust the global worker limit (64 in
Chrome, ~118 in Opera).  And if I really want to spawn the worker, I
can always try spawning it again soon.

This message describes why Chromium queues up excessive workers:
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-July/020865.html

I'm not sure that making it work like a "sea of XHRs" is the right
thing, for two reasons:
1) Workers often stay running for a long time; XHRs are usually short-lived.
2) Most web applications don't expect to definitely have access to a
Worker, so they work around it by running code in the page instead of
the worker.  This same code path could be used when the worker limit
is exhausted.  With XHRs, there's generally no workaround: you need
the data, no matter what.

Here's a crude test page that instantiates 17 workers:



var workers = [];
for(var i=0; i < 17; i++) {
  try {
workers.push(new Worker('empty.js'));
document.getElementById('log').innerHTML +=
'Worker #' + i + ' instantiated.
';
  } catch(e) {
document.getElementById('log').innerHTML += e.toString() + '
';
  }
}


Any thoughts would be appreciated.

Thanks,

Ivan

Re: [whatwg] Workers: What can be done in a worker after call to close()?

[Ian Hickson]

On Thu, 1 Apr 2010, Dmitry Titov wrote:
>
> I think the only change to the spec here would be the removal of the 3rd
> line in the description of what close() does, so the ports are still
> functional, at least for posting from the worker: [...]

I'm fine with doing this.


> Not sure about onclose indeed...  Perhaps we can use some time to see if 
> developers will request something like this more explicitly, then we 
> could think about it more.

There's no onclose in the spec currently. It was removed to avoid exposing 
GC behaviour.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Workers: What can be done in a worker after call to close()?

[Dmitry Titov]

Thanks Jonas!

So there is somewhat of a consensus on close() to effectively let a worker
run normally until the exit from the current JS fragment. It makes sense for
us as well.

I think the only change to the spec here would be the removal of the 3rd
line in the description of what close() does, so the ports are still
functional, at least for posting from the worker:

When a script invokes the close() method on a WorkerGlobalScope object, the
> user agent must run the following steps (atomically):


> Discard any tasks that have been added to the event loop's task queues.

Set the worker's WorkerGlobalScope object's closing flag to true. (This
> prevents any further tasks from being queued.)

Disentangle all the ports in the list of the worker's ports.


.. which probably is not a big deal (hope Ian will chime in on this).

Not sure about onclose indeed...  Perhaps we can use some time to see if
developers will request something like this more explicitly, then we could
think about it more.

Dmitry

On Thu, Apr 1, 2010 at 3:31 PM, Jonas Sicking  wrote:

> On Wed, Mar 31, 2010 at 10:03 AM, ben turner 
> wrote:
> > Hi,
> >
> > When implementing the close() function for Firefox we chose to set the
> > closing flag and clear pending events only. As the worker script is
> > calling close() on itself we figured that the worker should retain
> > maximum functionality until it has finished execution (otherwise it
> > could just not call close() and rely on some kind of postMessage() and
> > terminate() combo). Therefore we do not enforce any timeout for the
> > currently executing script and we continue to allow postMessage()
> > calls and synchronous XHR to proceed. Since the closing flag is set in
> > response to close() the worker is guaranteed to finish as soon as the
> > currently running script finishes. We always enforce a timeout for any
> > code that runs in response to the close event that gets fired after
> > the current script finishes, though.
> >
> > If the code that calls close() never returns (like the while(1) { }
> > example above) then the worker will never finish, as pointed out
> > above, but that's no different than having a worker script that
> > consists only of a while(1) { } loop and we don't think it's important
> > to prevent. If a worker script is written in this way then a
> > terminate() call is still a valid solution.
> >
> > Also, since we try to retain maximum functionality after close() we
> > also allow errors to propagate as shown above.
> >
> > If anyone is curious the basic strategy we use in response to close
> > functions (like close(), terminate(), and for UA-generated events like
> > when the main worker object is GC'd) can be found in the following
> > table:
> >
> >
> http://mxr.mozilla.org/mozilla-central/source/dom/src/threads/nsDOMWorker.h#202
>
> For what it's worth, I think the behavior that firefox has makes a lot
> of sense and I think it should be mandated by the spec. (I know, big
> shocker :) )
>
> The one thing that we do and that is somewhat iffy is the close event.
> Ben actually gets it a bit wrong in the description above. This is how
> it works:
>
> We fire the close event handler in four situations:
>
> * After close() is called by the worker, once it finishes its current
> execution.
> * After terminate() is called from outside the worker and any code
> running has been aborted.
> * If the worker is garbage collected.
> * Once the user leaves the page (or specifically, once the page falls
> out of the bfcache).
>
> Only in the last case do we give the close handler a time limit, after
> which any currently running close handler is aborted and no more close
> handlers are run.
>
> Though of course the user can leave the page *while* the close event
> is getting fired. If so, we start the time limit at that point.
>
> The iffy part is the third bullet above, since it exposes GC behavior.
> This is very unfortunate indeed and because of it I feel that our
> implementation is somewhat experimental.
>
> We could simply not fire the close event in that case, however this
> would seem to reduce the usefulness of the close event quite a bit.
>
> So I think for now I don't care if the close event is put in the spec
> or not. But I wanted to let you know what we're doing. We don't
> currently have any plans to remove it.
>
> / Jonas
>

Re: [whatwg] Workers: What can be done in a worker after call to close()?

[Jonas Sicking]

On Thu, Apr 1, 2010 at 4:40 PM, Drew Wilson  wrote:
> How does the GC-initiated close() event work in Firefox, in the case of a
> fire-and-forget worker?
> For example:
> foo.html:
> 
> new Worker("forget.js");
> 
> forget.js:
> self.setInterval(function() { ...do something...}, 1000);
> In this case, it seems incorrect to ever fire a close() event until the
> parent window leaves the bfcache. I'm guessing you must do something to
> prevent the worker object from being GC'd in the case that there's pending
> activity in the worker?

Indeed, such a worker would never be GC'd. Similarly a worker that
simply contains a infinite while(1) {} loop, or a worker that
continuously starts XHR requests at the end of the previous XHR
requests.

This isn't really related to the 'close' event though, but rather
worker lifetime.

The 'close' event would still fire at some point. Either if someone
calls terminate() from the outside, or once the user navigates away
from the page that started the worker.

/ Jonas

Re: [whatwg] Workers: What can be done in a worker after call to close()?

[Drew Wilson]

How does the GC-initiated close() event work in Firefox, in the case of a
fire-and-forget worker?

For example:

foo.html:

new Worker("forget.js");


forget.js:
self.setInterval(function() { ...do something...}, 1000);

In this case, it seems incorrect to ever fire a close() event until the
parent window leaves the bfcache. I'm guessing you must do something to
prevent the worker object from being GC'd in the case that there's pending
activity in the worker?

-atw

On Thu, Apr 1, 2010 at 3:31 PM, Jonas Sicking  wrote:

> On Wed, Mar 31, 2010 at 10:03 AM, ben turner 
> wrote:
> > Hi,
> >
> > When implementing the close() function for Firefox we chose to set the
> > closing flag and clear pending events only. As the worker script is
> > calling close() on itself we figured that the worker should retain
> > maximum functionality until it has finished execution (otherwise it
> > could just not call close() and rely on some kind of postMessage() and
> > terminate() combo). Therefore we do not enforce any timeout for the
> > currently executing script and we continue to allow postMessage()
> > calls and synchronous XHR to proceed. Since the closing flag is set in
> > response to close() the worker is guaranteed to finish as soon as the
> > currently running script finishes. We always enforce a timeout for any
> > code that runs in response to the close event that gets fired after
> > the current script finishes, though.
> >
> > If the code that calls close() never returns (like the while(1) { }
> > example above) then the worker will never finish, as pointed out
> > above, but that's no different than having a worker script that
> > consists only of a while(1) { } loop and we don't think it's important
> > to prevent. If a worker script is written in this way then a
> > terminate() call is still a valid solution.
> >
> > Also, since we try to retain maximum functionality after close() we
> > also allow errors to propagate as shown above.
> >
> > If anyone is curious the basic strategy we use in response to close
> > functions (like close(), terminate(), and for UA-generated events like
> > when the main worker object is GC'd) can be found in the following
> > table:
> >
> >
> http://mxr.mozilla.org/mozilla-central/source/dom/src/threads/nsDOMWorker.h#202
>
> For what it's worth, I think the behavior that firefox has makes a lot
> of sense and I think it should be mandated by the spec. (I know, big
> shocker :) )
>
> The one thing that we do and that is somewhat iffy is the close event.
> Ben actually gets it a bit wrong in the description above. This is how
> it works:
>
> We fire the close event handler in four situations:
>
> * After close() is called by the worker, once it finishes its current
> execution.
> * After terminate() is called from outside the worker and any code
> running has been aborted.
> * If the worker is garbage collected.
> * Once the user leaves the page (or specifically, once the page falls
> out of the bfcache).
>
> Only in the last case do we give the close handler a time limit, after
> which any currently running close handler is aborted and no more close
> handlers are run.
>
> Though of course the user can leave the page *while* the close event
> is getting fired. If so, we start the time limit at that point.
>
> The iffy part is the third bullet above, since it exposes GC behavior.
> This is very unfortunate indeed and because of it I feel that our
> implementation is somewhat experimental.
>
> We could simply not fire the close event in that case, however this
> would seem to reduce the usefulness of the close event quite a bit.
>
> So I think for now I don't care if the close event is put in the spec
> or not. But I wanted to let you know what we're doing. We don't
> currently have any plans to remove it.
>
> / Jonas
>

Re: [whatwg] Workers: What can be done in a worker after call to close()?

[Jonas Sicking]

On Wed, Mar 31, 2010 at 10:03 AM, ben turner  wrote:
> Hi,
>
> When implementing the close() function for Firefox we chose to set the
> closing flag and clear pending events only. As the worker script is
> calling close() on itself we figured that the worker should retain
> maximum functionality until it has finished execution (otherwise it
> could just not call close() and rely on some kind of postMessage() and
> terminate() combo). Therefore we do not enforce any timeout for the
> currently executing script and we continue to allow postMessage()
> calls and synchronous XHR to proceed. Since the closing flag is set in
> response to close() the worker is guaranteed to finish as soon as the
> currently running script finishes. We always enforce a timeout for any
> code that runs in response to the close event that gets fired after
> the current script finishes, though.
>
> If the code that calls close() never returns (like the while(1) { }
> example above) then the worker will never finish, as pointed out
> above, but that's no different than having a worker script that
> consists only of a while(1) { } loop and we don't think it's important
> to prevent. If a worker script is written in this way then a
> terminate() call is still a valid solution.
>
> Also, since we try to retain maximum functionality after close() we
> also allow errors to propagate as shown above.
>
> If anyone is curious the basic strategy we use in response to close
> functions (like close(), terminate(), and for UA-generated events like
> when the main worker object is GC'd) can be found in the following
> table:
>
> http://mxr.mozilla.org/mozilla-central/source/dom/src/threads/nsDOMWorker.h#202

For what it's worth, I think the behavior that firefox has makes a lot
of sense and I think it should be mandated by the spec. (I know, big
shocker :) )

The one thing that we do and that is somewhat iffy is the close event.
Ben actually gets it a bit wrong in the description above. This is how
it works:

We fire the close event handler in four situations:

* After close() is called by the worker, once it finishes its current execution.
* After terminate() is called from outside the worker and any code
running has been aborted.
* If the worker is garbage collected.
* Once the user leaves the page (or specifically, once the page falls
out of the bfcache).

Only in the last case do we give the close handler a time limit, after
which any currently running close handler is aborted and no more close
handlers are run.

Though of course the user can leave the page *while* the close event
is getting fired. If so, we start the time limit at that point.

The iffy part is the third bullet above, since it exposes GC behavior.
This is very unfortunate indeed and because of it I feel that our
implementation is somewhat experimental.

We could simply not fire the close event in that case, however this
would seem to reduce the usefulness of the close event quite a bit.

So I think for now I don't care if the close event is put in the spec
or not. But I wanted to let you know what we're doing. We don't
currently have any plans to remove it.

/ Jonas

Re: [whatwg] Workers: What can be done in a worker after call to close()?

[Dmitry Titov]

I see, thanks for the details!

This makes sense - you let the worker run unrestricted (ports still send
messages, sync API work) until it exits JS code. It is one of two
possibilities I though of as well (run unrestricted while in JS or immediate
termination).

BTW, the current Worker spec and WebKit do not have 'onclose'. I'm curious
if FF plans to keep it. I've tried to find relevant discussion on exact
reasons it was removed but it hides from me...

Dmitry

On Wed, Mar 31, 2010 at 10:03 AM, ben turner  wrote:

> Hi,
>
> When implementing the close() function for Firefox we chose to set the
> closing flag and clear pending events only. As the worker script is
> calling close() on itself we figured that the worker should retain
> maximum functionality until it has finished execution (otherwise it
> could just not call close() and rely on some kind of postMessage() and
> terminate() combo). Therefore we do not enforce any timeout for the
> currently executing script and we continue to allow postMessage()
> calls and synchronous XHR to proceed. Since the closing flag is set in
> response to close() the worker is guaranteed to finish as soon as the
> currently running script finishes. We always enforce a timeout for any
> code that runs in response to the close event that gets fired after
> the current script finishes, though.
>
> If the code that calls close() never returns (like the while(1) { }
> example above) then the worker will never finish, as pointed out
> above, but that's no different than having a worker script that
> consists only of a while(1) { } loop and we don't think it's important
> to prevent. If a worker script is written in this way then a
> terminate() call is still a valid solution.
>
> Also, since we try to retain maximum functionality after close() we
> also allow errors to propagate as shown above.
>
> If anyone is curious the basic strategy we use in response to close
> functions (like close(), terminate(), and for UA-generated events like
> when the main worker object is GC'd) can be found in the following
> table:
>
>
> http://mxr.mozilla.org/mozilla-central/source/dom/src/threads/nsDOMWorker.h#202
>
> -Ben
>
> On Tue, Mar 30, 2010 at 6:38 PM, Dmitry Titov  wrote:
> >
> > On Tue, Mar 30, 2010 at 5:58 PM, Drew Wilson 
> wrote:
> >>
> >> 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" processing model on a worker
> at
> >> any time, e.g. in response to user requests, in response to CPU quota
> >> management, or when a worker stops being an active needed worker if the
> >> worker continues executing even after its closing flag was set to true.
> >> Essentially, UAs can kill a worker at any time, and since the "kill a
> >> worker" algorithm allows UAs to abort the script after a
> user-agent-defined
> >> amount of time (including zero), it seems like almost any behavior
> >> post-close is compliant. This seems like a guaranteed source of
> >> cross-browser incompatibilities.
> >
> > Yes, and this, after many hours of troubles, may eventually crystallize
> into
> > "don't have any code after close() in your worker code" rule-of-thumb for
> > web developers. Which is basically a bad thing...
> > This is why it could be better to specify explicitly that either
> execution
> > is immediately terminated or it runs until JS exits with full
> functionality
> > of the worker, not in a special almost-closed mode. Having a timeout
> >
> >>
> >> I've always operated under the impression that the intent of the spec is
> >> to allow pending worker operations to complete, but still give UAs the
> >> ability to abort scripts that don't exit in a timely manner (so close()
> >> should not immediately abort the script), but I don't see anything in
> the
> >> spec regarding this.
> >> For #2 below, I believe that exceptions in worker context should
> *always*
> >> be reported, regardless of closing state. Section 4.6 (Runtime script
> >> errors) makes no mention of tying this behavior to the closing flag.
> >
> > This applies as long as the browser still executes the code after
> close().
> > In WebKit V8 case, we terminate execution almost instantly, so we don't
> even
> > run the code that causes an error :-) If we are not to terminate
> execution
> > instantly, then it'd be nice to say the script runs until it ends (or
> parent
> > document closes, which actually terminates the script forcefully), and
> not
> > have a requirement to stop the queue or disconnect ports, as to not
> create a
> > whole new 'mode of worker execution' which needs to have a spec on its
> own
> > since all other features will need to be mentions (like sync APIs).
> > It's not clear why a fixed timeout would be useful. It would create some
> > randomness in what a worker can still do after calling close(). I think
> web
> > developers would then rather do those things before calling close(), to
> > avoid 

Re: [whatwg] Workers: What can be done in a worker after call to close()?

[ben turner]

Hi,

When implementing the close() function for Firefox we chose to set the
closing flag and clear pending events only. As the worker script is
calling close() on itself we figured that the worker should retain
maximum functionality until it has finished execution (otherwise it
could just not call close() and rely on some kind of postMessage() and
terminate() combo). Therefore we do not enforce any timeout for the
currently executing script and we continue to allow postMessage()
calls and synchronous XHR to proceed. Since the closing flag is set in
response to close() the worker is guaranteed to finish as soon as the
currently running script finishes. We always enforce a timeout for any
code that runs in response to the close event that gets fired after
the current script finishes, though.

If the code that calls close() never returns (like the while(1) { }
example above) then the worker will never finish, as pointed out
above, but that's no different than having a worker script that
consists only of a while(1) { } loop and we don't think it's important
to prevent. If a worker script is written in this way then a
terminate() call is still a valid solution.

Also, since we try to retain maximum functionality after close() we
also allow errors to propagate as shown above.

If anyone is curious the basic strategy we use in response to close
functions (like close(), terminate(), and for UA-generated events like
when the main worker object is GC'd) can be found in the following
table:

http://mxr.mozilla.org/mozilla-central/source/dom/src/threads/nsDOMWorker.h#202

-Ben

On Tue, Mar 30, 2010 at 6:38 PM, Dmitry Titov  wrote:
>
> On Tue, Mar 30, 2010 at 5:58 PM, Drew Wilson  wrote:
>>
>> 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" processing model on a worker at
>> any time, e.g. in response to user requests, in response to CPU quota
>> management, or when a worker stops being an active needed worker if the
>> worker continues executing even after its closing flag was set to true.
>> Essentially, UAs can kill a worker at any time, and since the "kill a
>> worker" algorithm allows UAs to abort the script after a user-agent-defined
>> amount of time (including zero), it seems like almost any behavior
>> post-close is compliant. This seems like a guaranteed source of
>> cross-browser incompatibilities.
>
> Yes, and this, after many hours of troubles, may eventually crystallize into
> "don't have any code after close() in your worker code" rule-of-thumb for
> web developers. Which is basically a bad thing...
> This is why it could be better to specify explicitly that either execution
> is immediately terminated or it runs until JS exits with full functionality
> of the worker, not in a special almost-closed mode. Having a timeout
>
>>
>> I've always operated under the impression that the intent of the spec is
>> to allow pending worker operations to complete, but still give UAs the
>> ability to abort scripts that don't exit in a timely manner (so close()
>> should not immediately abort the script), but I don't see anything in the
>> spec regarding this.
>> For #2 below, I believe that exceptions in worker context should *always*
>> be reported, regardless of closing state. Section 4.6 (Runtime script
>> errors) makes no mention of tying this behavior to the closing flag.
>
> This applies as long as the browser still executes the code after close().
> In WebKit V8 case, we terminate execution almost instantly, so we don't even
> run the code that causes an error :-) If we are not to terminate execution
> instantly, then it'd be nice to say the script runs until it ends (or parent
> document closes, which actually terminates the script forcefully), and not
> have a requirement to stop the queue or disconnect ports, as to not create a
> whole new 'mode of worker execution' which needs to have a spec on its own
> since all other features will need to be mentions (like sync APIs).
> It's not clear why a fixed timeout would be useful. It would create some
> randomness in what a worker can still do after calling close(). I think web
> developers would then rather do those things before calling close(), to
> avoid random results.
> But if we say close() lets script run until completion (but prevents further
> messages/events from dispatching), then perhaps we don't need it at all -
> there is nothing then that script in the worker can not do to the same
> effect (unregister onmessage, clear timers etc).
> That means letting worker to call close() on itself only makes additional
> sense if it is specified as immediate termination. It could be useful and it
> can be specified in deterministic manner.
> On a separate note, I agree with giving workers some time before terminating
> them in case the parent page closes - but this is the case when forces
> outside and async to the worker need to close it. I think

Re: [whatwg] Workers: What can be done in a worker after call to close()?

[Dmitry Titov]

On Tue, Mar 30, 2010 at 5:58 PM, Drew Wilson  wrote:

> 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<#127b1baa1cefaebf_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 worker stops being an active
> needed worker <#127b1baa1cefaebf_active-needed-worker> if the worker
> continues executing even after its 
> closing<#127b1baa1cefaebf_dom-workerglobalscope-closing> flag
> was set to true.
>
> Essentially, UAs can kill a worker at any time, and since the "kill a
> worker" algorithm allows UAs to abort the script after a user-agent-defined
> amount of time (including zero), it seems like almost any behavior
> post-close is compliant. This seems like a guaranteed source of
> cross-browser incompatibilities.
>

Yes, and this, after many hours of troubles, may eventually crystallize into
"don't have any code after close() in your worker code" rule-of-thumb for
web developers. Which is basically a bad thing...
This is why it could be better to specify explicitly that either execution
is immediately terminated or it runs until JS exits with full functionality
of the worker, not in a special almost-closed mode. Having a timeout



>
> I've always operated under the impression that the intent of the spec is to
> allow pending worker operations to complete, but still give UAs the ability
> to abort scripts that don't exit in a timely manner (so close() should not
> immediately abort the script), but I don't see anything in the spec
> regarding this.
>
> For #2 below, I believe that exceptions in worker context should *always*
> be reported, regardless of closing state. Section 4.6 (Runtime script
> errors) makes no mention of tying this behavior to the closing flag.
>

This applies as long as the browser still executes the code after close().
In WebKit V8 case, we terminate execution almost instantly, so we don't even
run the code that causes an error :-) If we are not to terminate execution
instantly, then it'd be nice to say the script runs until it ends (or parent
document closes, which actually terminates the script forcefully), and not
have a requirement to stop the queue or disconnect ports, as to not create a
whole new 'mode of worker execution' which needs to have a spec on its own
since all other features will need to be mentions (like sync APIs).

It's not clear why a fixed timeout would be useful. It would create some
randomness in what a worker can still do after calling close(). I think web
developers would then rather do those things before calling close(), to
avoid random results.

But if we say close() lets script run until completion (but prevents further
messages/events from dispatching), then perhaps we don't need it at all -
there is nothing then that script in the worker can not do to the same
effect (unregister onmessage, clear timers etc).

That means letting worker to call close() on itself only makes additional
sense if it is specified as immediate termination. It could be useful and it
can be specified in deterministic manner.

On a separate note, I agree with giving workers some time before terminating
them in case the parent page closes - but this is the case when forces
outside and async to the worker need to close it. I think
it's different when worker's own script wants to terminate - it could do its
last wishes before calling close() as well.


>
> -atw
>
>
>
> On Tue, Mar 30, 2010 at 4:44 PM, Dmitry Titov  wrote:
>
>> Hi!
>>
>> Trying to fix some bugs for Workers, I've got some questions about close()
>> method on 
>> WorkerGlobalScope
>> .
>>
>> In particular, the spec seems to imply that after calling close() inside
>> the worker, the JS does not get terminated right away, but rather continue
>> to execute, while an internal 'closing' flag is set and a message
>> queue associated with the worker discards all the tasks, existing and
>> future. Also, all ports are immediately disentangled.
>>
>> This seems to leave some questions without explicit answer, with
>> differences in current implementations:
>>
>> 1. Does this code in a worker continues looping until the parent page
>> unloads:
>>  ...
>>  close();
>>  while(true) {}
>>
>> WebKit V8 terminates, WebKit JCS terminates after a timeout, FF does not
>> terminate.
>>
>> 2. Do the errors propagate back to Worker object after close()?
>> ...
>> close();
>> nonExistingFunction();  <<-- throws, if not processed locally, posts error
>> info to the Worker object.
>>
>> In WebKit and FF errors propagate, although it does not seem consistent
>> while worker closed all the ports and is in a dormant state.
>>
>> 3. Should synchronous operations work after close()? Asynchronous ones
>> perhaps should not, because of the event loop queue which is stopped...
>> ...

Re: [whatwg] Workers: What can be done in a worker after call to close()?

[Drew Wilson]

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 worker stops being an active needed
worker<#active-needed-worker> if
the worker continues executing even after its
closing<#dom-workerglobalscope-closing> flag
was set to true.

Essentially, UAs can kill a worker at any time, and since the "kill a
worker" algorithm allows UAs to abort the script after a user-agent-defined
amount of time (including zero), it seems like almost any behavior
post-close is compliant. This seems like a guaranteed source of
cross-browser incompatibilities.

I've always operated under the impression that the intent of the spec is to
allow pending worker operations to complete, but still give UAs the ability
to abort scripts that don't exit in a timely manner (so close() should not
immediately abort the script), but I don't see anything in the spec
regarding this.

For #2 below, I believe that exceptions in worker context should *always* be
reported, regardless of closing state. Section 4.6 (Runtime script errors)
makes no mention of tying this behavior to the closing flag.

-atw



On Tue, Mar 30, 2010 at 4:44 PM, Dmitry Titov  wrote:

> Hi!
>
> Trying to fix some bugs for Workers, I've got some questions about close()
> method on 
> WorkerGlobalScope
> .
>
> In particular, the spec seems to imply that after calling close() inside
> the worker, the JS does not get terminated right away, but rather continue
> to execute, while an internal 'closing' flag is set and a message
> queue associated with the worker discards all the tasks, existing and
> future. Also, all ports are immediately disentangled.
>
> This seems to leave some questions without explicit answer, with
> differences in current implementations:
>
> 1. Does this code in a worker continues looping until the parent page
> unloads:
>  ...
>  close();
>  while(true) {}
>
> WebKit V8 terminates, WebKit JCS terminates after a timeout, FF does not
> terminate.
>
> 2. Do the errors propagate back to Worker object after close()?
> ...
> close();
> nonExistingFunction();  <<-- throws, if not processed locally, posts error
> info to the Worker object.
>
> In WebKit and FF errors propagate, although it does not seem consistent
> while worker closed all the ports and is in a dormant state.
>
> 3. Should synchronous operations work after close()? Asynchronous ones
> perhaps should not, because of the event loop queue which is stopped...
> ...
> close();
> xhr.open("GET", "foo.com", *false*);
> xhr.send();
>
> WebKit: does not work (mostly), FF - does work.
>
> Perhaps it would be simpler to either say nothing is executed/posted/fired
> after close() (immediate termination), or to enable worker run unimpeded
> (with ports open, etc) until it naturally yields from JS.
>
> Any opinions?
>
> Thanks,
> Dmitry
>
>
>

[whatwg] Workers: What can be done in a worker after call to close()?

[Dmitry Titov]

Hi!

Trying to fix some bugs for Workers, I've got some questions about close()
method on 
WorkerGlobalScope
.

In particular, the spec seems to imply that after calling close() inside the
worker, the JS does not get terminated right away, but rather continue to
execute, while an internal 'closing' flag is set and a message
queue associated with the worker discards all the tasks, existing and
future. Also, all ports are immediately disentangled.

This seems to leave some questions without explicit answer, with differences
in current implementations:

1. Does this code in a worker continues looping until the parent page
unloads:
 ...
 close();
 while(true) {}

WebKit V8 terminates, WebKit JCS terminates after a timeout, FF does not
terminate.

2. Do the errors propagate back to Worker object after close()?
...
close();
nonExistingFunction();  <<-- throws, if not processed locally, posts error
info to the Worker object.

In WebKit and FF errors propagate, although it does not seem consistent
while worker closed all the ports and is in a dormant state.

3. Should synchronous operations work after close()? Asynchronous ones
perhaps should not, because of the event loop queue which is stopped...
...
close();
xhr.open("GET", "foo.com", *false*);
xhr.send();

WebKit: does not work (mostly), FF - does work.

Perhaps it would be simpler to either say nothing is executed/posted/fired
after close() (immediate termination), or to enable worker run unimpeded
(with ports open, etc) until it naturally yields from JS.

Any opinions?

Thanks,
Dmitry

Re: [whatwg] Workers and addEventListener

[Ian Hickson]

On Fri, 16 Oct 2009, Zoltan Herczeg wrote:
> >>
> >> I would not be opposed to changing the spec to include enabling a 
> >> port's message queue when addEventListener("message") is invoked.
> >
> > I'm reluctant to make addEventListener() do magic.
> 
> we have two choices:
>   - extend addEventListener
>   - fix the Shared Worker example on the whatwg site to call start()
> 
> seems the latter one was preferred by the majority of the people. Ian, 
> could you do this fix?

Done! Sorry about that.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Workers and addEventListener

[Zoltan Herczeg]

>> I would not be opposed to changing the spec to include enabling a port's
>> message queue when addEventListener("message") is invoked.
>
> I'm reluctant to make addEventListener() do magic.

we have two choices:
  - extend addEventListener
  - fix the Shared Worker example on the whatwg site to call start()

seems the latter one was preferred by the majority of the people. Ian,
could you do this fix?

Thanks,
Zoltan

Re: [whatwg] Workers and addEventListener

[Ian Hickson]

On Thu, 15 Oct 2009, Drew Wilson wrote:
>
> 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", function(event)
> {alert(event.data); }, false);
> 
> Should result in an alert dialog being fired?

Nope, this case should not get an event fired.


> I would not be opposed to changing the spec to include enabling a port's 
> message queue when addEventListener("message") is invoked.

I'm reluctant to make addEventListener() do magic.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Workers and addEventListener

[Ian Hickson]

On Thu, 15 Oct 2009, Drew Wilson wrote:
> On Wed, Oct 14, 2009 at 3:33 AM, Ian Hickson  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 the port.
> 
> Search for addEventListener in this document: 
> http://www.whatwg.org/specs/web-workers/current-work/#shared-workers
> 
> And you'll see what I mean.

Ah, yes, for shared workers you need to call start() (or use .onmessage).

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Workers and addEventListener

[Anne van Kesteren]

On Thu, 15 Oct 2009 19:54:23 +0200, Drew Wilson   
wrote:

I would not be opposed to changing the spec to include enabling a port's
message queue when addEventListener("message") is invoked.


FWIW, I would be opposed to any change to addEventListener() that makes it  
do something more than just registering an event listener for the given  
event.



--
Anne van Kesteren
http://annevankesteren.nl/

Re: [whatwg] Workers and addEventListener

[Drew Wilson]

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", function(event)
{alert(event.data); }, false);

Should result in an alert dialog being fired? Because that does not match my
reading of the spec at all - the spec explicitly states that a port's
message queue is only enabled via start() or via setting the onmessage IDL
attribute.

I would not be opposed to changing the spec to include enabling a port's
message queue when addEventListener("message") is invoked.

-atw

On Wed, Oct 14, 2009 at 3:32 AM, Ian Hickson  wrote:

> On Tue, 29 Sep 2009, Zoltan Herczeg wrote:
> >
> > In WebKit implementation of MessagePort the addEventListener("message",
> > ...) does not enable the transmitting of messages. All messages are
> > actually discarded until a dummy function is assigned to onmessage.
>
> That is a bug. The port message queue is explicitly enabled during the
> creation of the dedicated worker (step 12).
>
>
> > And in the normative text, it is not mentioned that addEventListener
> > should also enable message transmitting.
>
> The normative text just says to fire an event; the DOM Events spec makes
> it clear that events can be handled using addEventListener()-added
> handlers.
>
>
> > Anyway, my qestion is:
> >   - should addEventListener enable message transmitting?
>
> Yes.
>
> >   - Should it do it in all cases, or only when "message" is passed as the
> > first argument
>
> It should only receive 'message' events if you say 'message' as the first
> argument.
>
> --
> Ian Hickson   U+1047E)\._.,--,'``.fL
> http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>

Re: [whatwg] Workers and addEventListener

[Drew Wilson]

On Wed, Oct 14, 2009 at 3:33 AM, Ian Hickson  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 the port.

Search for addEventListener in this document:
http://www.whatwg.org/specs/web-workers/current-work/#shared-workers

And you'll see what I mean.


> --
> Ian Hickson   U+1047E)\._.,--,'``.fL
> http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>

Re: [whatwg] Workers and addEventListener

[Ian Hickson]

On Tue, 29 Sep 2009, Drew Wilson wrote:
>
> 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 message queue <#port-message-queue> must
> be enabled, as if the start() <#dom-messageport-start> method had been
> called.

Yes, but the dedicated worker construction algorithm explicitly enables 
the message ports' message queues.


> In fact, the only reason for the existence of the MessagePort.start() 
> method is to enable applications to start message queue dispatch when 
> using addEventListener().
> 
> I don't have a strong opinion as to whether we should change the spec, 
> though. I suspect not, given Anne's email. We should instead change the 
> example in the workers spec to call start().

There's no start() to call, since there's no explicit pointer to the 
MessagePort in dedicated workers.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Workers and addEventListener

[Ian Hickson]

On Tue, 29 Sep 2009, Zoltan Herczeg wrote:
> 
> In WebKit implementation of MessagePort the addEventListener("message",
> ...) does not enable the transmitting of messages. All messages are
> actually discarded until a dummy function is assigned to onmessage.

That is a bug. The port message queue is explicitly enabled during the 
creation of the dedicated worker (step 12).


> And in the normative text, it is not mentioned that addEventListener 
> should also enable message transmitting.

The normative text just says to fire an event; the DOM Events spec makes 
it clear that events can be handled using addEventListener()-added 
handlers.


> Anyway, my qestion is:
>   - should addEventListener enable message transmitting?

Yes.

>   - Should it do it in all cases, or only when "message" is passed as the
> first argument

It should only receive 'message' events if you say 'message' as the first 
argument.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Workers and addEventListener

[Drew Wilson]

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 message queue <#port-message-queue> must
be enabled, as if the start() <#dom-messageport-start> method had been
called.

In fact, the only reason for the existence of the MessagePort.start() method
is to enable applications to start message queue dispatch when using
addEventListener().

I don't have a strong opinion as to whether we should change the spec,
though. I suspect not, given Anne's email. We should instead change the
example in the workers spec to call start().

-atw

On Tue, Sep 29, 2009 at 2:13 AM, Anne van Kesteren  wrote:

> On Tue, 29 Sep 2009 09:13:17 +0200, Zoltan Herczeg <
> zherc...@inf.u-szeged.hu> wrote:
>
>> Anyway, my qestion is:
>>  - should addEventListener enable message transmitting?
>>  - Should it do it in all cases, or only when "message" is passed as the
>> first argument
>>
>
> I don't think it should. Web Workers should not modify the semantics of
> addEventListener.
>
>
> --
> Anne van Kesteren
> http://annevankesteren.nl/
>

Re: [whatwg] Workers and addEventListener

[Anne van Kesteren]

On Tue, 29 Sep 2009 09:13:17 +0200, Zoltan Herczeg  
 wrote:

Anyway, my qestion is:
  - should addEventListener enable message transmitting?
  - Should it do it in all cases, or only when "message" is passed as the
first argument


I don't think it should. Web Workers should not modify the semantics of  
addEventListener.



--
Anne van Kesteren
http://annevankesteren.nl/

[whatwg] Workers and addEventListener

[Zoltan Herczeg]

Hi all,

I am Zoltan Herczeg from University of Szeged, Hungary. I am a member of a
team who working on WebKit browser engine.

In this bug report: https://bugs.webkit.org/show_bug.cgi?id=29801 , Alexey
suggested me that I should contact you about my qestion.

In WebKit implementation of MessagePort the addEventListener("message",
...) does not enable the transmitting of messages. All messages are
actually discarded until a dummy function is assigned to onmessage.
However, after the dummy is assigned, the callback functions passed to
addEventListener start receiving messages.

The shared workers example here http://www.w3.org/TR/workers/ in section
1.2.4 suggests that addEventListener should also enable message
transmitting. However, as Alexey pointed out, the examples are
non-normative. And in the normative text, it is not mentioned that
addEventListener should also enable message transmitting. I feel the
workaround to enable message transmitting for addEventListener is ...
'dumb' now.

Anyway, my qestion is:
  - should addEventListener enable message transmitting?
  - Should it do it in all cases, or only when "message" is passed as the
first argument

Zoltan

Re: [whatwg] "workers" Highlighted

[Anne van Kesteren]

On Thu, 18 Jun 2009 14:50:41 +0200, Smylers  wrote:
> In the 'Design Notes' section the word "workers" has a thick pale green
> underline.  It isn't apparent what this is signifying.  Moving the mouse
> over it reveals it isn't a link, but a tool-tip appears -- with the text
> "Worker".  That didn't really elucidate matters:
>
>   http://www.whatwg.org/html5#serializability-of-script-execution
>
> What's this about?

It's an unimplemented feature. In this case a cross-specification reference to 
Web Workers.


-- 
Anne van Kesteren
http://annevankesteren.nl/

[whatwg] "workers" Highlighted

[Smylers]

In the 'Design Notes' section the word "workers" has a thick pale green
underline.  It isn't apparent what this is signifying.  Moving the mouse
over it reveals it isn't a link, but a tool-tip appears -- with the text
"Worker".  That didn't really elucidate matters:

  http://www.whatwg.org/html5#serializability-of-script-execution

What's this about?

Smylers

Re: [whatwg] Workers and URL origin check

[Ian Hickson]

On Wed, 27 May 2009, Dmitry Titov wrote:
>
> I have a question about URL origin check for Workers: the spec, in 
> 4.8.2, mandates a check for the Worker URL to be the 'same origin' with 
> the parent document's URL. At the same time, 4.2 says the origin of the 
> worker is derived later from the URL represented by the 'location' 
> object of the worker context.
> 
> However, the spec doesn't say how redirects should be processed. If a 
> browser gets 30x redirect request, the final URL of a worker can be 
> different from the original one which has passed the check before 
> loading. Current spec ignores the fact that origin can be changed via 
> redirect. If the origin of the loaded worker is based on the final 
> (potentially redirected) URL that 'location' object represents, then 
> subsequent XHR requests, nested workers and importScripts() will work in 
> the origin of that final URL. As specified, in case of redirect the page 
> from " http://applicationInternals.com"; can use a worker from " 
> http://application.com"; (via redirect) to access APIs of 
> application.comthat were not necessarily intended for such consumption.
> 
> Should the spec simply require the redirected, final URLs to be checked 
> against parent's and reject the script if redirection results in a 
> different origin?

Yes. Done. Any redirects to different-origin URIs cause an error now.


On Wed, 27 May 2009, Drew Wilson 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(). 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 constructor to point at any domain.
> 
> Is there a motivating security concern for this language from section 
> 4.8.2?:
> 
> # If the origin of the resulting absolute URL is not the same as the 
> # origin of the script that invoked the constructor, then throw a 
> # security exception.
>
> It seems like it makes it harder for people to share script across 
> domains without actually providing any security.

Yes. The idea is that we can extend this to cross-origin scripts in a 
future version, based on the origin of the script.


On Thu, 28 May 2009, Drew Wilson wrote:
> 
> I'm not quite sure why importScripts() should behave more like a 
> 

Re: [whatwg] Workers and URL origin check

[Kristof Zelechovski]

I was wrong: CONST values and conditional compilation variables land as
properties of the window, which means they are unavailable to other scripts
only if the defining script is external and deferred.
Still, I do not think this behavior is mandatory for run-time; there may be
symbols that are handled by the parser and do not survive after the script
has been loaded.  Admittedly, neither JavaScript nor Basic support such a
construct, but it would be easy to think of a scripting language that does.
Hypothetically,
Chris

Re: [whatwg] Workers and URL origin check

[timeless]

On Fri, May 29, 2009 at 12:27 PM, Kristof Zelechovski
 wrote:
> Inserting a SCRIPT element is not equivalent to a server-side include.  It
> is more like linking to an object file.  In particular, substitution macros
> (e.g. CONST in BASIC) in one script do not apply other scripts (all scripts
> present have already been parsed, and applying them to future scripts would
> be to fragile).

um

data:text/html,