WebKit Bugzilla
New
Browse
Search+
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED INVALID
29312
reorganize debug target API
https://bugs.webkit.org/show_bug.cgi?id=29312
Summary
reorganize debug target API
Patrick Mueller
Reported
2009-09-16 14:01:43 PDT
See
bug 27514, comment 23
: ----- start clip -----
> + WebInspector.console._evalInInspectedWindow(expression, appendResult.bind(this, expression, i)); > > You should make _evalInInspectedWindow public. I would recomend moving it to > inspector.js can calling it WebInspector.evalInInspectedWindow. That is where > it should have been all along.
I agree this API needs to be made public and moved somewhere else. But I'd like to do it in a separate patch: ... - I'd like to actually step back and see if we can find a good home for all these target-introspective APIs. Putting it just on WebInspector itself probably doesn't make too much sense - perhaps a new class called TargetMirror or something? ----- end clip ----- That's me wondering if we should put all of these target-related APIs in one place. Things like: - eval against global ( doEvalInWindow() ) - eval against global or currently selected stack frame (what _evalInInspectedWindow() does) - getProperties(), setPropertyValue from InjectedScriptAccess - ObjectPropertyProxy() and ObjectProxy() from WebInspector On a related note, there seems to be some interest around for remote debug APIs; a colleague at work has set up a google group
http://groups.google.com/group/webdebugprotocol
(not terribly active at the moment), Google has some kind of remote debug API for Chrome tied into an Eclipse front end -
http://blog.chromium.org/2009/08/google-chrome-developer-tools-for.html
. Not quite ready to suggest that Drosera be revived (if it's even dead, not sure), but it might be useful to start thinking in terms of the APIs that developers will be needing for building debuggers in general, so we can start thinking about some common capabilities, lingo, etc. In the future, this may allow developers more choice in development tooling, as well as potentially allow reuse of the significant investment already made, and to be made, in Web Inspector. I'll also note that I have asked up on the es-discuss mailing list about whether the ECMAScript standards group would be interested in looking at standardizing on debug APIs, and received positive feedback. For some generalist backgrounder material, check out the Mirrors paper:
http://bracha.org/mirrors.pdf
Attachments
Add attachment
proposed patch, testcase, etc.
Brian Burg
Comment 1
2014-12-12 14:10:42 PST
Closing as invalid, as this bug pertains to the old inspector UI and/or its tests. Please file a new bug (
https://www.webkit.org/new-inspector-bug
) if the bug/feature/issue is still relevant to WebKit trunk.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug