Inspector Plugins or Extend Capability

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

[Joseph Pecoraro]

Its been shown how to patch in your own "extension" of the Web Inspector:
http://obvioushints.blogspot.com/2008/12/extending-webkit-web-inspector-with-fun.html

However with this method user extensions gets overwritten on updates (a pain with nightly builds) and installation require sophisticated users.  It would be cool to allow users to package up "plugins" or "extensions" to the Inspector.  Firebug itself allows for extensions, and as the article above shows extending the Web Inspector is very easy.  This would of course be developer oriented anyways.

[Patrick Mueller]

I'd like to look into this.  As well as allowing arbitrary JavaScript (per user's request) to be loaded into the web inspector runtime, I'd also like to be able to pull in a user-specified .css file, so things like fonts could be customized.

What's not clear to me is where to pull this in from the user?  My thinking is that either the debugger would always try to load some specifically named files out of a user's home directory (web-inspector-extension.js, web-inspector-extension.css), or allow the user to name the files to be added to the environment.  Where do "preferences" get saved for Web Inspector, like whether the WI is attached/detached?  Is there already a "portable" mechanism for accessing the user's "home" directory?

[Patrick Mueller]

Bit of a brain fart the other day, I figured storing preference information, and probably extension info or pointers to extension info, would probably best be handled by using the localStorage facility that's baked in.  One potential problem is that such local storage would be accessible to "web content served from the same domain" (according to http://is.gd/UN2w ).  I assume the debugger is loaded via a plain old file:/// URL, and so any other file-based page would have access to such settings.  Maybe good, maybe bad.  Seems very survivable, maybe useful.

[Patrick Mueller]

Some more thinking on this.  Again, related to localStorage.  (note: there used to be a "settings" facility available on InspectorController, on the JS side, which is now gone).

The idea is to create a new debugger command called "!settings", or some such.  Think "defauilts" on the Mac command-line.  This would be a general purpose facility to provide a read/write store for settings for Inspector related things.

Next, have a setting called "userScript".  If set, this would be considered a file name, and at the end of inspector.js we'd dynamically add a new <script> element to the inspector's main document with that file.

The story would then be something like this:

- develop your extension in a .js file somewhere on your local file system
- while in Inspector, at the command console prompt, run
   !settings set userScript /users/foo/myExtension/main.js
- next time Inspector loads, that script will load at the end, via the dynamically inserted <script> element
- to "turn the extension off", run
   !settings delete userScript

Lots of issues here, but would be a way to get started playing with the concept of extending the Inspector, inexpensively.

[Timothy Hatcher]

(In reply to comment #3)
> Some more thinking on this.  Again, related to localStorage.  (note: there used
> to be a "settings" facility available on InspectorController, on the JS side,
> which is now gone).
> 
> The idea is to create a new debugger command called "!settings", or some such. 
> Think "defauilts" on the Mac command-line.  This would be a general purpose
> facility to provide a read/write store for settings for Inspector related
> things.
> 
> Next, have a setting called "userScript".  If set, this would be considered a
> file name, and at the end of inspector.js we'd dynamically add a new <script>
> element to the inspector's main document with that file.
> 
> The story would then be something like this:
> 
> - develop your extension in a .js file somewhere on your local file system
> - while in Inspector, at the command console prompt, run
>    !settings set userScript /users/foo/myExtension/main.js
> - next time Inspector loads, that script will load at the end, via the
> dynamically inserted <script> element
> - to "turn the extension off", run
>    !settings delete userScript
> 
> Lots of issues here, but would be a way to get started playing with the concept
> of extending the Inspector, inexpensively.

This is an interesting idea, and a cheap way to try it out.

In the end we will want to read a list of files from a directory and load them automatically.

[Patrick Mueller]

(In reply to comment #3)
> Some more thinking on this.  Again, related to localStorage.  (note: there used
> to be a "settings" facility available on InspectorController, on the JS side,
> which is now gone).

My mistake, settings are still available.

[Brian Burg]

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.