529086 - [meta] Create an Interactive Console for debugging web pages

Status: RESOLVED FIXED

(DevTools :: Console, defect)

Description

[Rob Campbell [:rc] (:robcee)]

[this is a meta bug]

Create an interactive Console to help web developers understand everything that happens during the creation of a web-page. Console entries will be time-stamped objects representing errors, network traffic, javascript events, DOM/HTML mutation and logging output. The Console will also have an interactive command line for evaluating javascript against the current webpage and an interactive Workspace window for entering and evaluating larger blocks of code.

For web-developers, the Console should include a logging API and a richer interactive environment for executing live javascript against the active webpage.

The Console should fully-replace the existing Error Console window.

Comment 1

[David Dahl :ddahl]

I would love to have a console that steals ideas from iPython and zsh. Dolske and I talk about this sometimes, his version of this would be called "Mosh" and would also allow access to the OS filesystem:)

Comment 2

[Rob Campbell [:rc] (:robcee)]

I don't think we want to create a full-featured OS shell for this version. It's pretty-specifically going to be targeted at helping web-developers see what's happening as their page gets constructed and for interacting with content. We do want to have some basic-command-line features though, and the ability to dump logs to disk. Hopefully, this'll be a good platform to base some extensions off of though and iPythonish or zsh-style features would be cool.

Comment 3

[Johnathan Nightingale [:johnath]]

-> To shiny new developer tools component!

Comment 4

[David Bruant]

I have a little suggestion which is to add a support for typed errors in JavaScript. Indeed, JavaScript programmers can throw error. One of the interesting thing that can be done is throwing typed errors either native (TypeError, RangeError...) or user-defined errors.

Currently, an uncaught JS-thrown error triggers the user-defined message of the error object, the file/line number of the throw statement and the error sign to be displayed. In Opera, for instance, the error type is displayed in the console. 

Displaying this information would encourage developers to use throw and try/catch.

Thanks

Comment 5

[David Dahl :ddahl]

Was there a user repo with some code in it for this bug? Or am I mistaken?

Comment 6

[Johnathan Nightingale [:johnath]]

http://hg.mozilla.org/users/rcampbell_mozilla.com/hud/ has work through december of last year, anyhow.

Comment 7

[David Dahl :ddahl]

Is the plan to continue working on the console as an extension, or can we create a toolkit or browser component? i for one would like to all of this coding in TDD style - or can we use xpcshell tests, etc in an extension?

Comment 8

[David Dahl :ddahl]

Was just running hud in Minefield and it slowed my browser down to a crawl after about 30 minutes/ hour. At first it felt like network latency, then it became clear that the UI was becoming molasses.

It might also be user error, I was trying to view the logging pane on more than one tab, maybe 3 tabs. also ended up with a detached console, and was able to have 2 of them open. is the console a singleton?

Comment 9

[David Dahl :ddahl]

Continuing some thoughts in this meta bug, I am thinking it might be handy to log all of the data to SQLite for later querying or reconstruction of pages, what do you think?

Of course we should keep the "current" logging data cached in memory to keep latency low.

Comment 10

[Rob Campbell [:rc] (:robcee)]

this was really just proof-of-concept code to demo at the science fair. The guts of the extension will need to be rewritten. Especially the hud-service component. Right now, it's not purging anything and storing everything in an array. Not ideal in a threaded environment. We also need to have a mechanism to limit the amount of data this thing stores.

Logging to SQLite has some advantages for storage, but I'm not sure we want to keep those things lying around in profile directories. They could balloon pretty heavily without a user's knowledge. I'd also be worried about performance.

Alternatively, we could use flat files, but they're a bit ugly. In either case, I think we'll need to do some cleanup on browser shutdown.

Comment 11

[Rob Campbell [:rc] (:robcee)]

oh, re: comment #7, I think ultimately this should probably live in toolkit.

Comment 12

[David Dahl :ddahl]

Sorry for my ignorance... I was just poking around the toolkit/console dir and some things came to mind.

Will be using nsIConsoleService with this new console? I assumed we were writing everything from scratch in JS. Which is awesome.

Comment 13

[David Dahl :ddahl]

per conversations with Mossop and robcee:

best approach may be to wrap nsIConsoleMessage and nsIConsole similar to the toolkit/console front end, the difference of course is taking into account the tab the message originated from and the "headsup" ui concept for each tab.

Comment 14

[David Dahl :ddahl]

for the front end my thinking is that I need to:

1. create a pref that turns the Heads Up Display on or off
 a. initialize the HUDService when toggled on
 b. create HeadsUpDisplay console for each open tab

2. add an event listener for "TabOpen" to create a HeadsUpDisplay console when tabs are created

3. cleanup routine to remove consoles and shutdown the service when toggled off

4. UI element to do the toggling

5. UI element per tab for show/hide heads up display??

Comment 15

[David Dahl :ddahl]

Also, I was thinking we should create a new browser component like:

browser/components/devtools

and then browser/components/devtools/inspector
         browser/components/devtools/hud

does that make sense?

Comment 16

[Rob Campbell [:rc] (:robcee)]

(In reply to comment #15)
> Also, I was thinking we should create a new browser component like:
> 
> browser/components/devtools
> 
> and then browser/components/devtools/inspector
>          browser/components/devtools/hud
> 
> does that make sense?

that might be over-compartmentalizing. No need to create a separate subdir for just two pieces. Also, I don't think I'll need a component for inspector.

Comment 17

[Rob Campbell [:rc] (:robcee)]

(In reply to comment #14)
> for the front end my thinking is that I need to:
> 
> 1. create a pref that turns the Heads Up Display on or off
>  a. initialize the HUDService when toggled on
>  b. create HeadsUpDisplay console for each open tab
> 
> 2. add an event listener for "TabOpen" to create a HeadsUpDisplay console when
> tabs are created
> 
> 3. cleanup routine to remove consoles and shutdown the service when toggled off

you might need another cleanup routine (and a settable pref) to scavenge max entries per hud. Something sufficiently large like, say 10,000 entries or more.

> 4. UI element to do the toggling

and hotkey! Cmd-; ? ;)

> 5. UI element per tab for show/hide heads up display??

I think one toolbar button is probably all the UI we'll need and most people probably won't even use that in favor of the hotkey.

otherwise, all sounds good!

Comment 18

[David Dahl :ddahl]

inspiration:

http://dreampie.sourceforge.net/

Comment 19

[David Dahl :ddahl]

Spent a great deal of time in gdb and talking to both mrbkap and sicking about a possible bug in cloned xbl nodes. 

I am cloning a set of nodes to create each HeadsUpDisplay. I am going to just programmatically create all of the nodes to see it that fixes the issue.

Comment 20

[David Dahl :ddahl]

After spending all evening on this, unless we can figure out out how to actually load "about:hud" into a dynamically created iframe node, we may have to go with a xul node for the output. Not really a big deal. we can just wrote an API for skinning it and whatnot. Perhaps a timer that runs and checks to make sure the right uri is loaded before completing construction? I am still not sure if that will even work at that point.

Comment 21

[David Dahl :ddahl]

Attempted to create a user repo, but my Lab's commit access does not seem to grant me user repo access. I'll keep the patches up to date all of the time and build some try builds every week.

Comment 22

[David Dahl :ddahl]

The current console patches are found on bug 545266 and bug 546708 - also try builds will start once things are actually usable - I hope end of next week. It turns out that trying to attach (and keep attached) an arbitrary object on a nsIDOMWindow is a it of a pain - from outside the window's constructor. sicking told me about his patch for detecting new windows (before content scripts run) and attaching objects to them: bug 549539 - which landed late today. Yay. With this patch on trunk it should be trivial now to detect window construction and attach a console.

Comment 23

[David Dahl :ddahl]

started a user repo: http://hg.mozilla.org/users/ddahl_mozilla.com/heads-up-display/

Comment 24

[David Dahl :ddahl]

Latest Try build is here: https://build.mozilla.org/tryserver-builds/[e-mail]-HUDConsole0415/

Latest changesets are here: http://hg.mozilla.org/users/ddahl_mozilla.com/heads-up-display/

Comment 25

[David Dahl :ddahl]

Looks like the web timing spec has the start of an implementation in Gecko: bug 570341

Comment 26

[David Dahl :ddahl]

All patches are landing on trunk now for inclusion in Fx 4 betas

Comment 27

[Mihai Sucan [:msucan]]

This bug is fixed for all practical purposes. Please reopen if you believe otherwise.

We have a Web Console for web pages, a debugger and soon a Global Console that could replace the Error Console.