I think the following features would be helpful for developers: 1. When an element is displayed in the console, clicking or double-clicking the element or any descendant will focus the same element in Elements panel (and the element becomes $0); if current panel is not Elements panel, will switch to it. 2. When a string like "script_file:line_number:column_number" is displayed as a link in the console, clicking the link will bring up the Scripts panel and select the script_file and move the cursor to the line and column. (For now, it only brings up the Resources panel and won't focus the file and line.) This would be useful for developer to inspect the related code when some script logs some stack trace in the console.
For (1) you can use the "inspect" function to make that element the selected element in the Elements Tree Hierarchy. For example, from any panel you can type "inspect(document.body)" to jump to the Elements Panel with the body element selected. You can pass in any element, database, or storage object.
Committing to http://svn.webkit.org/repository/webkit/trunk ... M WebCore/ChangeLog M WebCore/inspector/front-end/ConsoleView.js M WebCore/inspector/front-end/NetworkPanel.js M WebCore/inspector/front-end/StoragePanel.js M WebCore/inspector/front-end/inspector.js Committed r71413 inspect() should cover (1) linkify line number landed as a drive-by of r71413
Thanks Pavel for your timely fix. However, I'd still argue (1). I think making elements in the console link to Elements panel could be useful. A scenario might be that a developer uses console.log to print an element with page script (where inspect() is not accessible), and then inspects them in the console. The developer could achieve this in another way, but different developers might have different habits in debugging. Another benefit of (1) is that an extension can interact with the inspector in this way without using the inspector extension API. For example, a compatibility detection extension finds a problematic element and print it with console.log(), then the user can inspect the element to find more details.
(In reply to comment #3) > Thanks Pavel for your timely fix. > > However, I'd still argue (1). I think making elements in the console link to Elements panel could be useful. A scenario might be that a developer uses console.log to print an element with page script (where inspect() is not accessible), and then inspects them in the console. The developer could achieve this in another way, but different developers might have different habits in debugging. > > Another benefit of (1) is that an extension can interact with the inspector in this way without using the inspector extension API. For example, a compatibility detection extension finds a problematic element and print it with console.log(), then the user can inspect the element to find more details. Today, if you use console.dirxml or console.dir, you get the element dumped into the console. We can provide a "Reveal in Elements Panel" context menu item on such elements. Would that cover your scenario?
(In reply to comment #4) > Today, if you use console.dirxml or console.dir, you get the element dumped into the console. We can provide a "Reveal in Elements Panel" context menu item on such elements. Would that cover your scenario? Yes. Thanks Pavel!