Skip to content

Instantly share code, notes, and snippets.

@captainbrosset

captainbrosset/gist:6681978

Last active December 23, 2015 19:19
Show Gist options
  • Save captainbrosset/6681978 to your computer and use it in GitHub Desktop.
Save captainbrosset/6681978 to your computer and use it in GitHub Desktop.
Download ZIP
Firefox DevTools doorhangers
Raw
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.

color preview image preview canvas preview conditional breakpoint searchbox help css transform preview

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
  • Previewing HTML entities
  • 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)

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
  • Search inline help
  • 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

Network monitor

  • Previewing image responses just like the markup inspector
  • 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
@fitzgen
Copy link

fitzgen commented Sep 24, 2013

This is really good and definitely something we have needed for a long time. Following nits should be taken with a grain of salt, because they are just that: nits.

I feel like the border color is too light on top of our dark theme. Seems out of place. Caveat: I am not a designer.

The color/gradient box seems a bit big, but that might be ok since this is a pretty transient mouse hover thing, right?

@fitzgen
Copy link

fitzgen commented Sep 24, 2013

Another Debugger use case: mouse over a variable in the source editor and a door hanger pops up showing its current value when you are paused. We have a bug for this somewhere.

@joewalker
Copy link

Yeay!

What do we expect the interaction model to be - show-on-hover or show-on-click? (show-on-hover could be good for discoverability, and annoying if there are lots of them)

The last 2 examples involve the user interacting with the panel. I wonder if these examples fit with the others?

Do we have thoughts about indicating transparency in an image popup, or showing the dimensions, or indicating how or if we've re-scaled it.

It could be useful in a number of places to be able to preview a DOM element. E.g. web-console, jsterm, scratchpad, debugger, etc.

Off-the-wall thought: With the rise of icon-fonts, it could be useful to be able to preview a character in a given font, or maybe have a character-grid thing to show them all off.

@captainbrosset
Copy link
Author

For info, the first commit for the doorhangers is now available here:
captainbrosset/mozilla-central@e78a66c
An HG patch has been attached to https://bugzilla.mozilla.org/show_bug.cgi?id=765105 ready for review.

  • A lot of the tooltips mentioned will be preview tooltips, therefore a show-on-hover seems best, perhaps with a delay to avoid annoying the user if there are many as you said.
  • As for interaction tooltips, true they don't really fit with the rest and it turns out that we perhaps won't even be able to use the same underlying XUL structure for them. Indeed, I've had to revert to using XUL tooltips instead of XUL panels and those can't be used for interactions.
    Let's try and see if we can use the same shared widget anyway.
  • When it comes to transparency in image popups, so far I'm planning on using a white/grey tiled background so that if part of the image is transparent, it will pick through (like in photoshop).
    Dimensions of the image will be shown just below the image itself, and the image will be resized down if needed (max-width and max-height used).
    I don't think indicating if the image was re-scaled is needed, but why not. If yes, then perhaps a simple asterisk * sign next to the dimensions, or italic font, or any other visual clue that the dimensions written are not those displayed.
  • About previewing DOM elements, what do you mean exactly? I had an idea some time ago to display an element, with all its styling (as you see it in the page), but without any visible parent or child, but I'm not sure how useful that would be. Is this somewhat what you meant?
  • The icon-font preview idea is great. In the first commit, there's for now no font preview because it wasn't bringing that much added value since we already have a font inspector panel. So we still have to figure out what to do here.

@captainbrosset
Copy link
Author

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.

@darrinhenein
Copy link

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!

@nt1m
Copy link

nt1m commented Oct 10, 2013

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

@captainbrosset
Copy link
Author

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?

@nt1m
Copy link

nt1m commented Oct 11, 2013

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment