joewalker / devtools-window Goto Github PK

Before building a tab for a tool, the Toolbox should call isTargetSupport(aTarget). If this function return false, the tab should be disabled (visible, but grey).

For example, we should not build a tab for the StyleEditor if the target is not TAB.

We'll need a visual design.

Cmd-W and its friends should close the devtools window.

We define panels in JSMs. Most of these JSMs happen to also include the implementation of the tool.

That means a lot of tools-related JS code is loaded early and everytime Firefox is started, even if the user won't use the tools.

We should split implementation and definitions, and dynamically (or lazily) import the implementation JSMs (from the build function).

In this meta bug, I'll list all the remaining things that need to be done for the inspector.

Some will need to detach and reattach some events. Some might need to change their layout programmatically.

• support of the killswitch (if a tool is disabled, it should not be listed in getToolDefinitions. Or maybe we should have a getActiveToolDefinitions method)
  Mike: getToolDefinitions will be fine as getActiveToolDefinitions would be confusing.
• Remove this._listeners references
• Use new EventEmitter(this); (see pull #17)
• registerTool and unregisterTool should notify all the Toolboxes (aToolBox.emit("tool(un)registered", aToolID))
• openToolbox should return the toolbox instance
• remove DevToolInstance.show / DevToolInstance.hide

We should be able to change the target of a toolbox (on the API and implementation side).

Depends on issue #7.

Now that the tools target tabs and not the top level content window, we need to ensure that it can handle a tab reload.

The Web Console and the Debugger have been designed this way, but not the Inspector and the Style Editor.

And generally make it better

I didn't manage to reproduce yet.

We can call selectTool even-though the Toolbox is not loaded. It should throw an exception: "Toolbox is not ready. Wait for the ready event" (or something like that).

Otherwise, it breaks:

[JavaScript Error: "TypeError: tabstrip is null"
{file: "resource:///modules/devtools/Toolbox.jsm" line: 302}]

We should remove the close button and any inner mechanism that would close the webconsole.

This is a helper. What it basically does:

    gDevTools.getPanelForTarget("jsdebugger", gBrowser.selectedTab);

   getPanelForTarget: function(aToolName, aTargetValue) {
      let toolbox = gDevTools.getToolboxes().get(targetValue);
      if (!toolbox) {
        return undefined;
      }
      return toolbox.getToolPanels().get("jsdebugger");
   }

Once a tool is ready, it should emit a ready event. The toolbox should then emit a {toolId}-ready event.

I will take care of that as it affects the inspector.

Each tool should emit such event. Also, the tools should expose a property named isReady.

Just some basic stuff but a start all the same

For example, we want the WebConsole to be always the first tool to see. Toolbox should just set the attribute ordinal of the radio to this index. See: https://developer.mozilla.org/en-US/docs/XUL/Attribute/ordinal

That means:

• attaching a gDevTools instance to Firefox' window
• implementing the register mechanism (should be a simple function populating a Map or an Array)
• handling Toolbox instances (a Map)
• exposing basic types (Host and Target)

See issue #7

It's on the "right" only in LTR.

Go to paulrouget.com. Dock the tools to the side. Resize the sidebar. The web page layout never changes. Starting the Responsive Mode doesn't help. Might be related to bug 771043 or bug 771046.

Needs addTool and removeTool methods

Something like this:

Tool {
display visibility;
string name;
url icon;
targetChanged(???)
ctor(url)
freeze();
thaw();
destroy()
}

(i don't think we care about official js for now)

We currently have no tests ... let's create some.

The code needs tidying up (and probably extracting somewhere)

We need to finish off the icons

We need to decide on a default set of commands

First thing to do is to dynamically append an <iframe> to the .browserContainer or the notificationbox (see http://mxr.mozilla.org/mozilla-central/source/browser/base/content/tabbrowser.xml#24).

The iframe will load a about:devtools document (we don't have to handle this specific URL for now, we can use a simple chrome:// URL).

I think we should use XUL for this document.

This first version of the toolbox should have:

• one tab per tool definition (see mockup: http://i.imgur.com/Szlfh.png)
• a close button
• a vertical resizer

To retrieve information about the existing tools, the toolbox should use the gDevTools API.

for (let def of gDevTools.getToolDefinitions()) {
  // build the UI for one tab (just the button)
  // start the tool only when the tab is clicked
  tab.onclick = function() {
     def.build(…);
  }
}

The toolbox should expose the API described in this document: https://etherpad.mozilla.org/devtools-framework-jsm

Events that could be sent:

• toolReady,
• toolHide,
• toolShow,
• toolClosed
• toolBoxReady
• toolBoxClosed

(we want to use a generic event emitter mechanism: https://bugzilla.mozilla.org/show_bug.cgi?id=723904)

To simplify the development of the Toolbox, I suggest that we use a fake gDevTools object that could be loaded beforehand via Scratchpad. We would also need 2 fake tools that we could load also via Scratchpad. Opening the toolbox will also happen from the Scratchpad. See https://gist.github.com/3697858

See issue #8 for the gDevTools part.

A toolbox for a tab is started this way:

gDevTools.openToolbox(aTarget, aHost, aDefaultToolId); // aTarget being the tab

It's gDevTools job to ensure that only one Toolbox is open per target.

In the first prototype it was working. Apparently, it doesn't work anymore.

This might need to be discussed with UX people, but the same way Escape closes the Inspector in Firefox current, we'd like Escape to close the toolbox. It makes sense for the inspector, but also for the debugger (Rob said so).

This might sound fragile, but if we implement a cancellable mechanism to close the toolbox that is paired with the notification box, that would work.

EventEmitter.jsm not imported

Also while we're at it, fix a couple of nits noted at the end of this comment: https://bugzilla.mozilla.org/show_bug.cgi?id=788977#c9

I see 3 options:

1. A tool definition exposes a keybinding. When a tool is registered, we add a <key> tag to browser.xul. Pros: It's generic and keeps the tools isolated (no need to invade browser/base). Cons: Every time a Firefox window is open, those DOM element have to be created. That might have some performance impact.
2. No dynamic code. A <key> tag is added in browser-set.inc (as it is right now). Pros: No perf problem. Cons: Not generic (addons can't use it). Tools are not confined in browser/devtools.
3. No keybinding per tool. One single keybinding (Ctrl-shift-K) to start the toolbox, and from there, the user select the tool. Pros: implementation is simple. No perf issue. Mechanism is consistent for the builtin-tools and addons. No need to worry about findings keybindings for every new tools. Cons: It might disturb existing users. Path to a tool might be longer (but we would be smart about it, and show the latest used tool).

Personally, I'm for 3).

That would mean pressing Escape 3 times to get out of the ResponsiveMode + Inspector. But I think that might make sense.

I will use this bug to track my work on migrating the Inspector to the new API.

As for now, only the StyleEditor looks good in the sidebar. All the other tools and the toolbox tabstrip overflow in a bad way.

I suggest that we have a pref to enable/disable docking in the sidebar.

Just put a comment at the top

A picture paints a thousand words:

• Open / Close Toolbox
• Open individual tools when toolbox open
• Open individual tools when toolbox closed

We can just check which tab's checkbox is checked as tool initialization checks are each tools responsibility.

As described here: http://www.youtube.com/watch?v=yaFJFwDHBYc&feature=youtu.be

That means:

• removing tools from the Developer toolbar (completed)
• build the new tools menu
• add a button to the developer toolbar

Getting this error when opening the devtools toolbox (on the "toolbox" branch):

Error: TypeError: window.DeveloperToolbar.display is undefined
Source File: resource:///modules/devtools/gDevTools.jsm
Line: 259

The line in question is:

  var requisition = window.DeveloperToolbar.display.requisition;

in createButtons()

• add a "connect" button at the end of the tabstrip
• onclick, show a simple prompt (we'll get something more fancy later) to ask host + port
• switch target

STR:

• start the webconsole
• close the toolbox
• start the webconsole
• empty output / non-working js input

When a target is about the get destroyed (on tab close for example), we should notify the Toolbox, and let the toolbox cancel the destruction if needed.