Sepsis/inspector

DISCONTINUED
The sepsis-inspector and sepsis-console extensions were discontinued in summer 2015 due to the announcement to scrap the Mozilla extension ecosystem. There is no good replacement at this time. Ideally someday a unified, cross-target inspector and debugger will show up that embodies the sepsis fundamentals.

Where we're at

Pre-1.0 releases are available on AMO today: sepsis-inspector versions.

Third-party viewers are already possible. This is how the console is implemented. This is the sepsis-inspector analog to the old bug filed against DOM Inspector, bug 330251.

There's a sepsis-inspector owner's manual.

Where we're going

• bespoke viewers
  • create custom viewers for any kind of object from within the Inspector UI
  • eventually include a minimal visual designer for user-created viewers (far future)
  • content viewers: Whip up a custom viewer and begin using it just by publishing it over HTTP. When inspecting a page with a viewer directive in a meta tag, the Inspector will automatically register the viewer for use on a subset of all pages using something like same-origin policy.
• out-of-process
  • inspector will run as its own app, instead of the app-within-an-app that DOM Inspector has always done and that sepsis-inspector and devtools do right now
  • attach to Firefox, SeaMonkey, and Thunderbird; attach to mobile soon after that.
  • attach to Chrome? attach to Inkscape? (far, far future)
• dockable

Design work

Here are some UI mockups:

• 

  Viewer bar and findbar wireframe

• 

  objectDetails viewer wireframe (now implemented)

TODO

• Node highlighter
• Cut/Copy/Paste/Insert/Delete commands and context menu for both the domTree and domNode viewers
• Ability to toggle showAnonymousNodes and showSubDocuments from the UI

Viewer authoring guidelines

Best practices and other things to consider when writing a viewer:

• The viewer's |subject| setter should not try to detect whether the new subject is the same as the one it's already inspecting. The Inspector's "refresh" command is implemented by sending to the viewer the same subject as the one it's already inspecting. This is helpful if there are no APIs for observing changes to the subject in order to automatically update the viewer UI. (If there *are* APIs for that and you're already using them, whether you detect this or not is moot, so go ahead and do that if you like.)

• Be careful about implementing the viewer filter in such a way that it accepts or rejects an object based on that object's current state, rather than the type of object it is. There's no guarantee that your filter will be called again with an object that it initially rejected but that would now pass.

• If you're writing a viewer that only supports "Inspect Application" mode (i.e., its |subject| setter is a no-op and its filter is set to reject every potential subject), make sure not to dispatch a targetChanged notification during the viewer initialization sequence. Even if the viewer could in theory pick a target to use immediately after it's loaded, wait for the |inspectApplication| call before dispatching targetChanged.

• Viewers SHOULD NOT set their own subject. It should always use the subject the Inspector provides for it.

• Don't fire redundant "targetChanged" notifications. If the code path in your viewer that selects a target is executed, your viewer should check to see if it's the same target as the one it had the last time it sent out the "targetChanged" notification. If it's the same one, just stay quiet. If you're using |TargetChanger| (and you should be), you need not worry about this, because its |changeTarget| method will do this for you.