I think so. That would also make WebKit data flow consistent with Chromium. The only thing is that passing a JS stack info between processes should not be that easy. But traces in console have limited support in Chromium anyways.
Pavel On Sun, Nov 8, 2009 at 11:25 PM, Drew Wilson <atwil...@chromium.org> wrote: > Looking over the code, it's not hard to forward messages from > RenderViewHost back to the RenderView, and from there off to the console, so > perhaps that's the right short-term solution for shared workers. > > -atw > > > On Sun, Nov 8, 2009 at 12:23 PM, Drew Wilson <atwil...@chromium.org>wrote: > >> OK, I understand better now. Thanks. >> >> BTW, what happens to exceptions, etc generated in similar contexts today >> (e.g. extension background pages) - how are they surfaced to the >> user/developer? >> >> -atw >> >> >> On Sun, Nov 8, 2009 at 12:18 PM, Pavel Feldman <pfeld...@chromium.org>wrote: >> >>> The way devtools are implemented is that we have the DevToolsAgents >>> running within _inspected_ renderers and DevToolsFrontends running within >>> _frontend_ renderers. DevToolsManager routes messages between those without >>> really knowing what is in. The interesting thing is that DevToolsAgent is a >>> wrapper around InspectorController, DevToolsFrontend is a wrapper around web >>> inspector frontend. These guys serve as a transport for underlying webkit >>> components and also do not have much insight into the nature of the messages >>> they are forwarding. So there is no "addMessage" method in the >>> DevToolsFrontend's API you could short cut into. >>> >>> That's why I suggested comping up with InspectorController-alike >>> structure that leaves within worker process. We would then be able to build >>> DevToolsAgent around it and wire it to some frontend. That way we leverage >>> maximum of the WebKit code both on the agent side and on the frontend. >>> >>> Pavel >>> >>> >>> On Sun, Nov 8, 2009 at 11: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). >>>> >>>> -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 -~----------~----~----~----~------~----~------~--~---
