I think logging to all connected pages' console is fine for now, but I think Michael's suggestion (or something similar) should be implemented in the not too distant future. Definitely before shared workers are allowed to communicate with each other. J
On Sat, Aug 1, 2009 at 12:45 PM, Michael Nordman <micha...@google.com>wrote: > > 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<atwil...@google.com> 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 <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 >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev