[webkit-dev] Reporting exceptions from worker context to users

[Drew Wilson]

OK, I really wanted to gloss over this, but now Jeremy's going to make me
elaborate :)
There are a few things I think we will eventually need to support worker
development:

1) Some way to print out the values of things in a worker's global scope.
2) Similar debugging support for workers that we have for page script
(breakpoints, etc).
3) When the user is selecting a worker for #1/#2, it might be useful to
indicate what the parent(s) of the worker are to help developers select the
right worker (in case there are nested workers). Or maybe it's not very
useful - perhaps just having the URL of the worker base script is
sufficient. We don't know yet.

None of these issues have anything to do specifically with SharedWorkers.
Nor do I think that we should block development on arbitrary features like
nested workers because we think we need better tools. A better solution
would be to roll out a "just barely good enough" solution, get developer
feedback on real use cases, and improve the tools over time to reflect that
feedback, just as we do for every other feature in WebKit.

-atw


On Sat, Aug 1, 2009 at 1:06 PM, Jeremy Orlow <jorlow at chromium.org> wrote:

> 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 <michaeln at 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<atwilson at 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 <michaeln at 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<atwilson at 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 at lists.webkit.org
>> >> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>> >> >
>> >> >
>> >
>> >
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090801/926b3a22/attachment-0001.html>