Bug 94325 – Web Inspector: Implement editor API for extensions

• Status: RESOLVED
• Resolution: INVALID
• Component: Web Inspector (Deprecated)

[Jan Keromnes]

It would be great if devtools extensions could extend the Sources panel by adding a custom code editor. The extension editor would be loaded in an iframe, and could be used to open and edit devtools files, set breakpoints, debug, etc. Such an API would be a nice framework for playing and experimenting with new ways to edit code.

[Jan Keromnes]

Created attachment 159073 [details]
Patch

[Jan Keromnes]

Proof of concept implementation of an extension editor API, allowing the creation of an editor in an iframe, and the loading of any devtools code file for edition.

[Andrey Kosyakov]

Comment on attachment 159073 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=159073&action=review

> Source/WebCore/inspector/front-end/SettingsScreen.js:301
> +        var editorSelector = new WebInspector.HandlerSelector(WebInspector.editorRegistry);
> +        p.appendChild(this._createCustomSetting(WebInspector.UIString("Edit files in"), editorSelector.element));
> +
> +        var linksHandlerSelector = new WebInspector.HandlerSelector(WebInspector.openAnchorLocationRegistry);
> +        p.appendChild(this._createCustomSetting(WebInspector.UIString("Open links in"), linksHandlerSelector.element));

So we can now "open files" and "edit files". I think this is going to be confusing for the users. Can you describe how we choose which handler to invoke?

[Jan Keromnes]

Created attachment 159084 [details]
An example extension creating an editor to edit code in the Sources panel.

This extension uses the proof of concept API to create an extension editor. The editor API is similar to the panels API https://developer.chrome.com/trunk/extensions/devtools.panels.html

The most interesting code is in js/devtools.js:

> chrome.experimental.devtools.sources.createEditor('CodeMirror', 'index.html', function (editor) { ... }
This line creates the editor iframe using the page `index.html`.

> editor.onOpenResource.addListener(function(resource, line) { ... }
This line allows the extension to be notified when a file is opened, so it can request the content of the `resource` object and load up the code for edition.

> editor.onShown.addListener(function(window) { ... }
This listener is called each time the editor is showed. Its goal is to grab the editor handle from the `window` object the first time it is shown.

Remarks:
- This API depends on bug #93444. Until it is fixed, the extension will not behave properly: It will load the code of the first file opened, however, all future opened files won't be displayed because the iframe will reload, destroying the previous editor handle to create a new one.
- The current implementation is a proof of concept. It has room for a lot of improvement, and you are welcome to contribute your ideas and feedback.

[Jan Keromnes]

(In reply to comment #3)
> So we can now "open files" and "edit files". I think this is going to be confusing for the users. Can you describe how we choose which handler to invoke?

Yes, the "open links in" handler operates on a higher level, choosing a panel to open the file in (Sources, Resources, Network, and extension panel...), whereas "edit files in" determines which editor is going to be used in the Sources panel only.

The naming and proximity of those settings can bring confusion, maybe the editor choice should be placed in a different category (e.g. "Sources panel"?)

[johnjbarton]

View in context: https://bugs.webkit.org/attachment.cgi?id=159073&action=review

> Source/WebCore/inspector/front-end/ExtensionTextEditor.js:164
> +    addDecoration: function(lineNumber, element)
> +    {

This API passes an element from one DOM to another. I don't think that will work well. I think the extension editors have to implement decorations based on higher level API, eg "error on line 4" or "breakpoint on line 65".