Re: [webkit-dev] Reporting exceptions from worker context to users
Drew Wilson wrote: 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. What immediately comes to mind here is the Eclipse Java debugger. Single window that shows a list of connected VMs. Each VM contains a list of threads. In the Web Browser World, thread might correspond to worker, and perhaps would be a tree of workers instead of list of threads, to indicate nesting. The current story with Web Inspector is that a Web Inspector is associated with a window object. So the concept of supporting muliple windows like Eclipse supports multiple processes wouldn't make sense. Doesn't rule out supporting it in the future though - a single Web Inspector window instead of multiple. And someone might want to make a stand-alone JS debugger with the inspector code, that could somehow connect to multiple running JS engines simultaneously. Then the rest of the Web Inspector story, as far as the Scripts panel, works the same. Instead of just selecting a frame to operate on, you will also have a worker (or the main thread) to select on. Selecting a new worker changes. Presumably we'd change the Call Stack section, or add a new section above Call Stack called Worker (not a great name, but you know what I mean). I suppose we should open an enhancement bug ... -- Patrick Mueller - http://muellerware.org ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Reporting exceptions from worker context to users
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
Re: [webkit-dev] Reporting exceptions from worker context to users
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 Wilsonatwil...@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
Re: [webkit-dev] Reporting exceptions from worker context to users
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 Wilsonatwil...@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 Wilsonatwil...@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
Re: [webkit-dev] Reporting exceptions from worker context to users
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.comwrote: 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 Wilsonatwil...@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 Wilsonatwil...@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
Re: [webkit-dev] Reporting exceptions from worker context to users
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 jor...@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 micha...@google.comwrote: 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 Wilsonatwil...@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 Wilsonatwil...@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
Re: [webkit-dev] Reporting exceptions from worker context to users
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. absolutely... features come first ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
