Firefox DevTools doorhangers

gistfile1.md

DevTools Doorhangers

Goal

Provide rich preview or interaction about inspected objects across the DevTools, in the form of floating popups.

Yay! Screenshots!

These are for illustration only, just cause a picture is worth a thousand words, however final implementation may differ.

Solution proposal

XUL Panels!

The proposal is to use XUL panel elements since they fit the job pretty nicely (most probably, but not restricted to, arrow type panels). See https://developer.mozilla.org/en-US/docs/XUL/panel for information about panels.

4 advantages of panels:

• they are floating popup windows,
• they may contain any type of content,
• they do not have any window decorations,
• and they may extend outside the border of the main window.

Furthermore, using panels makes it consistent with Firefox's download and https panels already available. Finally, the debugger already features panels for conditional breakpoints and search input.

Shared widget

The proposal is to wrap this into a reusable component and make it as easy to instantiate and attach to a new type of object as possible. Special care should be taken to try and hide the low level XUL part.

Configuration

While consistency is important and doorhangers should have a common look and feel throughout the devtools, each instance should have the opportunity to make decisions about a few things:

• obviously content
• position
• show/hide behavior
• arrow type or not
• what else?

Use cases

All of these use cases should be tracked in the meta bug http://bugzil.la/711947

Markup inspector

• Previewing img tag images
  • http://bugzil.la/765105
  • Getting image dimensions via the client-server protocol (getting a data-uri)
  • Resizing proportionally the image if it exceeds a certain width or height.
  • Showing dimensions
  • Showing transparency using a tiled background
  • DONE
• Previewing canvas tag bitmaps
  • As above. http://bugzil.la/765105
  • DONE
• Previewing HTML entities
  • http://bugzil.la/839818
  • TODO
• Preview CSS values within style attributes (just like the style inspector, but within the inline HTML attribute).
  • Not a high priority because clicking on the element will display the values in the style inspector
  • Depends on the output parser in http://bugzil.la/918716
  • TODO

Style inspector (rule and computed views)

• Color picker
  • Possibility to pick a new color, convert between color formats, open the pixel inspector.
  • http://bugzil.la/889638
  • DONE
• Gradient preview/editor
  • As for color swatches, it would be better to show the preview inline, in a small element, while providing gradient editing in the tooltip.
  • http://bugzil.la/765105 introduces a simple gradient preview (will need to be removed when gradient swatches land)
  • Possible candidate: http://briangrinstead.com/gradient/
  • http://bugzil.la/706102
  • TODO
• Background image preview (just like in the markup inspector)
  • http://bugzil.la/765105
  • DONE
• Font preview
  • Not really sure this is needed, perhaps a link to the font inspector panel would be better instead.
  • A question regarding icon fonts has been raised. It could indeed be useful to visualize a palette of characters with this font. Knowing that usually, these fonts don't really use the typical character range (A-Z...) but characters far away in the UTF-8 range, so not really possible to play with in the font inspector.
  • http://bugzil.la/702577
  • DONE
• Box shadow
  • A tooltip might not be the best way to inspect this, see http://bugzil.la/942176 instead.
  • TODO
• Box border
  • A tooltip might not be the best way to inspect this, see http://bugzil.la/942176 instead.
  • TODO
• Length
  • Not sure how interesting it would be display a 200px ruler when a 200px value is inspected though?
  • Perhaps a length converter would help (converting from em to px to rem to %, in the context of the currently selected node)
  • http://bugzil.la/711944
  • TODO
• Angles
  • http://bugzil.la/711942
  • TODO
• Cubic bezier
  • Preview the timing function curve. Perhaps allow to update it? Here is a nice demo http://matthewlein.com/ceaser/
  • http://bugzil.la/711941
  • TODO
• Time
  • http://bugzil.la/839815
  • TODO
• HTML entity
  • http://bugzil.la/839818
  • TODO
• CSS transforms
  • Seeing the original and transformed version of the box. With projection of coordinates (linking corners of both boxes).
  • Candidates http://codepen.io/captainbrosset/full/lHpnK and https://github.com/captainbrosset/csstransformer.
  • This needs to be discussed still, as it may be better to just display that information in the highlighter: http://bugzil.la/663778
  • http://bugzil.la/726427
  • DONE

Style editor

Pretty much all the rule and computed view cases apply here. Bug http://bugzil.la/971702 provides information about the hovered text in the style-editor. New bugs should be opened for the style editor. TODO

Web console

• If output is a DOM Element
  • Image preview for img tags
  • Sub DOM tree inspector for others? Might be overkill when we can simply link to the DOM inspector, but not sure
  • Perhaps previewing the DOM element with styles, but without parents and children. Just to kind of see its box model styling perhaps?
  • Needs a new bug
• If output is a HTTP request
  • Preview of the waterfall graph?
  • Needs a new bug

Debugger

• Conditional breakpoint input
  • https://bugzilla.mozilla.org/show_bug.cgi?id=812083
  • DONE
• Search inline help
  • https://bugzilla.mozilla.org/show_bug.cgi?id=796135
  • DONE
• List object properties in watch expressions and variables view (not necessarily making it possible to expand through the sub-properties, this is already possible in the sidebar panel, the doorhanger could just be a way to quickly glimpse at an object content, saving a click).
  • Needs a new bug
• List arrays items (same as above)
  • Needs a new bug
• Evaluate expressions when debugger is paused. Hovering over a variable or expression shows the result in the tooltip
  • http://bugzil.la/725235
  • DONE

Network monitor

• Previewing image responses just like the markup inspector
  • http://bugzil.la/859135
  • DONE
• Previewing font responses just like the style inspector (and/or just link to the font panel?)
• What about using it to show the timings (waterfall graph for DNS resolution, ...) instead of using a sidebar panel.

Shader editor

• Compilation error reporting
  • DONE

Alright ... one more note regarding XUL tooltips vs. panels: turns out we can use panels, just need to make sure the attribute consumeoutsideclicks is set to false.
So I guess that means interaction panels should be possible with the proposed doorhanger widget.

A couple first impressions:

• I agree with fitzgen that the default/light color for the panel doesn't feel like part of the devtools when using the dark theme. I think some quick styling here will help cement the correlation between the panel and the devtools themselves.
• I also agree with a few comments re: color/gradient previews… a panel may be better as an editor, and only show a small swatch as a preview (inline with the color property)… similar to chrome's current implementation but I think there is room to improve. As a v1 though, the panel is fine.
• As far as the interaction goes, I think hover is most discoverable and also has less resistance/friction than a click (allowing for lightweight, quick previews). However, I agree with whoever proposed a small delay to avoid a spamming of panels when you mouse over the various definitions. It's tough to define how long that delay should be without actually playing with it!
• I'm wondering whether aligning the arrow with the left edge vs. the centre makes more sense. Center alignment may be more clear what exactly it is you are previewing
• Regarding font previews and the existing font inspector, I still think there is value in a quick preview with a click sending them to the font inspector. My intuition is that a lot of these interactions will be very brief and should not require clicking through to other tools.

If there are any specific questions about any of the individual previews (fonts, images, etc.) feel free to let me know!

To be honest, you're adding waaay too much panels here.

• For gradients, box-shadow, border, css transforms can't the guy just look at the element ?
• For fonts, we should use built in tools, like the font inspector, let's not duplicate our tools across the browser, about icon fonts, well, add that functionality to the font inspector too, after all that's what it's here for.
• For the debugger search inline help, well is not the appropriated element for that, there's a built in auto complete element in the dev tools
• For the debugger breakpoint input, I don't think it's necessary

I agree with you to some extent, but allow me to bring some answers:

• gradients: just previewing a gradient isn't much helpful, I agree. In fact our goal has changed and now we want to perhaps only show a small preview, inline, next to the value, like we want to do for colors (with a color swatch), and when the user clicks on it, a doorhanger would open with a gradient editor instead. That will be a lot more useful, and only will show on click.
• box-shadow and borders: I tend to agree with you at this point but I'd like to first get a few panels out there in nightly and gather some feedback from people actually using it.
• for css-transform, I don't agree with you. Our goal is to show both the original and transformed box as this can sometime help a lot understanding why an element is where it is. On the long run, I would probably prefer putting that information along with the highlighter on the page, but we can't do that yet, so let's see how a panel would work for that.
• for fonts, I'm not clear myself, and there's not going to be a font preview panel in the first patch.
• as for the debugger, we already have the 2 panels mentioned and I think they work fine. How would you define a conditional breakpoint otherwise?

For the CSS-Transforms, well try to make just a small panel, not a huge one like box-shadow. And for the debugger, well yep they work fine. The conditional breakpoint panel could be kept, but the search inline help should use the "autocomplete element" like the developer toolbar command line (when typing help) for a more "unified" experience.

It would also be nice if the panels would interact with the developer tools theme (dark/light).