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<atwilson@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