
Ask HN: Webdevs, designers: what devtools should we (Mozilla) build in Firefox? - paulrouget
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.<p>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/).<p>We are now working on defining what should be our next moves, and I'm trying to gather as much feedback as possible.<p>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/).<p>But we really want to get as much feedback as possible to make sure we're going into the right direction.<p>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?<p>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.
======
mbell
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.

~~~
pixelcort
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.

~~~
timdorr
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.

~~~
pedalpete
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.

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

~~~
paulrouget
> 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 :)

~~~
OmarIsmail
> 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.

~~~
robin_reala
Firebug isn't in house, it just has contributions from Mozilla employees.

~~~
chr1
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.

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

~~~
mehrzad
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.

~~~
lelandbatey
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.

------
sisk
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?

~~~
theallan
> 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...

~~~
sangnoir
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?

~~~
theallan
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>

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

~~~
paulrouget
We do have plans/patches for that.

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

~~~
paulrouget
That's interesting. I'll look at that. Thanks.

~~~
grayrest
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.

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

~~~
bmuon
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/)

~~~
JohnBooty
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.

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

~~~
JohnBooty
"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?

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

~~~
bmuon
1\. Yes, this. 2\. Try the Aurora channel. Now the developer tools look pretty
much like Firebug 3\. Yes!

------
yesimahuman
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!

~~~
paulrouget
All you said has been implemented in Firefox Aurora.

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

~~~
vinhboy
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.

~~~
Jemaclus
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.

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

~~~
krob
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.

------
soapdog
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!

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

~~~
potch
If you viewed the above screenshot, you would see that in fact the current
Firefox developer tools do the same thing.

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

~~~
paulrouget
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)

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

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

~~~
paulrouget
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)

------
olivierbeaulieu
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!

~~~
paulrouget
We have the inner architecture for "chrome" debugging (extensions debugging).
This sill needs some more work though.

~~~
olivierbeaulieu
Can we expect improvements to this in the near feature? It would definitely
make the idea of making firefox addons more inviting.

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

~~~
craigching
>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!

~~~
nathanstitt
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.

------
rebugger
Prettyprinting/unobfuscating the JavaScript sourcecode (like in chrome and
opera) would be nice.

~~~
paulrouget
Sourcemap support + unminification are coming.

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

~~~
paulrouget
We are already working on that (we call the "variable view"). It won't be a
window anymore.

~~~
TrisMcC
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!

------
mweibel
Websockets inspection would be very nice. To my knowledge no browser does
support this and it would be very handy IMHO.

~~~
switz
Chrome does: <http://i.imgur.com/KLmkYjH.png>

~~~
iso-8859-1
Your DPI is insane! What are you using?

~~~
Audiophilip
Maybe a MacBook Pro with Retina Display?

------
makepanic
I really love what you're doing with the developer tools in Aurora. But I'm
missing a network tab.

~~~
paulrouget
Thank you :) Network tab is our next tool.

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

~~~
paulrouget
I get the idea :) Thanks.

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

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

~~~
daleharvey
+1 this request, I deal in failing CORS a lot and still always get caught out
by this

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

~~~
jakub_g
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.

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

~~~
esrauch
I would recommend running jslint or jshint locally on your machine instead of
pasting it into the website.

------
moofish
Support V8's debugger protocol so we can use the WebKit Inspector.

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

~~~
bzbarsky
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.

~~~
Benferhat
Sadly, it's the only clue I have as to why my form's submit button isn't
working.

~~~
bzbarsky
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.

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

------
blissdev
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!

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

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

------
monteslu
Need to be able to profile frames/second for HTML5 gaming. The frames part of
the timeline tab in Chrome is extremely useful.

~~~
JohnBooty
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?

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

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

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

~~~
gcp
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.

~~~
paulrouget
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.

~~~
gcp
But does "work on" mean "maintain so it doesn't break" or "actively improve"?

~~~
campd
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>

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

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

~~~
paulrouget
There's an API for that.

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

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

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

~~~
vsync
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.

~~~
Gmo
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)

------
Thibaut
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!

~~~
paulrouget
I agree with all of that (especially with 1, 2 and 5).

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

~~~
ptgloden
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')
      [<div id=​"pocs" style=​"display:​ none;​ position:​ absolute;​">​…​</div>​, 
      <div id=​"pocs0">​…​</div>​, 
      <div id=​"pocs1">​…​</div>​, 
      <div id=​"pocs2">​Press Enter to search.​</div>​,
      <div id=​"cst" style=​"display:​none">​</div>​, 
      <div id=​"mngb">​…​</div>, ... ]
    
    

(edit: formatting)

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

~~~
krob
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

~~~
tholex
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.

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

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

------
EGreg
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?

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

You are reinventing ETags.

~~~
EGreg
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!

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

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

~~~
paulrouget
There's an option in Firebug to disable the inspector button.

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

~~~
paulrouget
Noted.

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

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

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

Thanks!

~~~
paulrouget
We do have a profiler now (alpha stage in Firefox 21).

~~~
silon3
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".

------
javajosh
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?

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

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

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

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

------
datadiver
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 - Firefox
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.

------
izietto
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 :-) )

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

~~~
nathanstitt
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!

------
goldfeld
I'd love vi keybindings to navigate the console and web inspector.

~~~
paulrouget
Oh man… I'll try to sneak that into Firefox' source code ;)

\-- A Vim user

~~~
tholex
<http://bukk.it/beemodance.gif>

------
msoad
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

------
janitor61
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://1.2.3.4@www.domain.com/index.html

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

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

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

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

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

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

------
electrotype
\- 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!

------
lifeisstillgood
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

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

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

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

~~~
paulrouget
Indeed. Not the first it's asked.

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

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

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

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

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

~~~
craigching
Oh, I really like that suggestion!

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

------
vsync
> 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".

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

~~~
monk_e_boy
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.

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

~~~
paulrouget
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.

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

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

------
Skalman
[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.

------
jbackus
* 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

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

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

------
alme1304
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

------
dmitris
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!

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

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

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

~~~
sets13
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.

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

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

------
stuaxo
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" - toggle

------
sathishmanohar
+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.

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

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

------
mehrzad
Personally I find it annoying that <tag> is displayed as <tag >. I never
understood why this is.

~~~
tholex
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.

~~~
mehrzad
I thought this might be why. Fair enough, not a bad feature.

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

~~~
paulrouget
retina support has been added to Firefox 19 (or maybe 20, not sure).

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

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

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

------
rebelde
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!

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

------
pwnna
I find that firebug slows down the browser after a while of debugging. Memory
leak? Make it faster :)

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

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

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

------
Yaggo
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/>

------
1337biz
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.

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

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

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

------
vanessa-dc
Keep "view selection source" !!

------
mikeburrelljr
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

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

------
ericb
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_.

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

~~~
monk_e_boy
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"

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

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

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

------
flexterra
Chrome has a button that gives format to minified code. It's useful.

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

~~~
paulrouget
(that's unrelated. We support restartless extensions. And that depends on the
extension. Some do support that, some don't).

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

------
Yahivin
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!

------
kevinSuttle
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?

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

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

------
digitalzombie
edit:

Sorry I didn't read the link you included.

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

\---------

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.

------
aviraldg
Make it possible to run DevTools in "editor mode" ie. make it possible to run
DevTools in a separate tab as an editor.

------
kadaj
Dev tools provided by webkit is really cool. Why not get some thing similar.
At least a debugger and a good console.

------
mnazim
Ability to move tabs to the sidebar - left or right is needed badly(at least,
I need it badly).

------
kineticfocus
A 'nice-to-have' security feature: when parsing the PDF, show the embedded
JavaScript code.

------
grapjas
Not related to devtools but please make the facebook addon or plugin or
whatever removable

------
serverhorror
Look at phantom.js -- make it happen that Firefox integrates easily with the
framework.

------
felipebrnd
I think a macro recording tool would be very useful (maybe something like
Selenium).

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

------
aaronsnoswell
+1 for remotable debugging. I love this feature in Chrome.

------
conradfr
A close/dismiss button on the responsive design mode ...

------
lignuist
JS and CSS minifier that (optionally) removes dead code.

------
bharad
Firebug: Make testing hover and active classes easier.

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

------
samiullah
Add some git plugins ,if possible ...

------
frozenport
I want an IDE for Javascript.

------
stfnhrrs
Webkit

------
d0m
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>

~~~
ptgloden
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.

------
dylanhassinger
Webkit?

------
benaston
Copy Chrome?

~~~
digitalzombie
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.

------
antihero
Make it _exactly like the webkit dev tools_?

~~~
mmuro
Safar and Chrome's dev tools are not the same.

