Closed Bug 568724 Opened 14 years ago Closed 12 years ago

Debugger needs user interface sketches

Categories

(DevTools :: General, defect)

x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: jimb, Unassigned)

Details

(Keywords: uiwanted, Whiteboard: debugger)

We need help designing user interfaces for the upcoming built-in JavaScript debugger, event console, and DOM and CSS inspectors. At the moment it's just a bunch of us opinionated engineers, but Mozilla has user-experience specialists on staff, and we should avail ourselves of their expertise.
Keywords: uiwanted
Already had some discussions with UX for the inspector. Mockups I have and am working towards are here:

https://wiki.mozilla.org/Firefox/Projects/Inspector#Designs
Should this be in Firefox::Devtools or is there a UX component?
Component: General → Developer Tools
Product: Core → Firefox
QA Contact: general → developer.tools
The uiwanted flag should get our attention:

limi - who do you think should be lead resource on this? I don't think it's a ton of time, just some orienting and availability to answer questions.
I spoke with Jim Blandy, David Dahl and Rob Sayre about this last week and agreed to lend my time helping with mockups for the debugger. Still willing to do this if needed.
Yup, I spoke to the team about this too, and we agreed that having someone experienced like Atul involved while they are still narrowing down the use cases for what the "average developer" are — and then I'm happy to give guidance on the UI bits (panels vs. windows, modal vs. non-modal, menu placement/structure, icons and sundry).
Atul, there is a sketch of the proposed JS debugging architecture here:

https://wiki.mozilla.org/Platform/JSDebugv2
https://wiki.mozilla.org/RemoteDebugging

One thought:

There are explanations there for why we think remote debugging is the way to go for nearly everything. That considered, I'm concerned about how usable a remote architecture would be for lightweight debugging tasks --- one shouldn't have to start a separate program and connect to Firefox just to get a backtrace for an error. Perhaps the separate tool would be started automatically by Firefox?
(In reply to comment #2)
> Should this be in Firefox::Devtools or is there a UX component?

I don't know the established boundaries of the categories, but this bug is only about tools for web developers. Nothing we're doing here should ever be visible to someone who hasn't asked to inspect or debug something.
> There are explanations there for why we think remote debugging is the way to go
> for nearly everything. That considered, I'm concerned about how usable a remote
> architecture would be for lightweight debugging tasks --- one shouldn't have to
> start a separate program and connect to Firefox just to get a backtrace for an
> error. Perhaps the separate tool would be started automatically by Firefox?

The reason this is relevant to Atul, and not just an internal consideration, is that a separate process must necessarily use a separate top-level window. In other words, our desire to isolate the debugger and debuggee from each other by putting them in separate processes effectively leads us to putting the debugger UI in a separate top-level window.
Here's a weird question, but is it possible for the separate process to just be a web server? This would effectively allow it to show up anywhere we wanted, whether an iframe or a tab or even another browser.
(In reply to comment #8)
> > There are explanations there for why we think remote debugging is the way to go
> > for nearly everything. That considered, I'm concerned about how usable a remote
> > architecture would be for lightweight debugging tasks --- one shouldn't have to
> > start a separate program and connect to Firefox just to get a backtrace for an
> > error. Perhaps the separate tool would be started automatically by Firefox?
> 
> The reason this is relevant to Atul, and not just an internal consideration, is
> that a separate process must necessarily use a separate top-level window.

Why is that the case?  We're going to have multiple processes in the same top-level window in Firefox pretty soon, so it seems like we have options here.
(In reply to comment #9)
> Here's a weird question, but is it possible for the separate process to just be
> a web server? This would effectively allow it to show up anywhere we wanted,
> whether an iframe or a tab or even another browser.

Sure, the debugger front end can be anything we want.  The requirement is isolation.
Isolation is good, but Firebug still wins (I'm told this by webdevs, even very recently) because it is integrated and uses a "twitch model" UI. Maybe I mean "tweak".

This can be implemented with process isolation, my point here is only that we must not require a separate program to be started by hand, or anything that breaks the lightweight-ness of Firebug for the user. Of course we should make things even lighter.

/be
(In reply to comment #10)
> 
> Why is that the case?  We're going to have multiple processes in the same
> top-level window in Firefox pretty soon, so it seems like we have options here.

I asked jimb about this on irc, and he agrees with shaver's point now. The in-window panel UI needs to stay, with the option of breaking out to a new window. Chrome can pull this off with a separate OS process, so can we. The DOMAgent code in WebKit is closer to the right idea, and much better than the current links we have for the inspector and jsdb.

We should aim higher for our UI, though. In the 10 minutes I thought about it, it seemed to me that the optimal layout for all of this stuff will be drastically different based on available display hardware. We should shoot for the level of panel layout flexibility found in Visual Studio or XCode.
(In reply to comment #13)
> We should shoot for the level of panel layout flexibility found in
> Visual Studio or XCode.

Is that a lot like Venkman and Eclipse?
(In reply to comment #10)
> Why is that the case?  We're going to have multiple processes in the same
> top-level window in Firefox pretty soon, so it seems like we have options here.

[My first reply to this got et by something.]  Oh, yes, that gives us the options we need.  So we can choose any point along a continuum: separate top-level window, separate layer within debuggee top-level window (to avoid interference via viewport resizing), and panels within debuggee top-level window.

We're basically back to "how much DOM interference should we tolerate to balance the UX we want with the isolation we want", and the process boundaries aren't constraining us much in figuring that out.

I violently agree with Brendan that none of this should require the user to start a separate program.  But I think that goes without saying.
(In reply to comment #12)
> This can be implemented with process isolation, my point here is only that we
> must not require a separate program to be started by hand, or anything that
> breaks the lightweight-ness of Firebug for the user. Of course we should make
> things even lighter.

definitely. That'd be unpleasant.

I think what we should figure out is the base set of features we'll need for a visual debugger rather than where it's placed in our window hierarchy. I very-much agree that it should be really easy to get at, though.

To riff on a few obvious features:
* Source view (preferably a pretty one with syntax highlighting, including eval'd scripts)
* Breakpoints (natch)
* Conditional/Evaluated Breakpoints
* Variable Watches / Object Inspectors (with live at breakpoints)

I think this'd be a decent starting point for more interesting capabilities.

Nice-to-haves could include:
* Pretty-printed minified, debuggable code
* Anonymous function display names or identifiers

What else?
(In reply to comment #16)
> * Variable Watches / Object Inspectors (with live at breakpoints)

with live *editing* at ...
Is there any kind of accepted standard or custom for accessing non-minified files from minified ones? For instance, often minified js files have an extension of .min.js, and if you remove the ".min", often you'll get the uncompressed version of the source.

In the spirit of "view source", it'd be really awesome if we could show this somehow, or push forward on some sort of custom if one doesn't already exist, because so much code is pre-minified/compressed these days that it's made "view source" much less useful. This could easily be way out of scope, though. :)
Some kind of integration with (or extension mechanism that would allow for the integration of) Patrick Walton's jsctags [1] could be awesome. Just brainstorming at this point.

[1] http://pcwalton.blogspot.com/2010/05/introducing-jsctags.html
(In reply to comment #18)
> Is there any kind of accepted standard or custom for accessing non-minified
> files from minified ones? For instance, often minified js files have an
> extension of .min.js, and if you remove the ".min", often you'll get the
> uncompressed version of the source.

I don't think there's anything like a standard for de-minifying files at this point. 

http://jsbeautifier.org/

is one of the more useful and popular online tools, but without debugger integration it's only partly useful.

Polling servers for non-.min versions is a good idea though as many servers will have the developer versions online. We'd have to have some hooks in place at the parser level to do that replacement though.

> In the spirit of "view source", it'd be really awesome if we could show this
> somehow, or push forward on some sort of custom if one doesn't already exist,
> because so much code is pre-minified/compressed these days that it's made "view
> source" much less useful. This could easily be way out of scope, though. :)

yeah, I think it's a pretty huge pain point for learning about how any given page is put together these days. I'd love to see us come up with a solution for lessening that.
IIRC, Venkman has always offered pretty-printed alterna-soruce, using SpiderMonkey's decompiler. No need for jsbeautifier.org.

/be
(In reply to comment #21)
> IIRC, Venkman has always offered pretty-printed alterna-soruce, using
> SpiderMonkey's decompiler.

Yes.

That being said, that doesn't always make minified files *that* much easier to understand, if identifier names have also been abused, but I doubt there's anything we could do about that without the original source - although maybe it would be cool if we could allow people to reconstruct identifiers themselves to make it more readable (and allow them to rename "a" to "url", and automagically update all the references to the same identifier for them).

I'd also like to say that very very many people use
(In reply to comment #16)
> * Anonymous function display names or identifiers

So I'm not sure that should be optional. There is code in Venkman that does a reasonable job at guessing them (although depending on APIs, updating that may not be much faster than rewriting it from scratch).
One point that ddahl made was that he'd often prefer to browse, not a list of scripts, but a list of global functions and objects with function properties --- viewing the program by name, not by source.

Note that I'm just describing a feature that would be nice if it worked well, not proposing an effective implementation.  Unless web pages are generally more disciplined than I imagine, deciding which of the content-added globals are worth listing could be hard.
GNU has a great definition for "source code": "the preferred form for editing".  Thus, say, generated C code is not source code, while the thing it is generated from is. In that sense, minimized JS is not source code.

Minimized source code comes up in conversations a lot; is it in fact that common for developers to be forced to work with it, or is this just a memorably frustrating but rare case?  (I'm genuinely ignorant.)

If it's common, then we should treat being forced to work with minimized source as a problem as serious as being unable to display the source at all.
(In reply to comment #23)
> One point that ddahl made was that he'd often prefer to browse, not a list of
> scripts, but a list of global functions and objects with function properties
> --- viewing the program by name, not by source.
> 
This would be very powerful. No one cares about the source file's path when trying to see the state of a program. They want to know the name of the objects that currently exist and what their properties are. I would actually like to have both bits of information.

The list of js file paths and any minimized code displayed in Firebug is pretty meaningless, especially to a developer who is just trying to figure out the names of the constructors, functions and what resulting objects in memory are created by them.
(In reply to comment #24)
> GNU has a great definition for "source code": "the preferred form for editing".
>  Thus, say, generated C code is not source code, while the thing it is
> generated from is. In that sense, minimized JS is not source code.
> 
> Minimized source code comes up in conversations a lot; is it in fact that
> common for developers to be forced to work with it, or is this just a memorably
> frustrating but rare case?  (I'm genuinely ignorant.)
> 
> If it's common, then we should treat being forced to work with minimized source
> as a problem as serious as being unable to display the source at all.

I'll post something here that I've had written down with regard to getting pretty-printed code out of a minified blob:

                                   -- ** --

What I propose is that minifiers/obfuscators (let's call them source packers) perform an extra step during the process, which is to write out an additional file, which, when coupled with the output code, produces the original input.  This would serve to have a similar effect to binary symbols + source.  I think a lot of web devs would be excited at the prospect of this feature built in to Firebug and on to Webkit's Web Inspector from there (and Venkman, if anyone ever picks up regular development of it).  I think the web toolkit guys [dojo, etc.] would also have a fun time integrating this into their packing utilities.

... [Someone needs to create] a pseudo-standard set of debugger pragmas, like where to load the symbols from (for those to whom packing has everything to do with bandwidth and nothing to do with obfuscation) and which bug tracker should be used for linkifying bug IDs.  In the first case, for example, you care if 92K of a 164K file can be minified out so that you aren't serving it to every person who views your site.  You don't really care about a 80 byte pragma line at the head of a few files.  Those who are obfuscating could of course manually load a pragma via filepicker (or perhaps specified in project settings for sufficiently advanced tools supporting that type of thing).

                                   -- ** --

If anyone is actually, seriously considering doing this, please, *please* think about doing it in a reasonably standard way before diving headlong into it.  I'm not saying you should form a committee and start using terms like "candidate recommendation", but as you're implementing it, ask yourself, "Hey, is this something that the Chrome guys would want to integrate into the Web Inspector?  Is it reasonably forward-compatible?"
For example, if you're going to do the symbol-loading directive, don't invent your own syntax and do something like:

// ##loadsymbols## $file$_unminified.productions

Javadoc-style is fairly popular even outside of Java.  Make sure the path resolution algorithm is the same as HTML's.  Also, if you choose to create your own ad-hoc unpacking/unification scheme, realize that someone *will* see it as a challenge to craft their own, "better" scheme that's more efficient and has some other property like "being more sensible".  Do this instead:

/**
 * @webdbg symbols mozunpack <path to symbol file>
 */

This leaves it open to do stuff like this:

/**
 * @webdbg <some custom directive applicable to web inspector>
 * @webdbg symbols dojopack <path to symbol file created with dojo's packer>
 */

If anybody comes along in the future and says "Hey, check this out!  The <JS toolkit team>'s packer is up to 6% more efficient than <the one everyone uses>, that's great.  You can go download their Firebug plugin.

kthx
We need a Toolbar Button also
Changing the subject of this to reflect that the Web Console and Inspector actually both exist well beyond UI sketches but that the debugger would still need sketches.
Summary: Debugger, Inspector, console, and related tools need user interface sketches → Debugger needs user interface sketches
since we've already got UI for this, I'm marking this closed.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.