Bug 53181 – Web Inspector: make use of X-edit-server headers to save JS edits

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

[Patrick Mueller]

The Orion JavaScript editor from Eclipse provides some kind of capability to save JavaScript back to the server it came from (presumably, Orion itself).

Details (to me) are sketchy, but here's a bug report from Eclipse that mentions it: 

     https://bugs.eclipse.org/bugs/show_bug.cgi?id=334956

It appears FireBug can now somehow taking advantage of this.

[Boris Bokowski]

We're just starting to experiment with this, but would of course be interested in WebKit integration, too. The current idea is that links in the debugger that currently open the resource in the built-in source viewer, could instead open our web-based editor in a new browser tab if a header indicates it is editable.

[Boris Bokowski]

Here is a bit more context. My goal (maybe a little naive?) would be that links in the WebKit Inspector (to lines in files, for example the ones displayed for errors in the console) could open the Orion editor in a new tab, instead of showing the file in the script panel of WebKit Inspector itself. (Or maybe a context menu over that link.)

We've started to send special headers for those resources we can edit in the Orion editor, making it possible for a tool like the WebKit Inspector to detect this and derive the URL to use for the new tab. What's nice about this: if the name of this header was generic enough (i.e. not Orion-specific), other web-based editors could use the same mechanism.

You can give this a try with our demo server at orion.eclipse.org (contact me if you'd like an account):

bokowski$ curl -I http://orion.eclipse.org/file/org.eclipse.orion.client.editor/web/js/editor.js
...
X-Edit-Server: http://orion.eclipse.org:80/coding.html#
X-Edit-Token: /file/org.eclipse.orion.client.editor/web/js/editor.js
...

The URL for editing the file is http://orion.eclipse.org:80/coding.html#/file/org.eclipse.orion.client.editor/web/js/editor.js - you can append ?line=<number> to jump to a specific line.

Any feedback would be appreciated. Does this make sense to you at all? Would you like to see us use a different mechanism and not headers? One header instead of two? etc.

[Pavel Feldman]

As a started, we could support following scenario:

- Click on a link in the console
- Scripts panel is opened, script being selected
- Right click on the script, choose 'Open in Orion'
- Separate tab is opened with current file in the edit mode.

We can achieve this by means of inspector extensions. We should allow those to contribute context menu items to the scripts / resources panels. Context menu action will get url of currently opened resource/script, reach out for associated HTTP headers, get the one it likes and navigate to the corresponding edit page.

As a result, we don't need to commit to the header format right now. Deployment-wise, inspector extensions are going to be platform-specific, but content-wise, they should be cross-platform for all WebKit ports.

[Boris Bokowski]

(In reply to comment #3)
> We can achieve this by means of inspector extensions.

While a good start, it would make it a multi-click process to get to where you can fix your problem, and the line number information would probably be lost. Is it possible for an extension to add a context menu to links in the console (with access to the line number as well)?

[Pavel Feldman]

(In reply to comment #4)
> (In reply to comment #3)
> > We can achieve this by means of inspector extensions.
> 
> While a good start, it would make it a multi-click process to get to where you can fix your problem, and the line number information would probably be lost. Is it possible for an extension to add a context menu to links in the console (with access to the line number as well)?

This is also an option.

Here is a broader context on where we are currently headed:
- We have editing ambitions in the inspector land as well and are currently making our source frame an editor. This use case would require a magic header on where to post changes (using webdav).
- We are about to expose websocket-based debugging interface where you would attach to the running browser and debug your app while developing it in your cloud ide. You can play with it via running Chrome with the --remote-debugging-port=9222 switch.

So I guess what I am saying is: we can do touch-point integration such as context menu now; and aim for deeper integration in the future.

[Boris Bokowski]

(In reply to comment #5)
> - We have editing ambitions in the inspector land as well and are currently making our source frame an editor.

Interesting. Will you be using one of the existing open source code editors, or are you writing your own? Would it be a possibility to make this pluggable so that I can opt to have the Orion editor in the WebKit Inspector source frame?

[Brian Burg]

Live editing of JS isn't supported.