Yes, SharedWorkers will eventually be able to communicate with one another, as will DedicatedWorkers. So at some point we'll have a big connected graph of workers that potentially might be interesting for people to traverse and inspect their global contexts (I'm not sure - I don't think we know yet what debugging tools will be useful for developers). Further agreed, the HTML5 spec states that exceptions from shared workers are *not* propagated to parent pages for application execution - this would be solely for logging purposes.
In the meantime while we work towards our glorious future, I'd still like to log exceptions somewhere :) It sounds like we have one vote for "just log them to the console for every connected document". -atw On Sat, Aug 1, 2009 at 10:35 AM, Michael Nordman <micha...@google.com>wrote: > Shared workers can also communicate directly with one another, is that > right? And its possible to have a shared worker whose only client is > another shared worker, is that right? > > Feels like we should be working towards inspecting shared workers > directly. Where a page inspector would show which shared workers it > was connected to, and you could open a separate inspector to see what > is going on within each shared worker (including which shared workers > it was connected to). > > Broadcasting exceptions within a worker to its clients for inspection > purposes may be useful even with separate inspectors per shared > worker. The client's 'shared worker' tab (or console) could log > unhandled exceptions occurring in each, as you described, encouraging > the developer to look into it... open the shared worker inspector and > poke around. > > About broadcasting unhandled shared worker exceptions in general... > > It makes sense to have unhandled exceptions in a dedicated process > propagated to the parent page's context (which may presumably handle > the exception in some way). But I'm not sure that model applies to > unhandled exceptions in shared workers. The possibility of multiple > connected pages, which should "handle it"? Seems good for > logging/debugging purposes to have them show up in the client's > inspector, but doesn't sound like a good fit for application execution > purposes. > > > On Sat, Aug 1, 2009 at 9:31 AM, Drew Wilson<atwil...@google.com> wrote: > > Hi all, > > Currently, unhandled exceptions are sent from worker context over to the > > parent page where they are logged to the console. This works fine for > > dedicated workers, but not for shared workers which can have multiple > active > > windows. > > The immediate solution that springs to mind is to broadcast the exception > to > > every window associated with a shared worker, and have each window log > the > > unhandled exception to its console. Is there another option that might be > > better (is there the concept of an inspector/console that is not > associated > > with a specific window, for example)? > > -atw > > _______________________________________________ > > webkit-dev mailing list > > webkit-dev@lists.webkit.org > > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > > > >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev