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:)
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.
-> To shiny new developer tools component!
Component: General → Developer Tools
QA Contact: general → developer.tools
Was there a user repo with some code in it for this bug? Or am I mistaken?
http://hg.mozilla.org/users/rcampbell_mozilla.com/hud/ has work through december of last year, anyhow.
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?
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?
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.
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.
oh, re: comment #7, I think ultimately this should probably live in toolkit.
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.
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.
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??
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?
(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.
(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!
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.
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.
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.
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.
started a user repo: http://hg.mozilla.org/users/ddahl_mozilla.com/heads-up-display/
Latest Try build is here: https://firstname.lastname@example.org-HUDConsole0415/ Latest changesets are here: http://hg.mozilla.org/users/ddahl_mozilla.com/heads-up-display/
Looks like the web timing spec has the start of an implementation in Gecko: bug 570341
All patches are landing on trunk now for inclusion in Fx 4 betas
9 years ago
Depends on: console-a11y
Summary: Create an Interactive Console for debugging web pages → [meta] Create an Interactive Console for debugging web pages
Component: Developer Tools → Developer Tools: Console
QA Contact: developer.tools → developer.tools.console
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.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.