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 -~----------~----~----~----~------~----~------~--~---
