One should add a button into the UI that uses DevToolsManager API for bringing up devtools for their stuff. That's what extensions do. But that API is capable of showing DevTools for RenderViewHosts only. We would need to narrow the interface for your stuff. Also, frame is not enough - inspector controller is wired via page in WebKit.
Pavel On Sun, Nov 8, 2009 at 11:39 PM, Drew Wilson <atwil...@chromium.org> wrote: > I ask because we do have that shadow frame in the worker process that we > could potentially use, if there's some way to bring up devtools for these > types of pages. > > -atw > > > On Sun, Nov 8, 2009 at 12:38 PM, Drew Wilson <atwil...@chromium.org>wrote: > >> I'm assuming that there's not currently any way for a user/developer to >> open one of these devtools windows for a hidden page? >> >> -atw >> >> >> On Sun, Nov 8, 2009 at 12:26 PM, Pavel Feldman <pfeld...@chromium.org>wrote: >> >>> Well, these are pages and hence have backing RenderViewHost instances. We >>> can show DevToolsFrontend for any RenderViewHost using the schema I >>> described. (They are opened in a separate devtools window). >>> >>> >>> On Sun, Nov 8, 2009 at 11: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. >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -- > 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 -~----------~----~----~----~------~----~------~--~---
