> it sounds like we have one vote for "just log them to the console for every > connected document"
sgtm On Sat, Aug 1, 2009 at 12:39 PM, Drew Wilson<[email protected]> wrote: > 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 <[email protected]> > 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<[email protected]> 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 >> > [email protected] >> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> > >> > > > _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
