Ask HN: Webdevs, designers: what devtools should we (Mozilla) build in Firefox? - <AUTHOR> I'm @paulrouget. I'm part of the Firefox Developer Tools team (we are working on the builtin tools and Firebug). I believe that the HN community includes a lot of web developers and designers, so I guess you can help us.
We have recently added a bunch of new builtin tools in Firefox (please try Firefox Aurora or Firefox Nightly to see a recent version of these tools). We also redesigned the way we show these tools (screenshot here: http://paulrouget.com/e/toolboxTesting/).
We are now working on defining what should be our next moves, and I'm trying to gather as much feedback as possible.
The current plan is to build a bunch of performance-related tools (see https://groups.google.com/forum/?fromgroups=#!topic/mozilla.dev.developer-tools/L9vfZ1-smUI), improve the user interface (better theme), make the tools remotable (for mobile development), and drastically improve the WebConsole (see an experiment here: http://paulrouget.com/e/jsterm.v2/).
But we really want to get as much feedback as possible to make sure we're going into the right direction.
What do you think we should add/remove/fix in our tools? Anything you miss from Chrome or Opera? Or anything you haven't seen yet you'll like to see part of the browser?
PS: because a lot of people have raised concern about "cluttering" Firefox: we are considering providing some of these tools only as addons, to keep the Firefox DevTools as simple as possible. <comment><USER5> This is a big request:

Improve "design in the browser" capabilities. i.e. pushing CSS/HTML and maybe JS changes made in Dev Tools back to the source files without manual shenanigans in the middle.

I probably waste more time copying CSS / HTML tweak diffs from the browser back into the related source files than anything else with in browser dev tools. Due to the nature of 'losing changes' if I happen to hit refresh or if the page has some automatic polling mechanism I also tend to do this very often as some sort of manual 'save' action.

There have been a couple attempts to do this (<http://www.cssupdater.com/> or <https://code.google.com/p/backfire/>). But, I'd really like to see a standardized protocol for pushing changes to the server such that server side frameworks can implement it appropriately.

For example a server side implementation for Rails needs to understand the asset pipeline to know how the final file was created so it can work its way back to the correct file to save changes to. This also means you probably need source map style support for LESS and SASS also. Also to change HTML template files the server side needs to know how the page was constructed so it can find the correct partial / template to save changes to. Which is probably really hard depending on how much state based conditional rendering there is in your templates, maybe the server side caches the last response and associated state to work around this.

<comment><USER6> If a browser supported PUTting the modified resource back up to the server, we'd be off to a good start. Server-side frameworks could then add functionality to split the modified resource back into the files that created it.

<comment><USER7> What about pre-processors (SASS, Less) or templating engines (ERB, Haml, Slim)? That would seem to be a huge task to "un-pre-process" an asset. Going backwards is immensely difficult. These are not easily reversible processes.

Instead, why not make something like IntelliJ/RubyMine/WebStorm/etc.'s Live Edit plugin a native part of the browser. Allow the asset pipeline to tell the browser it has changes available, rather than try to have it regurgitate all the processed assets. That would be relatively easy to add and very straightforward to implement.

<comment><USER8> Your Live Edit idea is a good one, but I think the assumption about "un-pre- processing" would be part of the pre-processing development tools understanding what was being pushed to them, therefore, the need for an open standard as has been alluded to above.

</comment></comment></comment></comment><comment><USER9> I have to be honest - I find the developer tools a pain: They aren't even close to replacing Firebug, yet they're more obtrusive. So I can't stop using Firebug, and I can't remove the unwanted built-in menu options.

So for me personally, what I'd really like to see is either one of:

\- Match Firebug feature for feature

\- Allow for the dev tools to be completely removed from the interface

Sorry, but it really does come down to those two: Whilst the Dev Tools can't replace Firebug, I won't use them. So either allow me to get rid of them, or allow me to switch 100% to them.

Sorry it's not more constructive, but I've no interest in having to juggle between two different debug tools because they both have awesome features. So I don't care what amazing new stuff you might be lining up, I won't use them until all of the functionality I use in Firebug is also available in FF's builtins.

<comment><AUTHOR> > They aren't even close to replacing Firebug

That's why we still work on Firebug :)

> yet they're more obtrusive

It should be better in Firefox 21.

> I can't remove the unwanted built-in menu options.

Firebug allows you to do that. But seeing the number of comments about this specific issue, I think we can do something smarter.

> Sorry it's not more constructive

It's actually a great comment :)

<comment><USER10> > That's why we still work on Firebug

To be quite frank, this is really ridiculous to me. Why in heck are there TWO separate developer tools for one browser that are _both_ in-house? Supporting both tools means that neither one moves as quickly, and there's a ridiculous amount of confusion as to which one to use.

Imagine the noobie developer that has cut their teeth on the elegant Chrome dev tools. Now they need to do some Firefox compatibility work and the first thing that happens when looking at the documentation they see both "Firefox dev tools" and "Firebug" being referenced, each with different use cases and slightly different functionality.

I don't think any other issue is matters as much until you can solidify your efforts and officially support just one set of tools. Once you do that, then I think it's worth talking about all the other improvements that need to be made.

<comment><USER11> Firebug isn't in house, it just has contributions from Mozilla employees.

<comment><USER12> More than 2/3 of work on firebug is done by 1 mozilla employee, and there 2-3 other people we contribute to firebug from time to time. So it's pretty much in house.

IMO starting complete rewrite of firebug, in form of devtools, was very wrong. 2 years ago firebug was order of magnitude better than chrome devtools. Now it can't keep up with chrome. But firefox devtools only starts to become barely useful, If all that work have gone into improving firebug, Firefox would be ahead of chrome now.

</comment></comment></comment></comment></comment><comment><USER13> Honestly, the absolute best thing you could do for any dev, is lighten the footprint FF currently has on my ram, and continue to improve the api for add- ons/plugins. The more stable, extensible and _fast_ FireFox is, the more useful I will find it for development. But if more kludge is added to it, and it continues to get slower/bigger, the less likely I am to continue to use it, regardless of what amazing plugins are available (FireBug, Web Developer Tool Bar, etc)

If you are just looking at what's best to add to the browser itself, just look at the plugin market to see what's in wide use.

<comment><USER14> I thought that the latest browser tests showed that FF used less ram than Chrome. [http://lifehacker.com/5976082/browser-speed-tests- chrome-24-...](http://lifehacker.com/5976082/browser-speed-tests- chrome-24-firefox-18-internet-explorer-10-and-opera-1212)

Unfortunately, reputations stick.

<comment><USER15> Indeed, everything I've seen recently points to FF as having a slim lead over Chrome. It's just that for many of us, the last time we used FF was right before we switched to Chrome, so our perspective is frozen at that point.

</comment></comment></comment><comment><USER16> Hey Paul. First off, thanks for reaching out to the community like this.

A few things:

Visualized event bindings. Would be awesome to have a visual indicator of event bindings right on the page. Color-coded bounding boxes drawn around elements with a label denoting the event type. Clicking on that box (or label in the case of an element with multiple bindings or nested elements with bindings) would direct you to the code that does the binding.

An aggregate repaint view. Chrome lets me view repaints but it clears after every one. If I have a method that is doing a lot of dom manipulation, I have to step through the code to view all of the repaints. Would be great to have the repaint bounding boxes drawn with a low opacity background so that I could see (and clear out) an aggregate view (with highly redrawn areas having higher opacity due to there being multiple layers).

An intelligent debugger that would automatically step over certain files (selectable per debugging session). I occasionally want to step into jQuery but less often than not. I know I can step over those methods but would be great if I could just keep stepping in without accidentally stepping into something when I don't want to.

I'll edit this as I think of more.

EDIT:

Breaking on navigation or on a particular request in order to manipulate headers. Breaking on the response from those requests for the same reason (plus manipulating the body).

The timeline and profiles sections in Chrome are under-utilized but infinitely useful. Anything close to those would be much appreciated.

Throw warnings for potentially orphaned event listeners. Granted, the number one offender recently introduced methods to address this (backbone's #stopListening) but it's still a easy mistake to make. This might bleed into too much hand-holding and open up a can of worms but just a thought.

Throw warnings for overloaded event listeners that fire a lot. Like the last suggestion, this may be heading in a direction you don't want to go in (educating the developer by means of the dev console) but, all too often, I find pages that overload, e.g., the scroll event. If there was some way to inform the developer of this potential problem, I think the web at large would greatly benefit. Perhaps this and the last suggestion would better reside in an auditing section?

<comment><USER17> > Visualized event bindings. Would be awesome to have a visual indicator of > event bindings right on the page. Color-coded bounding boxes drawn around > elements with a label denoting the event type.

A bit of shameless self promotion - I wrote a bookmarklet to do that asking talking to a couple of Mozilla folks a few years back: <http://sprymedia.co.uk/article/Visual+Event+2> . Source is available on GitHub: <https://github.com/DataTables/VisualEvent> .

The biggest problem I faced with this is that there is no DOM method to get a list of the events that have been bound to a node. Possibly a Firefox plug-in would have the ability to access that information, but it can't be done through the DOM at the moment, so I had to resort to parsing the information available from the libraries, each needing its own integration file...

<comment><USER18> Thanks for the awesome tool! I've found it handy on more than one occasion to trace jQuery/vanilla JS listeners. Any plans for Dojo support?

<comment><USER17> Hadn't been planning it, but it sounds like a very sensible idea! Added an issue in GitHub which you can follow if you like: <https://github.com/DataTables/VisualEvent/issues/26>

</comment></comment></comment></comment><comment><USER19> Hi Paul, how about when serving pages that are https, but contain mixed content, highlighting somewhere exactly what the offending requests are. Currently, I have to scan the network pane and see what's coming from the <http://> domain, but it'd save me a few seconds if this was more automated.

<comment><AUTHOR> We do have plans/patches for that.

</comment></comment><comment><USER20> How about exposing an API for dev tools similar to the "swank" protocol that Emacs uses for editing Lisp code? I know there are people doing stuff like this already, but it would obviously be a lot easier if there were a nice protocol for it (ideally standardized across browsers...). I want to be able to seamlessly interact with a running Firefox instance from my editor or IDE, sending it snippets of code to evaluate and seeing my page change in real- time.

<comment><AUTHOR> That's interesting. I'll look at that. Thanks.

<comment><USER21> If using swank is impractical, the Clojure community is in the process of shifting from swank to nrepl. I haven't looked into the details of either but wanted to point out another option.

</comment></comment></comment><comment><USER22> It would be nice if there was a way (or ways) to ease the pain of debugging minimized CSS/JS files.

We've all been there, right? Uncaught exception on Line 2, Column 49,392 of /foo/jquery.min.js, right?

1\. For well-known source files (like major jQuery releases, etc) perhaps the debugger could (optionally) switch to the unminimized version. This could be done via file hash comparisons based on a table stored on Mozilla's servers (oh, I see you're using jquery.min.js which has a hash of 498DE248A4B which corresponds to the unminimized file jquery-1.9.1.js on Google's CDN) or perhaps the debugger could just optionally substitute "foo.js" for "foo.min.js" if it exists on the server.

2\. For cases when #1 fails, perhaps the debugger could at least pretty-format the source code so that it's not all on a single line of code 30,000 (or whatever) characters long, so that breakpoints could be set.

<comment><USER23> This is what sourcemaps are for. You can minify your JS files with the Closure Compiler and tell it to create a Source Map. Then tell the developer tools to use that sourcemap and you'll debug looking at the unminified code even if you're running the minified one.

[http://www.html5rocks.com/en/tutorials/developertools/source...](http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/)

<comment><USER22> First off, thanks for the link! I up-voted you; that's a really good introduction to source maps.

I believe it would be incredibly useful if FF's dev tools could do some of this on their own; primarily for the reason that the person debugging the Javascript can't always control the build process. The times when you don't have access to the build process and/or the original unminified code are the times when you need this functionality the most.

<comment><USER23> If you don't have any of those, then I don't see how the developer tools can figure out what the original source is. You need some way of mapping points in the minified file to lines in the original file. Ask your favorite CDN to also host a source map. Otherwise the best the developer tools can do is prettify the minified file, something both Chrome and IE do (I don't recall if Firefox Nightly does).

<comment><USER22> "If you don't have any of those, then I don't see how the developer tools can figure out what the original source is."

You don't think that un-minifying and pretty-printing the minified Javascript would be both:

a) a lot easier than debugging an error on line 1 at column 28,482? and b) technically possible?

</comment></comment></comment></comment></comment><comment><USER24> My biggest annoyances with the dev tools right now are:

1\. The debugger has no REPL. If you evaluate a statement in the console, it doesn't run in the current stack frame and has no access to locals, etc. The only way to execute a statement in the current stack frame is to add it as a "watch" and then delete it.

2\. There's no way to get to the console from the debugger and vice versa. You have to activate them independently in two steps, which is annoying because I almost always want both of them. Also, they stack in a different order depending on the order they're activated, which is unnecessarily confusing.

3\. There's no way to "pause on uncaught exceptions". It's either "pause on all thrown exceptions" or nothing. Also, the UI is buried in a menu. Exception breakpoints should be shown in the breakpoint pane like other breakpoints, and should be filterable by exception type and whether the exception is caught or not.

<comment><USER23> 1\. Yes, this. 2\. Try the Aurora channel. Now the developer tools look pretty much like Firebug 3\. Yes!

</comment></comment><comment><USER25> I think I'm just used to the WebKit dev tools, but I find it requires more work to get to the Script tools, etc in Firefox than Chrome. For example, in FF I have to go to Tools -> Web Developer -> Debugger to get to the debugger. I can't just get there by doing "Inspect Element".

I'd like to see all the tools combined into one mode and allow me to pop it out into a new window. If I can do that right now, it's just not intuitive.

Also, it'd be great if FF pushed people away from Firebug, as I didn't know FF had built in tools and I was resorting to Firebug each time.

Just some thoughts. Great work!

<comment><AUTHOR> All you said has been implemented in Firefox Aurora.

</comment></comment><comment><USER26> I would say make Firefox as light and fast as possible by keeping ALL developer tools as addons. Most users aren't going to need them at all, so it's just eating up space for no reason.

I personally prefer Firebug over Inspector, so I would rather see you throw more resources into integrating it fully with FF.

<comment><USER27> That new Inspector thing is really annoying. I always accidentally open it instead of Firebug. From a developer stand point, Firebug stills beat all other browser dev-tools by a mile and is the main reason I still have Firefox on my dashboard.

<comment><USER28> You can turn off the built-in Inspector by going to about:config. There's an option in there (I forget the name of it off the top of my head... probably something like "inspector"!) and you can change the Boolean value to 0 and it will no longer appear in the context menu.

</comment></comment></comment><comment><USER29> Paul, can you comment how Firebug fits into this?

I mean there is A LOT of people who routinely use Firebug. Heck, I am actually _designing_ sites with it. So from my perspective the best thing moving forward would've been for Mozilla to adopt Firebug as a standard DevTool. Frankly, it pains me to see two almost identical tools being developed in parallel, while it would clearly benefit everyone much more if it were a single, unified effort, with freed up dev resources spent on something else.

<comment><USER30> Firebug is a monster ram whore, ideally the functionality would be built into firefox so it can be maintained as a core-set functionality. Then they can assemble unit tests etc to make sure it's there for the longrun.

</comment></comment><comment><USER31> I would like a record/replay feature for AJAX requests or at least an interface where I could easily assemble a request as if it was sent from the current app.

A possible "exporter" for the changes you made on the current web page would help some people I know, specially with CSS stuff.

Some integration with MDN documentation would also be a boon, like right- clicking a function and seeing the docs. Like Lisp HyperSpec gizmo.

I don't think that the inclusion of dev tools is cluttering or bloating. We should always include them even if the final user never uses it. The potential for a free tweekable web is there. Lots of people start learning more about webmaking by trying stuff on web consoles.

PS: On saturday I will be a speaker on the largest Javascript event in Rio de Janeiro (<http://riojs.org>). I will be speaking about Firefox OS (I am a mozillian volunteer) and I will be showing all my stuff using the current devtools from the responsive design view to the web console, so BIG THANKS to @paulrouget and the team for making my life easier!

</comment><comment><USER32> The guy is asking for suggestion to the DEVELOPER TOOLS... no to the firefox browser itself.

I have to admit that i changed my dev browser to chrome. The chrome developer tools are great. I like to have everything on one panel instead of the console in one place and the html and css in another.

<comment><USER33> If you viewed the above screenshot, you would see that in fact the current Firefox developer tools do the same thing.

</comment></comment><comment><USER34> Excellent initiative! I'd personally kill for a tool akin of Chrome's timeline, where to debug performance issues not related to javascript, like rendering e.g. things that trigger a complete screen redraw and whatnot. I'd really like to see this happen because at the moment if an app is super snappy on Chrome but slow on Firefox and javascript is not the culprit, I'm left basically to guess how to improve the performance.

<comment><AUTHOR> We have a plan for performance tools: [https://groups.google.com/forum/?fromgroups=#!topic/mozilla....](https://groups.google.com/forum/?fromgroups=#!topic/mozilla.dev.developer- tools/L9vfZ1-smUI)

</comment></comment><comment> Su-Shee So far I'm just not using the Developer Tools at all, because they don't give me what Firebug does.

Debugger, Inspect and Web Console just aren't working well together, aren't interegrated smoothly into each other and I hardly can get from one to the other. I can't enable ALL of them at once.

If they _were_ like Chrome's tools or Firebug I'd wish for the features of Firebug's XPath and CSS extension: input expression, get matching elements highlighted.

So, either they have to be as useful as Firebug, or throw them out to keep FF lean for users who doesn't need them anyways.

Also "keep the DevTools as simple as possible" makes absolutely no sense to me as a Web Developer - I need those tools as GOOD as possible and as USABLE as possible with a specific range of features I've come to expect from Firebug and Chrome.

I mean, I basically live with an open Firebug during work...

</comment><comment><USER35> I'd greatly appreciate a performance monitor that is tab specific or even code specific. If you can dial down that one of my methods are using up 80% of my memory, please let me know. Or if the reason my page keeps crashing is because some knucklehead is still using flash poorly for ads, then I need to know that.

From that, if you can "label" sites or ad styles or script styles that are known to perform poorly, that would be amazing.

I find it difficult to edit code in place and see its change. It'd be nice if when I Right Click > Inspect Element; I can track the changes, and maybe even see side by side comparisons. Most of us have multiple monitors so screen real estate isn't an issue. Maybe even be able to let us launch a new window and edit the currently rendered page would be nice.

<comment><AUTHOR> We have plan for performance tools. See: [https://groups.google.com/forum/?fromgroups=#!topic/mozilla....](https://groups.google.com/forum/?fromgroups=#!topic/mozilla.dev.developer- tools/L9vfZ1-smUI)

</comment></comment><comment><USER36> I work a lot on a Firefox extension, and honestly, the absence of dev tools for addons is really painful. Developping our extension for Chrome was super easy, since all their default devtools work in extension panels as well, but in Firefox it's been a nightmare, almost no tools. We are left off in a console.log madness trying to figure out what's causing bugs.

It would be soooooo awesome to have Firefox's default devtools working easily in extension panels!

<comment><AUTHOR> We have the inner architecture for "chrome" debugging (extensions debugging). This sill needs some more work though.

<comment><USER36> Can we expect improvements to this in the near feature? It would definitely make the idea of making firefox addons more inviting.

</comment></comment></comment><comment><USER37> Embed mozrepl <https://github.com/bard/mozrepl/wiki> or something simular. I'd like network based access (restricted to a socket or localhost by default) to the innards of the browser. Mozrepl works, but has proven fragile. I've had to make several updates to keep it working with the latest Firefox nightlies.

I've currently got mozrepl hooked to emacs so when I save a js, coffeescript, or css/scss file it live updates the page. This makes development so much quicker. I know there's several other methods of achieving this, but to be clear I'm not talking about reloading the page, I'm talking about updating the backbone model of type Foo to have a new definition when I save model/Foo.coffee.

I can also see this being useful for acceptance testing. I'd imagine that the Selenium project would also be interested.

<comment><USER38> >Embed mozrepl <https://github.com/bard/mozrepl/wiki> or something simular. I'd like network based access (restricted to a socket or localhost by default) to the innards of the browser. Mozrepl works, but has proven fragile. I've had to make several updates to keep it working with the latest Firefox nightlies.

That looks really interesting. I just tried out swank-js and it worked for simple javascript, but it didn't work with dojo (going to debug that and see if there isn't an easy solution).

How does this work with more complex javascript? Does it work with libraries like jquery or dojo? Does the link you gave have your fixes? I will probably give this a try tomorrow, thanks for the link!

<comment><USER37> I use it primarily with ExtJS and backbone. What I've done with mozrepl is inject some global javascript, then call methods off it over the network link, so for instance I have a reloadModel method that will remove the model's definition (basically delete window.Foo, but a bit more to it), then reload's the JS file which re-creates it. I've got this bound to occur automatically with emacs when coffeescript/js files save.

This method works for anything that can be removed from a system then reloaded. I'm not sure you could do that with jQuery, but you might be able to with a plugin I suppose. No idea on dojo, sorry.

My fixes for the nightlies is at: <https://github.com/nathanstitt/mozrepl> I haven't submitted a pull request until I'm sure things have settled down with the Firefox changes, but plan to do so soon.

Hit me up if you want further details.

</comment></comment></comment><comment><USER39> Prettyprinting/unobfuscating the JavaScript sourcecode (like in chrome and opera) would be nice.

<comment><AUTHOR> Sourcemap support + unminification are coming.

</comment></comment><comment><USER40> The JavaScript object browser mini-windows do not behave properly on Awesome, a tiling window manager. There is no way to close the windows without closing the entire web console. If I try to close the window like I close any other window, it will close the full browser window.

<comment><AUTHOR> We are already working on that (we call the "variable view"). It won't be a window anymore.

<comment><USER40> Thanks! I am running a current Nightly, do you know when this might land?

I am remarking today that on my system, Firefox must use less ram today than it did in 2005. Great work!

</comment></comment></comment><comment><USER41> Websockets inspection would be very nice. To my knowledge no browser does support this and it would be very handy IMHO.

<comment><USER42> Chrome does: <http://i.imgur.com/KLmkYjH.png>

<comment> iso-8859-1 Your DPI is insane! What are you using?

<comment><USER43> Maybe a MacBook Pro with Retina Display?

</comment></comment></comment></comment><comment><USER44> I really love what you're doing with the developer tools in Aurora. But I'm missing a network tab.

<comment><AUTHOR> Thank you :) Network tab is our next tool.

</comment></comment><comment><USER45> The console certainly needs some love. I love that it opens so fast and feels so light compared to Firebug. I don't use it because:

* I can't select and copy text from the console's output (it's a listbox now)

* The autocomplete is not as good as Firebug's and hitting enter does not complete it

* The inspector does not remember the width of the two panels (left with DOM/right with CSS rules)

You get the idea. You've completed the 90%, now fix the 10% left.

<comment><AUTHOR> I get the idea :) Thanks.

</comment></comment><comment><USER46> The main reason I'm still using Firefox as my main browser is Firebug, which is still better than the competition. Unfortunately it's a memory hog and dramatically slows down the whole browser. So my vote goes to performance improvements for Firebug.

</comment><comment><USER47> Throw an error if a ajax request fails because it's a cross domain request. Last time I run into that problem everything looked good but the request silently failed and it was only when I tried it in Chrome that I got a hint what might go wrong.

<comment><USER48> +1 this request, I deal in failing CORS a lot and still always get caught out by this

</comment></comment><comment><USER49> Add better support for keyboard shortcuts. I use firefox every day and I still prefer it to chrome because it has better keyboard shortcuts, but they could be better still.

1\. I can't disable Ctrl-P/Cmd-P that maps to print screen. I use emacs and this conflicts with many shortcuts that I am used to using. The print dialog takes a full second to display. I haven't had a printer in 8 years.

2\. Firefox gives webpages more extensive key capture capability then chrome. Some pages take away the ability to press Ctrl-L to get to the firebug console, this requires me to use a mouse. It's slow.

3\. I don't know how to setup a key mapping to change the zoom style.

<comment><USER50> Ad. 1: Install keyconfig: <http://mozilla.dorando.at/keyconfig.xpi> (more here: <http://forums.mozillazine.org/viewtopic.php?t=72994>). I've been using it for ages.

Ad. 3: what do you mean? To toggle between zoom-text-only and standard zoom? Unfortunately I don't know a way to do it either.

</comment></comment><comment><USER51> Would it be possible to make JS lint available in Firebug? Preferably in such a way that all scripts included from a currently opened site are automatically linted?

At the moment I go to www.jslint.com to lint scripts, which is such a PITA.

<comment><USER52> I would recommend running jslint or jshint locally on your machine instead of pasting it into the website.

</comment></comment><comment><USER53> Support V8's debugger protocol so we can use the WebKit Inspector.

</comment><comment><USER54> It would be great if it was easier to debug errors like this:

        [12:11:02.525] Empty string passed to getElementById(). @ https://ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js:3

Especially when Firefox throws the error and Chromium doesn't.

<comment><USER55> For what it's worth, it's a warning, not an error. And Chrome doesn't have this warning at all, hence it not showing up there.

<comment><USER54> Sadly, it's the only clue I have as to why my form's submit button isn't working.

<comment><USER55> The chance that this warning has anything to do with the submit button not working is low, unless it doesn't work in all browsers.

</comment></comment></comment></comment><comment><USER56> I would love to see something akin to YSlow's Statistics tab. <http://d.pr/i/QC0g>

I also support the idea of not competing with Firebug, and possibly absorbing it into the Firefox project. It seems wasteful to have developer resources tied to both in parallel.

To the existing dev tools in Firefox: \- The UI layout could be improved quite a bit, expanding by default and taking up less screen real estate. e.g. the CSS panel could be part of the source view, like most devtools UI. Lots of space on the right side going unused in that panel anyway. \- devtools.inspector.htmlHeight needs to at least be doubled \- everything under devtools.inspector. needs to default to true (I realize this is contradictory to my earlier statement about real estate \- Is the 3D view really needed? Seems like this could be an add-on also. \- Picky one: I would prefer the toolbar/breadcrumbs to be on the top of the panel. Makes it easier to distinguish on a page that looks similar.

I do really like the :hover :active toggles, and the markup viewer mode though. :)

</comment><comment><USER57> I think the output/pretty-printing of objects is lagging far behind Firebug/Chrome Devtools. Would like to see this improved.

Also, the request interface seems kludgy and could be optimized. Having to turn on logging of req/res bodies is an annoying extra step. I feel if the devtools are open it should do that.

Thanks for all your effort. Looking forward to upcoming devtools releases. JSTerm is awesome also!

</comment><comment><USER58> I'm a big Firefox fan for one major reason : it's the most customizable browser out there. I just _love_ the right-click/Customize and all the available extensions.

My suggestion won't be for a new tool, but it's a suggestion anyway : Please _always_ allow users the decide what they prefere. Choose any defaults you think are the best, but always add a configuration to be able to change it!

An example of this : I don't remember when exactly, but in one release, Firefox devs decided to remove the "loading cursor"( <https://bugzilla.mozilla.org/show_bug.cgi?id=482985> ) without any config:about setting to enable it back!!! I was furious, not simply because I prefere to see this loading cursor, but because Firefox didn't allow me the choose what _I wanted_.

Thanks for reading and thanks a lot to all devs contributing to this wonderful browser!

\-----

(By the way, it's now possible to enable the loading cursor using ui.use_activity_cursor = true)

</comment><comment><USER59> I really dislike how chrome display :before & :after in the styles pane. More often than not these pseudo selectors contain quite important styling that's hidden away in the styles. Not sure how you can fix this, but there must be a better way.

Any chance you could remove the animation that appears when using the element selector? I find the flicker very distracting.

</comment><comment><USER60> Need to be able to profile frames/second for HTML5 gaming. The frames part of the timeline tab in Chrome is extremely useful.

<comment><USER22> I'd also love other performance hints with regards to optimizing for games or other things that require heavy animation.

\- Which layers/elements are being hardware-accelerated, and which aren't? Just as importantly, why or why not? \- How much VRAM is being used by which element/etc, and how much total RAM/VRAM am I using at a given moment?

</comment></comment><comment><USER61> I'd personally really like a remote debugging API (Does one already exist) Particularly I'd rather debug in my editor than in Firefox, at least for certain things, there is integration that I could implement in emacs, or even a javascript based Development Environment that just would not be doable without project specific code.

</comment><comment><USER62> Cookie handling needs to be visible, not just for devs, but normal users. Maybe a little bar that shows that first party and 3rd party domains are offering cookies and users can allow them as needed or set defaults they are happy with (like having to white-list third-party cookies on an as-needed basis instead of allowing everyone to track you by default). Not only would these cookie controls allow for easier development, but they would make it obvious that sending cookies back to a site is something that the browser (as an agent for the user) is doing voluntarily on behalf of the user, so we can do away with "cookie laws". The fact that cookie laws exist is related to the fact that nobody understands that accepting/using cookies is perfectly voluntary. Nobody knows this because cookies management is insanely obscure and difficult in all browsers Firefox inclusive.

</comment><comment><USER63> A clear strategy as to which dev tools will be maintained in the future.

Will Firebug and Firefox Dev Tools coexist? What's the plan there? It seems like a duplication of effort from Mozilla.

<comment><USER64> My understanding is that Firebug is discontinued from Mozilla's side (which means nothing wrt any volunteer effort ongoing there, btw!), but they assist in keeping it alive on Firefox updates because the native tools don't have the same functionality yet.

<comment><AUTHOR> Our team also work on Firebug. So no, it's not "discontinued".

We are working on sharing more code. In an ideal world, we will be able to merge these 2 tools in the future.

<comment><USER64> But does "work on" mean "maintain so it doesn't break" or "actively improve"?

<comment><USER65> Jan Odvarko, the current maintainer of Firebug, is on our team. He's currently the only Mozilla employee dedicated to the Firebug project. He's joined by a healthy community (you can follow the project at <https://github.com/firebug/firebug>).

Jan and the Firebug team are actively improving Firebug - not just maintaining it so it doesn't break. The bulk of the Mozilla staff (and our volunteer community) is focused on the built-in tools, but a lot of it ultimately benefits the Firebug team.

The standby example is our debugger. A lot of the performance and stability problems Firebug has are a symptom of the old Spidermonkey debugging API (JSD). The developer tools and Spidermonkey team built a new debugging API[1] along with a remote debugging server. The Firebug team is currently working to update Firebug to the new debugging API/remote server.

Most of our work is dedicated to the built-in developer tools. But those also support Firebug development.

[1] <https://wiki.mozilla.org/Debugger>

</comment></comment></comment></comment></comment><comment><USER66> I love the work that you guys are doing on these tools, they've really come a long way in a short period of time. I find I prefer them to the Chrome tools for a number of reasons. However, I occasionally swap to Chrome for a couple of things:

\- The timeline tab. I know there's a profiler panel in FF now, but I have trouble interpreting the results. This may have changed.

\- Better stack traces

\- The networking tab. Looks like this is in the pipeline. I can't wait to see what you come up with).

\- In the style editor, as an Emacs user, I _always_ accidentally ctrl+n to a new stylesheet instead of the next line. I'd really enjoy an easier way to edit keybindings.

\- Live editing of JavaScript in the debugger would be really killer

\- I often wish the debugger had the "pretty print" button Chrome offers to diminify scripts in the Sources tab.

On another note, Paul, I love the work you're doing on JSTerm. Keep up the great work.

</comment><comment><USER67> My request would be a way to plug into the developer tools, similar to Firebug. That way things like Firephp logging woule be possible without the overhead of Firebug.

<comment><AUTHOR> There's an API for that.

</comment></comment><comment><USER68> Thanks for doing this post! Some things I'd like to see:

* Less UI chrome. The blue bar doesn't need to be blue and element breadcrumbs don't need to be fancy styled boxes. Large elements don't even fit in them and get chopped off.

* When I hit Ctrl-Shift-I the FDT open, but if I have the dialog detached it immediately loses focus and I have to alt-tab to see it.

* I find Chrome's Network inspector to be _very_ useful for tracking APIs and checking headers/responses etc.

* It'd be nice if Firefox had an option to 'deminify' Javascript source in the debugger. The same for CSS.

* Built in html/css/js lint would be a nice feature

      * Right click -> Save option for CSS. The "Save" hyperlink is great but it took me too long to spot it.

That's all I can think of for now. I will continue playing and post if I have any more suggestions. :)

<comment><USER69> Deminifying is probably going to be standardized as source maps. That will (or should) eventually land up in all the browsers.

</comment></comment><comment><USER70> I believe all the current development tools do it wrong, and the right place for a tool is _outside_ the browser, as a custom shell around the main browser component.

This is how I tend to work: I load up an app. I set up my credentials (by logging in or setting a particular cookie manually, for example). I debug using Firebug, mainly using the DOM view, the console and the JavaScript REPL. Then I might change my credentials to see the page as a different user, for example. I clear the cache now and then, and I clear my cookies often. I also change things like cookie preferences and turn JavaScript on/off to see how my app behaves. I also work on multiple projects concurrently, so I frequently need to switch, meaning yet again to clear the browser state.

In other words, I _need the browser as a clean slate_. I frequently need to throw its state away, and I rarely if ever run pages as "myself".

I'm a Chrome user, so for this reason I currently use Firefox as my dedicated debug browser. This means I can always throw away my browser state, and I can close Firefox when I'm done with work. Firefox is a resource hog on OS X, and will frequently sit consuming 5-10% CPU even when idle, so this is actually important. I almost never use Chrome for debugging, not just because its DOM view and console are both much worse than Firebug's, but because it's my browser. (Yes, I know that Chrome supports per-window profiles, but Chrome just isn't good enough for debugging.)

My ideal development tool would be a thin shell around a web browser component. It would be chock full of techy dev stuff, and it would not compromise the dev aspect in favour of user-friendliness; unlike today's browsers, everything could be provided natively by the tool instead of inserted awkwardly by "extensions". It would do away with user-facing features like browser extensions, fancy history and bookmarks. In other words, it would be a hard core, bare-bones development tool.

This tool would support "projects"; each project being is a browser window, and each browser window is logically compartmentalized, with its own cookie database, history, settings, etc., with the option to save certain things like cookies, so that I can "bake" current browser state and recall it later. The ideal solution would be for each window to be able to embed different browser engines; there is no particular technical reason why this should not work, although it would be a little more work to implement.

I actually started writing an app like this for OS X that embeds WebKit. It was surprisingly simple, and I got a decent DOM inspector view and style editor working, but then my mind wandered off to work on something else. I may pick this project up again at some point.

<comment><USER71> Prism used to be kind of cool but Mozilla abandoned it. There also used to be more focus on being able to build arbitrary tools around Gecko but Mozilla abandoned them (except for specialized OSes?).

Gecko is my favorite layout engine and Mozilla makes my favorite browser environments. Firefox gets weirder and weirder sadly.

The multiproject browser environment thing sounds really cool. Multifox does some of that but its interface strikes me as a bit awkward.

Just so you know, Firefox does allow you to run multiple profiles simultaneously in different instances. I do this all the time. Just "firefox -a blark -P profile_name" (or -ProfileManager) and there you go. Don't know if it will work on OS X though.

It's also possible to preload plugins, config settings, and extensions so that you don't have to set them up each time. Let me know if you'd like some pointers. This was a big part of my work at a previous job.

<comment><USER72> you can also set MOZ_NO_REMOTE on the command-line and you can start Firefox with another profile (I use that for dev, with a special dev profile)

</comment></comment></comment><comment><USER73> This is my wish list: (I'm running Firefox Beta)

\- Show ::before/::after pseudo elements in the DOM inspector.

\- An option to clear the web console on page reload.

\- An option to hide assets requests / show only ajax requests in the web console.

\- A "Storage" tab for viewing cookies, localStorage, applicationCache, etc.

\- Merge the Developer Toolbar with the DevTools.

Thanks!

<comment><AUTHOR> I agree with all of that (especially with 1, 2 and 5).

</comment></comment><comment><USER21> Webkit dev tools timeline in frame mode is bar none the most useful tool for tracking down performance issues. Looks like it's on your roadmap but it's far, far more useful in tracking down actual perf issues in large codebases than any other tool in any developer tools toolbox because it's cross-cutting and bottlenecks tend to be a combination of factors and the frame-sizing lets you find what's on the critical path when it's on the critical path. I use it 10 times for every one use of all other perf profiling tools (I consider network/pageload to be a different set of problems).

I don't see it on the roadmap but the firefox console is SO terrible at printing objects. In most apps I work on I'm shipping around 2kB+ JSON objects and the current console is absolutely worthless for these.

Related, but I think there's room for improvement in object printing in general. I find myself not really caring about most fields in an object but I'd like a couple fields printed inline before expansion. I like that the firebug console prints a few fields with the option to expand objects but would like to have control over which fields those are. FWIW, my preferred pretty printer is node's.

I find CSS errors/warnings to be absolutely useless in both the firefox dev tools and opera's. Pretty much any modern site is using vendor prefixes and the result is hundreds or thousands of errors which makes the console fall over.

Due to the above, I've been taking the approach of trying dev tools out again every time Aurora updates and then going back to using firebug and chromium after 15 minutes or so. I completely missed the jsterm addon despite following you on a couple channels. It looks reasonable so I'll be giving it a go today.

When you're doing your network cascade panel, please set it up to load HAR files. You can get HARs from a variety of sources but there isn't (yet) a convenient way to view them locally.

For the debugger, I don't know of an equivalent of webkit's source view cmd+o / cmd+shift+o, which are extremely useful. The cmd+p filtering is decent but most of the time I do actually know what file and function I'm looking for. I also use the reformat button and break on caught/uncaught exceptions on a regular basis. Actually, now that I think about it, I use every single function except for the editing functionality on the chromium sources panel at least once a week.

For the style editor, the side list of stylesheets isn't mousewheel scrollable on my machine (I'm on Aurora).

I find dock right to be the most useful attached view for chrome tools. Screens (and particularly laptop screens) are wider than they are tall and dock right takes advantage of that.

Edit: For a larger feature, I would very much like the ability to edit code when the browser hits an exception and then continue execution using the new code. I've only seen this in smalltalk demos so I assume it's difficult but being able to flip a variable to tweak an if statement when stepping through the debugger saves the effort of getting back into the correct state from pageload.

<comment><USER74> Agreed on the console not displaying objects well. I find that to be especially true with DOM nodes.

FF:

      >>> document.getElementsByTagName('div')
      (pocs:({}), pocs0:({}), pocs1:({}), pocs2:({}), cst:({}), mngb:({}), ... )

Firebug:

      >>> document.getElementsByTagName('div')
      HTMLCollection[div#pocs, div#pocs0, div#pocs1, div#pocs2, div#cst, div#mngb, ... ]

Chromium:

      >>> document.getElementsByTagName('div')
      [
…
,

…
,

…
,

Press Enter to search.
,

,

…
, ... ]

(edit: formatting)

</comment></comment><comment><USER30> I think something that would be useful as a dev tool in FF, which only chrome right now has a decent tool for is restful url testing, similar in part to [https://chrome.google.com/webstore/detail/advanced-rest- clie...](https://chrome.google.com/webstore/detail/advanced-rest- client/hgmloofddffdnphfgcellkdfbfbjeloo?hl=en-US) I haven't seen anything even remotely similar for FF, maybe a optional plugin for this kind of tool, it would make my development process much quicker for the client-side code which is being used for restful interfaces. especially if we can maintain our session when submitting information.

<comment><USER30> Better auto-complete for css fields for the css editor in the new FF, such that it's on par with the firebug auto-complete functionality in the dom/css inspecter

<comment><USER75> Auto-complete for css properties and easier value editing (up/down arrows) would definitely be a huge help. With that, I could see myself switching to FF for CSS development.

The responsive features in the web console - which imho HAS to be monosopace - are also definitely exciting, and make me want to switch to FF.

</comment></comment></comment><comment><USER76> What drove me away from Firefox to begin with was the crashing, memory usage, and (lack of) speed. Mostly the crashing -- I was willing to put up with the other stuff.

I'm a backend/systems developer. One thing that would be awesome for me would be a fully featured web debugging proxy ala Charles/Fiddler. This is where I spend most of my time debugging/testing.

I watched your video with the new webconsole (jsterm.v2). Looks pretty slick -- but I'd request code completion. It was hard to tell if you had it or not from the video.

Another comment in this thread mentions you are working on Firebug AND dev tools? Firebug functionality must be part of Firefox by default.

</comment><comment><USER77> An SSL MITM "proxy" a la Burp, but built into Firefox (or Firebug). It would be nice if it allowed re-writing (both manually and programmatically) requests and responses (including headers) on the fly, substituting files, etc.

</comment><comment><USER78> I'm glad you asked! This is a good time for me to bring up something I wrote two years ago:

<http://news.ycombinator.com/item?id=2024164>

I really wish browser makers would do this! Mozilla can lead the way.

I am going to post it here for ease of reference:

1) I propose a simple mechanism to guarantee that a resource located at a certain URL is always the same. Similar to how we have <https://> blabla, and the user agent warns us if the server's certificate is not trusted, we should have httpc:// blabla to indicate constant resources. Sites all over the world can download resources from httpc:// urls and store hashes to them in various formats, and your user agent can trust one or more of these authorities. When downloading, it would compare the hashes against the ones downloaded from these authorities, and if there is even a small deviation, it would give you a warning just like <https://>

This must be done by the user agent. Right now we do have "cache control" headers, but I am talking about the server making a promise to the world that a page is really truly static, and user agents having the ability to verify that. This is different from server-controlled caching.

I can see this being used in app stores for the web (curating apps and various versions of apps, like Apple does) and also for secure logins. I would like someone to make guarantees that my password is not being sent in the clear to the server that I am connected to. Right now, the web forces us to trust a remote server completely, when interacting with a website. For example, when I enter a password, I have no assurance that the server won't misuse it. (See <http://xkcd.com/792/>)

This simple change would make possible a variety of applications that we haven't even thought of, besides these two.

2) The second proposal is to have iframes that are on top of everything else in the containing window, no matter what. That would enable 3rd party logins (such as OAuth) do be done in the iframe, without worrying about clickjacking. The javascript inside the iframe should have a way of checking whether the iframe is of this type. At most one such iframe can be shown in any given window.

This would lead to much more pleasant interfaces, and once again, the user would receive the extra protection. Of course, this means that Flash and other plugins would have to play nice with this. We could implement this rather easily with a browser extension that causes a borderless window to appear (like Flash does) above the actual browser window.

Thoughts?

<comment><USER79> > 1) I propose a simple mechanism to guarantee that a resource located at a > certain URL is always the same (...)

You are reinventing ETags.

<comment><USER78> ETags do not have a built-in system to verify arbitrary hashes of the content from different authorities.

Actually both https and httpc rely on authorities and trust. It's an interesting proposal!

</comment></comment></comment><comment><USER80> It would be great if response bodies were easier to view. I have to enable logging and scroll to the bottom of the network request window to view them currently.

Also, thank you. The updated tools in FF20 beta have been fantastic.

</comment><comment><USER81> Make the native 'Inspector' tool go away. Accidentally opening that thing (because they're next to each other in the context menu and the labels are similar) instead of Firebug is infuriating.

<comment><AUTHOR> There's an option in Firebug to disable the inspector button.

</comment></comment><comment><USER82> I was just now debugging in 3D view and wishing the view would re-render when I changed a style attribute. That would be pretty slick and quite helpful. Thanks for all your hard work.

<comment><AUTHOR> Noted.

</comment></comment><comment><USER83> What about some "livereload" capabilities?

<http://livereload.com/>

I know a lot of people who use it. And I think it would be great to have it native on firefox.

</comment><comment><USER84> One things I recently tried in firebug, and which seemed unnecessary hard: I tried to get a list of all the event handlers that fired. Yes, you can go in the source view, and there on "trace events" or whatever it's called (why doesn't that work in the DOM view?), but when there's a page reload, tracing is off again.

And as soon as there's a handler for mouse movement, you see nothing else in the flood of onmouse* events.

(Maybe there's an elegant solution to this problem already, but I didn't find any).

</comment><comment><USER85> Maybe this is provided and I haven't found it yet: \- Rendering speed - <USER2> what slows it and what we can do to improve it. (Too many DOM objects, external files, redrawing?).

Thanks!

<comment><AUTHOR> We do have a profiler now (alpha stage in Firefox 21).

<comment><USER86> It would be nice to have a latency profiler that would dump stack traces (or break) when execution takes more than 0.1 seconds (or 0.01...) for both js and native/html and xul.

Also, realiable support for "break on throw exception".

</comment></comment></comment><comment><USER87> Move toward cloning MS Access from around 1997, but with open web technologies. And yes, I am very serious about this. We have needed this for a long time, and I don't think anyone but a browser vendor has the expertise to make it happen. Clearly you understand that the browser is an important development environment, so why not go whole hog and create something that can solve roughly 90% of developer's software needs?

</comment><comment><USER88> A menu somewhere to select the current media type would be lovely - not least for checking print stylesheets. Perhaps a drop-down at the top of responsive mode?

A nice ui for cookie management stuff (edit, delete) would be good too. Even better would be a way to manage different sets of cookies on the same site - eg per-tab cookies, or an option to save/clear/restore - to make it easier to test as different users at the same time.

</comment><comment><USER89> Long, long ago the "info" dialog box had a "Forms" section, kind of like the current "Media" section. It showed all the forms on the page along with all their fields & current values. I'd love to see that feature again. Then I could easy see the current values of my form fields (including hidden fields). Bonus points if I can use that dialog to edit the values and press a button to submit the form.

</comment><comment><USER90> This isn't in your purview, but it'd be really nice if Firefox text boxes on OS X acted like OS X text boxes. Whenever I try to switch to using Firefox instead of Chrome, this drives me crazy because all the ctrl, cmd, option + arrow key combos I use with every other Mac application for text manipulation don't work.

This realistically a low priority matter, but it's one that keeps on making me switch back to chrome.

</comment><comment><USER91> In terms of devtools, here is my feedback/proposals:

\- the scratchpad is great but not usable enough. I would go somewhat in the same direction as firebug when you have the js command line in multi-line mode. The problems I see with the scratchpad is that it's yet another window to open and drag around and executing the code and getting the result aren't very easy things to do (ctrl+enter would be great).

\- of course, a very popular request is a better integration between the devtools and the IDE, and I think the fact that the debugger can be remotely accessed is great cause it will help immensely in this topic, however, I was thinking that perhaps, one simple thing that could help would be a way to drive the web page UI elements from the devtools, with some kind of selenium- like script. The goal would be to easily reach a certain point of the app when repeatedly debugging/developing that particular part. Today, a webdev's workflow is mostly write in IDE -> F5 in browser -> click around -> debug/verify -> back to IDE -> etc .. So the goal would be to speed up the "click around" part, and I was thinking that firefox/devtools could expose something simple to easily script that part.

\- another thing I'd enjoy as a webdev is a way to mock/filter http requests and responses from the Net tab (currently being developed). Indeed, when working on a web app, there are chances that the server-side code won't be ready at the same time as the client-side code. Another use case is when debugging and trying to find a fix for a problem in a remote platform (in production for instance). The idea would be to let developers specify, for a given request, a static file on disk to respond with instead of actually going to the server to get the true response. This way you could inject a new version of a file for testing, or you could mock a server response to work on the javascript part before the server-side is ready.

Hope this helps.

</comment><comment><USER92> 1\. for debugging minified JS we tried to use source maps, but they were not supported (I have to say that Chrome claims to support it but it is working intermittently). So our fallback today is to serve non-minified to developers (based on a cookie) and minified to the rest of the world. The drawback is that users may report JS exceptions with the line numbers which are different from what developers would see.

2\. for mobile I need FF to let my webaps compete with native apps. Mozilla is changing the game on mobile with webapis to devices <https://wiki.mozilla.org/WebAPI>, you guys are the saviors! We have been waiting for the ability to write device interfacing webapps since 2008! Our team is on the way with an MVC framework that utilizes device webapis, see <http://github.com/urbien/urbini>. But one critical thing is missing - <USER3> needs to start as a service on device boot, and webapps should be able to register JS callbacks in this service. It does not need to include a rendering engine, but webapp should be able to spawn full browser. Without this we can't write proximity-based social apps, a bump-like app for business cards, network aware db sync engine, etc. To continue this line of thinking, it is not always devices that you need your webapp to communicate with. Sometimes it is Android intents. Like the intents defined by pebble watch service <http://developer.getpebble.com/> What would be cool is to have a generic interface to those intents in Javascript. I know it is Android-specific, and iOS will need another solution. The idea I want to throw on a table is to define any interactions with native code as Models in MVC. Our team is prototyping such for Pebble smart watch right now <http://urbien.com/app/Pebble>. I am available for brainstorming if you want to take it further.

</comment><comment><USER93> On Firebug, when you hover the layout section, the respective section of the selected HTML element is highlighted. I use _a lot_ this feature, it is very useful, and IMHO is a must-have for a webdev tool :-)

Another feature I would like to see is a 'Disable cache', and a 'Open source code in a new tab' (the things I use more of Web Developer Tools :-) )

</comment><comment><USER94> Some random suggestions:

(1) Developers do A LOT of style tweaks using the dev tools. In Chrome, this flow has gotten smoother and smoother. For example, the little of feature of having key handlers to jog numeric style properties is huge as it allows you to look at your page and not the value you are changing. Along these lines, here are some things that would go beyond what is currently offered.

\- Allow me to easily get a diff of the styles that I have changed. I tweak a lot of styles and then I painfully bounce back and forth between my editor trying to make sure I have everything updated. When I forget something, it's lost. (Another angle on this would be to keep a history of the styles that were tweaked so I can get that back after refresh).

\- You have the beginnings of an awesome z-index debugger with the 3d-view. Make it more interactive. I really want to see the page from the side with the z-index values somehow visible. Debugging z-index issues are a royal pain in the ass and you have a great opportunity to be awesome here.

(2) Your network level debugging needs a lot of work to even reach par with WebKit browsers. There is a great opportunity here as well. Even with the features that Chrome offers, I still resort to a debugging proxy for many tasks. Specifically, I use Charles for throttling to test timing on slow networks, replace network resources with a copy on disk (for in the field debugging), visibility into compression and a lot of cache related issues. In fact, tooling that gives visibility into caching behavior would be great. Another area lacking for browsers these days is debugging WebSocket traffic. Chrome's WebSocket visibility doesn't give me the real time visibility I need for message-style traffic.

(3) Performance visibility. I worked on the performance related tools in Chrome for a while. In fact, I landed the instrumentation that gave developers visibility into reflow/layout. I want visibility into what is going on in the browser: Reflow, compositing, parsing, HTML tokenization, image decoding, message passing queues. I want to be able to see it all.

(4) Expand Scratchpad. I basically want to be able to write a user script without ever having to install anything or open a file. Let me open the scratch pad, write some code and check "run this when example.com/ loads". I have a lot of debugging-in-the-field issues where I end up jumping through hoops to get some custom script to run at startup.

Ok, that's a quick 4 off the top of my head. Hope this helps.

<comment><USER37> An additional point on (2). One thing Firebug does right that neither chrome nor the built in tools does is show a decoded version of the JSON for both the send and receive sides of a connection. I love being able to click the request in the console and drill down into the JSON tree.

If you're dead set on replacing firebug with the built in tools, they need this feature!

</comment></comment><comment><USER95> I'd love vi keybindings to navigate the console and web inspector.

<comment><AUTHOR> Oh man… I'll try to sneak that into Firefox' source code ;)

\-- A Vim user

<comment><USER75> <http://bukk.it/beemodance.gif>

</comment></comment></comment><comment><USER96> Hi Paul,

I am not a FireFox dev tools user and I highly invested in Chrome devtools. I edit JavaScript code in browser all day. It's hard to not use a fully featured editor but I invested in it to make it better. I submit bugs and sometimes fix small bugs there too.

I will tell you what Chrome dev tools CANT do for HTML and CSS and ask you to implement them to attract more developers.

1\. Editing JavaScript code in browser: \- Autocompletion (I know this is very hard) \- Code block collapsing \- A good theme API \- Shortcut keys like CMD+/ for comments \- Inline watchers for when developer stopped at breakpoint and look at watched value right next to it's position in code (Something like Visual Studio) 2\. Editing CSS \- Inline CSS reloading (Reloading CSS without refreshing) \- Better autocomplete for values \- Unminifying CSS 3\. Multitouch

</comment><comment><USER97> Hi Paul, I think some sort of explicit URL protocol would be nice for short- circuiting DNS without having to add entries to your hosts file and restart; something like:

httpe://firstname.lastname@example.com/index.html

would connect to 184.108.40.206 and ask for domain.com, without querying DNS either locally or otherwise. I'd find it useful.

</comment><comment><USER98> Firefox is my primary browser, but I use Chrome to do development, entirely because of the dev tools. I'd really like to move my development back to Firefox.

For me, I'm held back more by the UI rather than the features. I find the different, independent panels very confusing, and the popups (for eg. XHR request info) drive me nuts. I'm sure there's a strong rationale for how it is, but it doesn't quite click for me.

I've tried going back to Firebug where the UI is more my style, but for me, it's too slow (on my not new, but not old laptop). It often takes several seconds to launch the select element tool, and can lock up for a couple of seconds at a time.

The built-in tools are much faster, which is great. I'm just not accustomed to the UI, and have reservations about whether I can get into it or not.

</comment><comment><USER99> This is more of a plugin request but I'd love to see something like Postman for Firefox: [https://chrome.google.com/webstore/detail/postman-rest- clien...](https://chrome.google.com/webstore/detail/postman-rest- client/fdmmgilgnpjigdojojpjoooidkmcomcm?hl=en)

</comment><comment><USER100> I would love to an allocation profiler that reports garbage. .Net has the CLRProfiler which tracks allocations over time and can show where you are creating a lot of temporary allocations. CLRProfiler is a great tool and I haven't found anything like it in the web world yet.

</comment><comment><USER101> I would like to see the adoption, if not formally at least informally, of a javascript ux toolkit. This toolkit would work across platforms - mobile, web, desktop. Ideally it would be modeled on qt. Maybe using dojo/Maqetta if this is possible or makes sense or Qooxdoo.

ZUL offered much promise but was never really developed imho. And now there are too many js toolkits out there -- too much choice! I can understand not wanting to favor one toolkit over another, but I think there is nothing wrong with informally adopting one -- and consolidation will happen eventually anyways. Web components may be a way forward here, but I would think Mozilla, with its emphasis on standards, could be a leader in uniting these elements.

</comment><comment><USER102> Would love to see integrated ftp/sftp client and in-browser tabbed editing for quick site edits.

</comment><comment><USER58> \- To be able to "View Source" with an external editor, without having to use an extension that sometimes breaks from releases to releases, would be really nice.

\- Being able to open a new tab that doesn't share the same sessions/cookies than the other tabs would be nice too!

</comment><comment><USER103> A RESTful stub,

so I can run my ajaxy goodness without needing a web server up. More importantly, have it run from standard definitions like jsonschema and URL mappings. Make the static version easy peasy config, and then let me extend the stub with JavaScript as it gets more complex.

Front end dev is splitting from backend dev - and there is a world of people who would kill for an industry wide means to define easily the expected behaviour of rest API / media types and so be confident that when the outsourced devs returned their work integration would not be a bightmare - expect your stub to be part of many SLAs

There are frameworks out there that do this (Jasmine) but if I wanted something, that's it

Edit: was even less clear than it is now

</comment><comment><USER104> View event bindings. I'm often debugging pages I've never seen before and the only way I've found to know what's bound to what is to grep the js for live/bind/click/etc. or replace the event library (usually jQuery) with one where I've inserted logging into the lowest-level event binding functionality. This sucks a lot.

Show me HTML source over time. If I use curl/Tamper Data I see what the server actually sent, if use View Source I see the source after JS has run, if I use Firebug I see the current DOM. I care about all of these. Give me one place to click through them with diffs. Include steps for the JS changes, and a copy of the JS stack at each change so I can see who did it.

</comment><comment><USER105> I'm not being pedantic.

Implement the same toolset, layout(UI), and keyboard shortcuts as Chrome/Safari __. The underlying code would obviously be different, but as a developer one of my biggest problems with Firefox is having to do a mental context switch every time I have to debug something. Things that bother me is the dev tools defaulting to the top instead of bottom and having to click little buttons instead of fat tabs to choose what shows up in the console. Make each its own tab.

On the good side, the FF dev tools are a lot faster than Firebug was. That's much appreciated.

 __Chrome and Safari should do this as well. My point is that they are more similar to each other than Firefox is.

</comment><comment><USER106> When I go in a tweak the CSS of various html elements, it would be nice to have those changes available somewhere (even if I reload). Even the ability to replay those tweaks after reloading.

I need this to be able to move that css back to my external files.

<comment><AUTHOR> Indeed. Not the first it's asked.

</comment></comment><comment><USER107> Firstly, I love the new Devtools. I use Firefox as my main development browser because of it.

First, I would like to request if the rules tab on inspector pane didn't change user value or unit. We can save that for the computed value tab. For example I would like to inspect the hex color and not rgb.

Second, I miss Firebug's colored overlay of padding, margin and border on inspect mode. Chrome inspect didn't have it either.

Third, is the performance measurement pane, like in Chrome.

Lastly, maybe an additional pane to edit/manipulate request header. Right now, I had to enable it every time I need to inspect the request header, and it couldn't be manipulated.

</comment><comment><USER108> Would like to see something that help inspect events bound to DOM elements. i remember there was a script/plugin called liveevent but that has been plagued with issues of late and kinda stopped working for me.

</comment><comment><USER109> After having to hunt in google chrome dev tools for memory leaks from a single page JavaScript app, memory dumps with a separate tool that can give you a really good insight into what hanging around would be great. I found that if you were doing snapshots of website states and the memory footprint was significant then the browser just wasnt able to handle displaying all of them at once. I know this is an issue kinda for chrome, but I figure Firefox might have a similar problem. And single page/MVC javascript apps are only going to get more demanding.

</comment><comment><USER110> This comment may get lost... I have a lot of the same problems as others on this list. I love FF but use Chrome for developing, it is so much nicer. I don't get a lot of FireBug or whatever it is called. I use the DOM Inspector a lot (with the right click -> inspect this menu)

But what I'd like is to be able to mark a set of CSS rules and see if they are ever run. Put a breakpoint on them. Then browse around my website and see which are used and if any are superfluous. When taking over another website from another team, de-crufting the CSS is a pain.

</comment><comment><USER111> It would be nice to record a session and see what CSS rules that were applied. This should include events such as :hover. As an added bonus it could return a clean version of a stylesheet that matches.

<comment><USER38> Oh, I really like that suggestion!

</comment></comment><comment><USER112> Right now, Web Developer Toolbar lets me live edit HTML in the browser. I'd like the same feature, but instead of editing in the browser, I want to edit the actual html file. So, this would be some sort of "live edit mode" where open a url to your local html file, and any edits you make to the file get applied in realtime (just like the Web Developer feature). It would be nice to use my regular editor (and the true html source file) instead of a browser text field.

I suppose support for CSS could work as well.

</comment><comment><USER71> > improve the user interface (better theme)

Oh no.

No offense, but every time Firefox gets on an improvement kick, especially when it comes to interfaces, it seems to just be a euphemism for "removing functionality".

</comment><comment><USER113> I spend a lot of time needing to step through/understand someone else's pages/script, and would really like to see a way to immediately link between the HTML on* attributes and the functions that are invoked. I can at least get the function names through the DOM tree sub-tab, but I end up doing global finds to actually get the function being called - especially when someone has overloaded myFunc() with N different parameter options.

Maybe there's a different way to do it, but I haven't found it yet.

<comment><USER110> chrome lets you see what events are attached to DOM elements. It also lets you add breakpoints to the JS in an onclick="dothis()" so you can just step into it.

</comment></comment><comment><USER114> The two things that I'd want to see are a Network tab and a better way to edit the HTML. Adding to the HTML is a must-have in my opinion, not just editing what's already there.

<comment><AUTHOR> Network tab is our next tool.

And a lot of people have asked for a better edition mechanism in the HTML panel. So I hope we can fix that soon.

</comment></comment><comment><USER115> Please build a remote inspection / debugging API similar to Chrome so tools like <http://brackets.io> can integrate with Firefox.

</comment><comment><USER116> One thing that I think would really improve the lives of all firefox users is if firefox would update silently like chrome does. Firefox always chooses the times when I want to get something done to do the updates and so I always cancel the update (in order to do what I want). In chrome, updates happen without me noticing them which is ideal. (this also has the added benefit to devs that older versions of firefox will fall out faster and thus require less support)

</comment><comment><USER117> [Inspector] Support more pseudo selectors where applicable. E.g. :link and :visited for links, :target, :enabled, :disabled, :checked, :indeterminate etc.

[Web Console] Add an option to reset when the page reloads (like Chrome). Perhaps it doesn't even have to be an option, but could be the only way.

[Editing HTML/CSS/JS] I don't have a clear idea, but I _don't_ want to edit code in the browser (my editor is my tool of choice), and would love if I didn't have to refresh to update a resource.

</comment><comment><USER118> * Expose APIs for developer to hook into firefox and reload pages or parts of pages (i.e. reload changed JS/CSS file)

* Intuitive system for playing, changing, rewinding, and replaying JS files for more rapid feedback (see: <https://vimeo.com/36579366>)

* Let me alter CSS / JS live (like I can with firebug) and then save it to the file if its local

* Implement some sort of system that shows link between JS events and the HTML they are bound to

</comment><comment><USER119> Honestly I would like to see firefox become more like google chrome in the fact that theres less of the browser and more of the page that takes up the screen for normal browsing. Firefox would be a lot nicer actually if you guys would keep the dev tools but they don't really need their own key command to get to them as you will not really need them on each and every page you visit and a basic user may get lost if they open it by accident.

</comment><comment><USER120> I'm a bit late in commenting here, but would love Firefox to do one thing with script debugging. A lot of scripts are written unindented, without spaces, and may be obfuscated to save size and for other obvious reasons. But that makes script debugging very difficult in the browser. A feature to properly indent them, and possibly unobfuscate them 'live' in the debugger will be great ! Not sure how difficult would that be ...

</comment><comment><USER121> First of all thank you for taking the time to do this and for your work. The tools have made some great progress in the recent builds.

I'm currently on FF 22.0a1 and I can't find the ability to dock the tools to the left/right. I know I used to be able to. Whether that option is present or not, I think that it is part of a bigger issue, customization. I would love to have the ability to customize the hell out of this, either from a gui or code

</comment><comment><USER122> Tainted mode for Javascript and tools for identifying DOM XSS (similar to DOMinator) would be really useful for security testing and audits of the modern complex sites. There is a bug open <https://bugzilla.mozilla.org/show_bug.cgi?id=811877> \- hopefully it can be given sufficiently high attention and priority!

</comment><comment><USER123> Small but irritating issue: The clicking and editing mechanics of Firefox's CSS 'Rules' sidebar is just-a-bit too sticky. It'd be nice to be able to use the arrow keys to move around different fields instead of just TAB and SHIFT + TAB.

The left - right keys should obviously only jump fields once the cursor is at the edge of the current field. Kinda like Microsoft Excel cells, if you know what I mean.

</comment><comment><USER124> I'd start with something simple. Edit a file, server detects the change, browser refreshes the page. Just that would save a ton of man-hours.

</comment><comment><USER125> Two things I would like:

1) An easy way to debug events. I find that javascript has become so non- linear it is really hard to decide where to breakpoints and what I really want is to follow an event from object to object instead.

2) An easy way to send, receive, debug RESTful Ajax queries: GET, PUT, POST, DELETE would be nice especially if it had a clever way to view and edit the requests (and responses).

<comment><USER126> Number 1:

I would love a tool that would let me set a breakpoint on an element and then show me a stack trace any time that element is modified. This would make locating a broken piece of JS in an unfamiliar code base so much easier.

</comment></comment><comment><USER127> I'd like to be able to debug webworkers in their own environment (though I would accept the Chrome workaround of debugging in an iframe).

</comment><comment><USER75> FF's web console has some nice resizing features to test responsiveness. They keep me coming back and trying aurora once in a while but the CSS property / value editor is currently lacking.

Either keyboard shortcut mappings for web console commands, or a simultaneous view of different responsive sizes would definitely be killer for responsive development.

</comment><comment><USER128> For so long I've been wanting a system I can ask -

Why is this element "HERE" - instead of "THERE" where "HERE" might be 60 pixels to the left, or off the screen + "THERE" is somewhere else.

Basically a system that would be able to interegate the DOM, work out which rules might be causing the problem or have a go at some modifications.

It could answer:

"blah.css resets clear on line 266" - <USER4>

</comment><comment><USER129> +1 for "design in the browser" capabilities.

But, a more easier (I guess) but similar feature I would like is, full color picker for color values, and a gradient generator with color stops etc. which can be invoked for all gradient background supported elements, both color and gradient should update the rendering as the values are changed.

</comment><comment><USER130> This is a big request and probably outside the scope you are thinking (but it shouldn't be): a WYSIWYG layout and editing mode.

Think something like [divshot](<http://www.divshot.com>) but more powerful, and built right into the browser.

Authoring web content should be a lot easier than it currently is.

</comment><comment><USER131> Better unit testing support please. Currently marrionette js support is minimal, selenium/webdriver is too heavy weight. I realize that there is a lot of legacy mochitest code. Having an easily accessible framework that one can integrate with nodejs to do BDD/TDD is extremely useful for writing guality code.

</comment><comment><USER14> Personally I find it annoying that <tag> is displayed as <tag >. I never understood why this is.

<comment><USER75> This creates separate click areas for "change the name of this tag" vs "add an attribute". I find myself adding classes and attributes often, so I'm a proponent of <tag >.

Chrome's tools only show <tag>, and the only way to add a class requires two clicks on "tag", and then a click on ">", which is really wonky.

<comment><USER14> I thought this might be why. Fair enough, not a bad feature.

</comment></comment></comment><comment><USER132> I understand this is probably not be the kind of feedback your team is looking for, but I haven't used Firefox for front end development since I got a Retina Macbook because I can't stand reading text anywhere in Firefox.

Before the Retina I used Firefox/Firebug all day everyday. After Retina, I jumped to Chrome.

<comment><AUTHOR> retina support has been added to Firefox 19 (or maybe 20, not sure).

<comment><USER133> Released in Firefox 18. Release is currently Firefox 19. Release notes for 18: <http://www.mozilla.org/en-US/firefox/18.0/releasenotes/>

</comment></comment></comment><comment><USER134> Something similar, if not identical, to Chrome's Speed Tracer. I spend most my time in JavaScript heavy apps, and being able to see a visual break down of where my performance goes, _and the particulars behind it_ (e.g. especially involuntary repaints), has been very helpful.

</comment><comment><USER135> I'd like to see a way to compare the CSS values on two different elements, like two buttons that should look the same, but aren't. I do a lot of manually flipping between the two elements, and trying to spot the differences in the property list. But it's pretty clumsy that way. :)

</comment><comment><USER85> This is probably too late...

Right clicking an element, you have "Copy CSS Path". I want the same thing for JS. Something where copy/paste gives me "getElementById()" for the element or some other way to uniquely identify that element in JS. I can then easily paste it into the Console and get to work.

Cheers!

</comment><comment><USER136> Simplify the Firefox API's. The J2EE-like APIs in Firefox are complicated and a big turn off. Make debugging background pages easier. Make logging easier. We've built several extensions on Chrome, Firefox and IE. NOBODY volunteers to do Firefox or IE tasks. Chrome is fun.

</comment><comment><USER137> I find that firebug slows down the browser after a while of debugging. Memory leak? Make it faster :)

</comment><comment><USER138> Web Worker debugging that's on par with debugging code in the document. That includes logging, breakpoints, and being able to see the scripts loaded in a Worker without having to open its debug tab first.

(I'm reacting to Chrome's current situation, but it applies across the board.)

</comment><comment><USER139> A thing I never understood is why writing into the console a function should show the complete body content.

The only one who do it "right" in my head is firebug: console.log(my_function) show just the function "definition", clickable to go directly in the sources at the right row.

</comment><comment><USER140> Hello. I think first and foremost FireFox should build in support for disabilities, so that one can get to its UI Elements. The nice side-effect is that governments, which has laws regulating software for the benefit of disabled workers, then are able to use it.

</comment><comment><USER141> Integrated js/coffeescript editor for live-editing the code without page reload. Must be able to save to disk as well.

Inspiration: <http://smotko.si/using-chrome-as-a-javascript-editor/>

</comment><comment><USER142> What I would love to see are improved privacy options. Whenever I come across <https://panopticlick.eff.org> it serves as a reminder that there could be much more done to reduce the footprint.

</comment><comment><USER143> Better management of data would be a big thing for me. Being able to edit cookies locally, and tamper with POST/GET data that I'm sending to pages. Also LocalStorage although that's not something I personally use.

Chrome has the same issue. It's all read-only.

</comment><comment><USER144> My suggestion is to take a look at this plugin and make everything about it better and faster: <http://chrispederick.com/work/web-developer/>

I use this thing several hours per day.

</comment><comment><USER145> One feature I love is, When I right click on the tab it should give an option to stop the music or video I am playing. May be you should provide hooks for the web page developer to integrate their music/video player to your menu items.

</comment><comment> vanessa-dc Keep "view selection source" !!

</comment><comment><USER146> Get rid of the current native debug tool - and replace it Firebug (or have the option to switch between the two).

There is nothing more annoying than trying to inspect something via Firebug, and you end up accidentally open the native debug tool instead.

/rant

</comment><comment><USER147> At some point, I've noticed that stack traces just stop altogether. This happens when I work with Three.js. I think libraries are gonna grow bigger and more complex, and so having the browser tools match that would be great.

</comment><comment><USER148> Create a debug view that displays all attached event listeners for each dom element, with a link to the source location for each. I hate unobtrusive javascript only because we have traded easy debugging for _pretty_.

</comment><comment><USER149> Just thinking that debugging a huge DOM is a waste of time after each refresh. If there's a way to visually select/click elements on screen to directly zoom in onto the part of the DOM tree, that will be kickass.

<comment><USER110> There are plenty of ways of doing this. I have the DOM Inspector installed, then you can either ctrl+shift+I to launch it and then click on the Mouse Icon to start selecting items on the page and see them in the DOM Tree. Or I also have the right click -> inspect plugin. Now you can just right click on the page then "inspect element"

</comment></comment><comment><USER150> Tab group: one process per group. Kill one group kill all the tabs within the group. Make most extensions per group instead of browser wide to improve isolation and security.

It's a natural evolution from one process per tab.

</comment><comment><USER151> One thing I'd love to see baked in is the "fireshot" plugin. Basically a way to take a screenshot and annotate it. Very useful when mocking up with the client / working through support requests etc.

</comment><comment><USER152> I'm glad you added the last sentence, because at the end of the day, web- browsers are primarily an end-user application. IMHO dev tools should _all_ be add-ons or in a developer-specific build.

</comment><comment><USER153> Chrome has a button that gives format to minified code. It's useful.

</comment><comment><USER154> It would be helpful if I didn't have to close and restart my browser to install an addon. It would be easier to only have to restart the tab I want the addon to start working on.

<comment><AUTHOR> (that's unrelated. We support restartless extensions. And that depends on the extension. Some do support that, some don't).

</comment></comment><comment><USER155> Maybe I'm not using Firebug correctly but my stack traces only include the last few function calls. It'd be nice to have comprehensive stack traces from beginning to end.

</comment><comment><USER156> Inline editing of Stylus and CoffeeScript when using the inspector. That's about the only thing that could get me to switch from Chrome.

Also, please finish implementing the gamepad api!

</comment><comment><USER56> Also, I can't remember exactly what the issue was, but I remember not being able to access or do something with local files. Anyone know what I'm talking about?

</comment><comment><USER157> fix issue 201011 (<https://bugzilla.mozilla.org/show_bug.cgi?id=201011>)

Some years ago I really wanted to change some firefox keybindings but found to my dismay that they were broken. I then used the keyconfig extension which worked really well until a firefox upgrade broke it - haven't tried it again. Surely something like this should be in firefox core...

</comment><comment><USER158> I'm really missing Firebug's DOM tab (being able to see all JavaScript functions and properties). Also the ability to see which event are being fired.

</comment><comment><USER159> edit:

Sorry I didn't read the link you included.

You've made what I've just requested. Thank you so much!

\</comment><comment>---

I know you guys have a lot of built in tools for web development.

But they're (the web dev tools) are all separated. It's nice and I like it. But is there a single shortcut or something where I can click and have it all organize in one giant tool? Like Firebug?

Btw, I loooove mozilla (borderline fanboy) and aurora is awesome, thank you for an awesome product.

</comment><comment><USER160> Make it possible to run DevTools in "editor mode" ie. make it possible to run DevTools in a separate tab as an editor.

</comment><comment><USER161> Dev tools provided by webkit is really cool. Why not get some thing similar. At least a debugger and a good console.

</comment><comment><USER162> Ability to move tabs to the sidebar - left or right is needed badly(at least, I need it badly).

</comment><comment><USER163> A 'nice-to-have' security feature: when parsing the PDF, show the embedded JavaScript code.

</comment><comment><USER164> Not related to devtools but please make the facebook addon or plugin or whatever removable

</comment><comment><USER165> Look at phantom.js -- make it happen that Firefox integrates easily with the framework.

</comment><comment><USER166> I think a macro recording tool would be very useful (maybe something like Selenium).

</comment><comment><USER167> I tried searching, but I couldn't find a single thing about accessibility on this page.

As someone who does not rely on accessibility tools, I have a lot of problems writing and debugging accessibility-compatible services, though I do try. I have a blog and a project that I am trying to make aide the experience for people with accessibility tools, but I still have no idea how it "renders" on their end. Nor do I know if I make a typo or write something that would not get validated by a test suite.

Here are some of the measures I include that Firefox does not appear to assist with:

        1. rel="next" and rel="prev"

It is actually incredibly sad that only Opera supports this—from what I can tell. Even Google seems to screw up the "next" and "prev" articles in search results for my blog.

On a personal note, being able to browse through a catalogue of blog posts, forum posts, etc. with just my Space bar, as Opera allows you, is amazing and something I am surprised others haven't copied.

If you want to try it, you can check out my blog linked in my profile on Opera; you can use it either from the pages with several posts displayed or on individual permapages. This kind of navigation creates an entirely new experience, and in some cases it also defeats a lot of tedium, such as when I am reading through fifty pages of forum posts—especially if it is a high- activity thread for, say, a live event where I have to keep up with new posts.

        2. WAI-ARIA

In other words, the `role` attribute.

        3. .link-skip

How, if at all, does my HTML/CSS actually work on accessibility software? Maybe my implementation is a completely rotten experience, but I wouldn't know.

        4. Testing for colours

Be it colour-blind people or people with poor vision. One functionality could be contrast inspection where a font `color` is compared to the colour of its background. Since you already have the requisite tools for modelling element- layering, this should be fairly trivial to automate as a test.

Another functionality could flip the colour scheme to show what the site would look like with different types of colour-blindness.

There is much more to be done in accessibility, but I don't really feel anything has changed in web-base accessibility in the last five or maybe ten years. I guess I wouldn't know, because the tools available aren't that great at the moment.

        5. Noscript testing

+++++

I really love the continuous integration that Travis CI provides (when I can get it to work, which isn't right now). I would love to be able to automate this process to the extent possible.

Perhaps I could provide some kind of testing recipe that is either automated or provides the tools I need for a certain task—and _only_ those tools—so I have, say, an accessibility-specific testing environment.

</comment><comment><USER168> +1 for remotable debugging. I love this feature in Chrome.

</comment><comment><USER169> A close/dismiss button on the responsive design mode ...

</comment><comment><USER170> JS and CSS minifier that (optionally) removes dead code.

</comment><comment><USER171> Firebug: Make testing hover and active classes easier.

</comment><comment><USER172> obstrusive http and -browsing mode. basically show http and head data (in a useful way) while browsing.

</comment><comment><USER173> Add some git plugins ,if possible ...

</comment><comment><USER174> I want an IDE for Javascript.

</comment><comment><USER175> Webkit

</comment><comment><USER176> Thanks for asking.

Here are some ideas associated with their pain points in no particular order.

1) I'd like to environment to feel more "dev" when I'm in the debug tools. Ctrl-L should clear the console, C-a should get to the beginning, etc. Ideally, there should be standard console mode (Vim-like, Emacs-like) so programmers can feel more at home while in the firefox console. There should also be a way, maybe a json file a-la sublime, to tweak the debugging tools. That way, I could tweak the appearance, tweak the hotkeys, tweak which tabs are visible, etc.

2) I'd like to have plugins that integrate better with the "main" firefox tool. For instance, a plugin could create a new tab in the firefox dev console or add features on top of what's already there. I.e. A "surround" vim plugin or whatever. That way, existing IDE and other dev tools could integrate with firefox which would make it so much more powerful.

2) I'd like to always have the console at the tip of my hand, so it can load "very" fast and be non-intrusive. An idea would be to bind it to the ~ key which would popup a transparent console _on top_ of the web page. For instance, I'd type:

      ~$('.whatever')

which would evaluate this and return the result in a tool-tip. It annoys me to death to write things like

console.log($('.whatever')).. It should be easier to evaluate things as we write them.

i.e.

      ~$('.whatever')<key to evaluate>.click<key to evaluate (ok good there's the click function)(function() { return 'meh'; }
      <Actual click on the .whatever link show 'meh'>
      ~$('.whatever')<key to evaluate>.click<key to evaluate (ok good there's the click function)(function() { return $('.submit-button')<key to evaluate>  } etc, etc.

A little bit like a scheme repl.

And I stress the transparent console because it's so annoying to have a big white console take a large portion of the screen even if most of the time you don't have to look at it. Yes, you look at what you're typing, but everything that happened before isn't that much relevant. And if you need it, you can still "pop" it for real.

3\. Firefox needs to be lighter and faster. Maybe on your machine it's fast, but on mine, it's so slow compared to chrome. The main reason I'm not using Firefox for my debugging needs is because I don't use Firefox for normal browsing. It's not just about the page loading.. it's also about the ram footprints and the time it starts. The best analogy I have to explain this is "Presently, Chrome is to Firefox what Firefox was to Explorer in term of speed".

4\. Firefox needs to be prettier. Again, maybe on your machine with I-don't-know-what-you-have-installed Firefox looks nice, but on my Archlinux distribution, it looks awful. Here are two snapshots from Chromium and Firefox (Firefox really looks like netscape 10 years ago)

<http://s4.postimage.org/e5zmk1m1n/firefox_netscape.png> <http://s10.postimage.org/4o2te27x5/chromium.png>

<comment><USER74> I'd also like to see more readline-like behavior. It's hard to stop entering C-p and C-n to explore the command history, which currently bring up a print dialog/new window.

Currently I hack some limited readline functionality with Pentadactyl, which is probably appropriate given the potential invasiveness of that change. But if we're talking about dream FF dev features-- there you go.

</comment></comment><comment><USER177> Webkit?

</comment><comment><USER178> Copy Chrome?

<comment><USER159> Hell no. They over optimize and it's horrible developing in it because those bugs are so rare and so hard it's annoying.

We had a feature to upload pictures and the img file have to have a certain format. If we upload the img to replace the current one, chrome cache the old image. It's annoying as hell.

</comment></comment><comment><USER179> Make it _exactly like the webkit dev tools_?

<comment><USER114> Safar and Chrome's dev tools are not the same.</comment></comment>