On Sun, Nov 8, 2009 at 12:04 PM, Drew Wilson <atwil...@chromium.org> wrote:
> In base webkit (i.e. the default, single-process implementation of > SharedWorkers), I route all of these errors back to the individual parent > documents on the main thread, and log them via > ScriptExecutionContext::reportException() and > ScriptExecutionContext::addMessage(). > > That base code is not executed in the chrome version of SharedWorkers, > because the multi-process architecture is different - we don't route > exceptions generated in worker processes back to renderer processes (if you > think about it, it doesn't make sense to route exceptions in worker > processes back to the renderer process to call the ScriptExecutionContext > APIs, only to have that renderer process immediately bounce it back up to > the browser process). > You're saying it doesn't make sense because of efficiency reasons? I wouldn't worry too much about it at this point, if your goal is to get this up and working. We already have a large overhead for workers compared ot other browsers because of our need to go to a different process. > -atw > > On Sun, Nov 8, 2009 at 11:54 AM, Pavel Feldman <pfeld...@chromium.org>wrote: > >> >> >> On Sun, Nov 8, 2009 at 10:41 PM, Drew Wilson <atwil...@chromium.org>wrote: >> >>> That makes sense. >>> >>> In the meantime, I'd like to come up with a pragmatic solution for how to >>> log exceptions from shared worker context within Chromium, as I think it's a >>> valuable debugging aid while we wait for upstream functionality to be added >>> - I don't want to block the release of shared workers in the meantime. >>> >>> Is it possible to report things to the console directly from the browser >>> process? I believe I can get a reference to all of the RenderViewHost >>> objects for the worker, so I could do the same thing in Chromium that we do >>> in base webkit: log all messages to every single console associated with >>> every parent frame. It's not ideal, but at least they are exposed to the >>> user. >>> >>> >> I am confused. In 'base webkit' you report to console client only or to >> inspector controller of the parent frame's page as well? If you do the >> latter, you will get console messages routed both to web inspector and >> devtools. >> >> >>> It's not clear to me how I would route my messages through them to the >>> inspector, though - I see RenderViewHost::OnAddMessageToConsole(), but that >>> doesn't seem to do what I want (doesn't look like it routes to the >>> inspector). >>> >>> -atw >>> >>> On Sun, Nov 8, 2009 at 11:29 AM, Pavel Feldman <pfeld...@chromium.org>wrote: >>> >>>> [now from chromium address] >>>> >>>> >>>> These are essentially different requests (although related). Please >>>> submit bugs for both. >>>> >>>> - Shared workers, workers, etc. require InspectorController-alike >>>> infrastructure upstream that they would report exceptions / console >>>> messages >>>> to. They should also be able to report JavaScript events there and hence >>>> allow debugging. Going that way would allow opening inspector with limited >>>> capabilities (resources, scripts and console) for shared worker context. I >>>> think we need to start with the bug upstream for this one. >>>> >>>> - This thing above will lead to the UI complexity upstream that Aaron's >>>> team is already facing in Chromium: too hard to manage several devtools >>>> windows. >>>> >>>> Thanks >>>> Pavel >>>> >>>> On Sun, Nov 8, 2009 at 9:59 PM, Aaron Boodman <a...@chromium.org> wrote: >>>> >>>>> It would be cool if the devtools window had some kind of UI where you >>>>> could see all running top-level contexts. Like tabs that had: >>>>> >>>>> + extensions >>>>> - foo extension >>>>> - background page >>>>> - worker >>>>> - tab 1 >>>>> - tab 2 >>>>> - content script a >>>>> + bar extensions >>>>> + worker 1 >>>>> + worker 2 >>>>> + tab 1 >>>>> + tab 2 >>>>> >>>>> Then we could reconfigure the current entrypoints into devtools to go >>>>> automatically to the right place in this tree. >>>>> >>>>> - a >>>>> >>>>> On Sun, Nov 8, 2009 at 10:34 AM, Ojan Vafai <o...@chromium.org> wrote: >>>>> > +chrome-devtools-team >>>>> > I think this is a general UI problem that needs to be solved for the >>>>> > inspector. There are increasingly more and more pages we have that >>>>> don't >>>>> > have a page visible to the developer (sharedworkers, extensions >>>>> background >>>>> > pages, etc.). I can't think of any good solutions off the top of my >>>>> head >>>>> > though. >>>>> > Ojan >>>>> > >>>>> > On Sun, Nov 8, 2009 at 10:14 AM, Drew Wilson <atwil...@chromium.org> >>>>> wrote: >>>>> >> >>>>> >> I'm trying to figure out the best way to report exceptions/console >>>>> >> messages from shared workers. Currently, dedicated workers just send >>>>> their >>>>> >> messages back to their parent frame, where they are reported like >>>>> any other >>>>> >> frame-level exception. SharedWorkers don't have a specific parent >>>>> window >>>>> >> (they may have many parents) so this approach won't really work for >>>>> them. >>>>> >> I can think of a couple of ways to approach this: >>>>> >> 1) These exceptions/messages are already marshaled up to the browser >>>>> >> process - perhaps they could be routed to the inspector/dev tools >>>>> from >>>>> >> there? >>>>> >> 2) There's a "shadow frame" that is created in worker context to >>>>> handle >>>>> >> resource requests from the worker. It's possible that this could be >>>>> >> leveraged to report exceptions. >>>>> >> It seems like #1 would be the simplest, but I've never been in this >>>>> code >>>>> >> before so I'm not positive about the details. Who's a good person to >>>>> talk to >>>>> >> about this? >>>>> >> -atw >>>>> >> >>>>> > >>>>> > >>>>> > > >>>>> > >>>>> >>>>> -- >>>>> >>>>> You received this message because you are subscribed to the Google >>>>> Groups "chrome-devtools-team" group. >>>>> To post to this group, send email to chrome-devtools-t...@google.com. >>>>> To unsubscribe from this group, send email to >>>>> chrome-devtools-team+unsubscr...@google.com<chrome-devtools-team%2bunsubscr...@google.com> >>>>> . >>>>> For more options, visit this group at >>>>> http://groups.google.com/a/google.com/group/chrome-devtools-team. >>>>> >>>>> >>>>> >>>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "chrome-devtools-team" group. >>> To post to this group, send email to chrome-devtools-t...@google.com. >>> To unsubscribe from this group, send email to >>> chrome-devtools-team+unsubscr...@google.com<chrome-devtools-team%2bunsubscr...@google.com> >>> . >>> For more options, visit this group at >>> http://groups.google.com/a/google.com/group/chrome-devtools-team. >>> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
