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
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
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.orgwrote:
The way devtools are
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
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.orgwrote:
Well, these are pages and hence have backing RenderViewHost instances. We
can show
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
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
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
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
[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
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
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
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
I was just saying that it'd be cleaner to do this directly from the browser
process (especially since SharedWorkers don't keep a footprint in the
renderer process the way dedicated workers do).
Now that I understand the architecture better (renderer-side webkit
inspector code tunnels through to
14 matches
Mail list logo
