Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: Webdevs, designers: what devtools should we (Mozilla) build in Firefox?
470 points by paulrouget on March 5, 2013 | hide | past | favorite | 347 comments
I'm @paulrouget. I'm part of the Firefox Developer Tools team (we are working on the builtin tools and Firebug). I believe that the HN community includes a lot of web developers and designers, so I guess you can help us.

We have recently added a bunch of new builtin tools in Firefox (please try Firefox Aurora or Firefox Nightly to see a recent version of these tools). We also redesigned the way we show these tools (screenshot here: http://paulrouget.com/e/toolboxTesting/).

We are now working on defining what should be our next moves, and I'm trying to gather as much feedback as possible.

The current plan is to build a bunch of performance-related tools (see https://groups.google.com/forum/?fromgroups=#!topic/mozilla.dev.developer-tools/L9vfZ1-smUI), improve the user interface (better theme), make the tools remotable (for mobile development), and drastically improve the WebConsole (see an experiment here: http://paulrouget.com/e/jsterm.v2/).

But we really want to get as much feedback as possible to make sure we're going into the right direction.

What do you think we should add/remove/fix in our tools? Anything you miss from Chrome or Opera? Or anything you haven't seen yet you'll like to see part of the browser?

PS: because a lot of people have raised concern about "cluttering" Firefox: we are considering providing some of these tools only as addons, to keep the Firefox DevTools as simple as possible.




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.


I'm the author of http://tin.cr, it tries to solve this exact problem for Chrome Devtools. (someone else mentioned this in this thread).

I've spent some time thinking about the problem. In an ideal world a standardized protocol to push changes to a server would be awesome. I think it's unrealistic though to expect widespread adoption especially for existing frameworks to add code just for doing this. For example, have you ever heard of WebDAV? It was thought up along the same lines and it's virtually dead now.

A better solution for now would be for source maps to tell you the full local path to the original source file. Yes, in a world where we all develop from Chromebook-like devices against files in the cloud, this won't work. We are a long way from that world at the moment.


This was the original intent of the PUT method in HTTP.


When I try to install the extension I get the following error: "This application is not supported on this computer. Installation has been disabled." I have a Thinkpad T420s running windows 8 with Chrome Version 25.0.1364.152 m, any idea what's not compatible?


Neat. Out of interest, how does Tincr compare to LiveReload or CodeKit?


At the moment, it has two big drawbacks compared to those two

* The live reloading doesn't support full refreshes. You can only do live updating inside the running page. Chrome has built-in support for this. Works awesome for css. JavaScript support is a little flaky. * It doesn't support re-compiling Sass, LESS, CoffeeScript, etc. on a file change.

I'm actively working on fixing both problems.


This is quite honestly the best new feature we could be given. It's not an easy task, but such a tool could save millions of man-hours.

Mozilla guys: if you implement this--even partially--I'll switch back to Firefox in a heartbeat.


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.


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.


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.


Love this idea, it would make source modification a piece of cake for every browser-maker to implement. To allow for compatibility, this feature could be activated only when a X-Source-Modification-Enabled (or something) header is present on the original page. The header's value could even be the (relative) endpoint to call!

The simplest middleware that would pop up would be a diff generator. But with source maps, web frameworks could track what exact source files were used.


My crazy idea is to just use git + some sort of source map style overlay on both ends to track changes and pass them back and forth.


A lot of these ideas could be supported via a proxy system. Something like charles http://www.charlesproxy.com/ on steroids. If you wanted to edit yahoo.com , you would checkout your local repo, have charles point to the local repo, and then your on the fly css/js fixes would go to your local repo. Yahoo's server wouldn't have to support it.


It seems to me, that with source maps in the browser, the browser should be able to PUT the original source file, with the correct file hierarchy. So, downloading assets.min.js, editing models/Foo.coffee, PUTting models/Foo.coffee.

That would be really something.


I'd be happy even if this was limited to the local file system! I've already got build and deployment set up, and modifying the web servers seems like a hassle.


A lot of people are asking for that. I guess sourcemap is (part of) what you're describing. We're working with Google on this, and we'll soon have builtin support at least for JavaScript (not HTML/CSS yet).


Something like this, but for all (standard) source files, not just JS.

http://remysharp.com/2012/12/21/my-workflow-never-having-to-...


Isn't that the wrong way around? Instead of pushing to the web server and let it figure out where to put the changes, change the local file (or file on the server, via NFS or such) and push the changes to the browser as well using tools such as swankjs [1] or, once it's ready, Kite [2] (that's my pet project).

For higher-level languages like Coffeescript or SASS, run a local compiler on the file or function so you can push the compiled code to the browser.

A nice side effect of this approach is that you can use a real code editor instead of the Notepad-style editor embedded in the browser.

In that regard, my #1 feature request for the Firefox devs is to finish and implement the remote debugging protocol [3] and, preferably, work with the WebKit devs towards unifying the two protocols.

[1] https://github.com/swank-js/swank-js

[2] https://github.com/jscheid/kite

[3] https://wiki.mozilla.org/Remote_Debugging_Protocol


(Disclaimer: I'm working on http://www.webflow.com to try to solve this exact problem.)

I've been thinking about this issue a lot over the last year, and it's really as hard as you state (and then some). We ended up having to create our own supersets of the DOM/CSSOM in order to keep track of individual elements/selectors as they are created/removed/changed. I would be very surprised (and pleased) if Mozilla was able to implement this in a way that works without lots of additional/manual inputs. If you think JS source maps are a hard problem to solve, I'd say this one is at least an order of magnitude harder.


My thought is that this is really most useful for CSS and the transformations that SASS/LESS are capable of are relatively mundane in comparison to CS -> JS. In addition I only see this as a tool for development, not something that I would want running in production so you don't have the concerns over increased file size or still supporting minification that you do with source maps, assuming you want source maps in production for error reporting.

I can envision simply using structured CSS comments to pass the needed information to the browser. The browser only needs a structured pushing protocol, baseline comment format, probably handling of comments that indicate file boundaries (used for pushing to the correct resource) and a 'plugin api' to allow plugins to parse other comments in a meaningful way, SASS/LESS could provide a 'Dev tools' plugin to parse the comments and support whatever editing features they wanted. They would also have to support generation of the comments in the preprocessor.

The important bit is a standardized pushing protocol, a standardized way to provide additional mapping information and a standardized 'plugin' style system to allow things like SASS to add to dev tools additional editing support.

Just one theoretical approach, still a ton of work, but I really think there is a lot of developer time spent dealing with this issue so it may well be worth it.


I tried to enter my email address to get notification of your launch. Nothing happened when I clicked the button (using IE 8)


Woah, oops - thanks for letting me know. Trying to stand up a VM right now so I can see what's going on.

Edit: Should be fixed now.


I'm having similar problem on firefox 19 on ubuntu 12.10 x86-64. After some seconds it says "Hmm, that email address doesn't look right...".


I'm not sure I would say that JS source maps are a hard problem to solve.


Fair point. However, it has taken years to get to where we are today (CoffeeScript just shipping support, limited browser support), so it doesn't seem to be an easy problem either.


The delay in CoffeeScript support had to do with the design of the compiler more than anything. CoffeeScriptRedux [1] has had this in for quite some time.

[1] https://github.com/michaelficarra/CoffeeScriptRedux/


Indeed the ecosystem and support around source maps isn't super easy in total, but I wouldn't call any particular point in isolation particularly difficult. It's just that there is quite a few of them.


+1. I can't even add an element directly in the Chrome dev tools - you can only edit an existing elements HTML and append something after it.

My kingdom for a '+' button.


You can, sort of.

Right click on an element and choose "edit as HTML" and you can add whatever you want, granted it offers no reasonable formatting, its just a wall of text, not even tabs / line breaks.

It is also broken in that when you do this Chrome rebuilds all the sub elements of what your editing so if there were event hooks or anything like that on the elements they will be gone.


Not to mention dragging over text to select it usually results in the entire HTML fragment getting destroyed when Chrome decides that you're actually attempting to drag the text to move it somewhere else.


> It is also broken in that when you do this Chrome rebuilds all the sub elements of what your editing so if there were event hooks or anything like that on the elements they will be gone.

This may not be completely true. In Edit As HTML mode every effort is made to retain the original elements. If you move some tags to another location, the real element (and handlers) should actually be retained.


My workaround is to click an element, then type into console

    $0.appendChild(document.createElement('tagName'))
but yeah, a [+] button would be nice…


It really seems like you didn't read my post before you replied to it.


If you're using Chrome, try out: http://tin.cr/ It seems to be at least very similar to what you're looking for!


Not perfect but what I did last time I played with backbone:

* As I used sass, coffeescript and haml, I used guard (https://github.com/guard/guard) to watch the source files and automatically compile them

* Used serve (https://npmjs.org/package/serve) to serve the directory over http, could use python -m SimpleHTTPServer too

* Used live.js to pull for changes (http://livejs.com/)

As I said it's not perfect though, while CSS changes get applied transparently, changes in javascript will reload the page (you can also watch only for CSS changes). Still for working on CSS, especially together with LESS or SASS it's quite pleasant. Also it spams your Firebug console pretty bad.


I wrote a post about a year ago, to open up a discussion about what browser vendors can do to encourage rapid prototyping designing in the browser, by giving them tools for visual design that they would opt to use over software like Photoshop/Fireworks.

I'd love to see more tools that enable rapid prototyping, including the ability to craft CSS in a more visual manner.

Here's the post, for any who are interested:

http://blog.colin-gourlay.com/blog/2012/03/how-can-browser-b...


Yeah, I think it would really set Firefox above everyone else is if it had its own web IDE (live WYSIWYG and code editing) built right in. It'd have to be a good one and you shouldn't try to force people to use it who don't want to. But I agree with other folks here: We all would kind of like the option to use something like that right in the browser.


aaaaaaand then we'd be back to SeaMonkey.

Not that there's anything wrong with that.


It's not always possible to push changes back to LESS or SASS due to ambiguity at which level changes should be applied - if you're editing CSS values. The browser would have to display SASS or LESS in the inspector for what you're suggesting to work.


Chrome Canary (perhaps, the Dev channel, too) supports navigation to CSS selectors, property names and values (Ctrl-click them) in the corresponding Sass resources (the Sources panel). You can edit Sass and save it to disk (right-click the editor, "Save as...").

Now, if you have the "Support for Sass" experiment enabled, you'll see the "Auto-reload CSS upon Sass save" timeout setting to reload re-generated CSS files after "sass --watch in:out --sourcemap" (or equivalent) has updated them on the local disk.


Just being able to hold down a modifier key to move an element up down left and right would be great. You can do this in one dimension at a time at present but to be able to exactly place something would be a tremendous time saver.


>You can do this in one dimension at a time at present //

In FF dev tools?


+1. I know it's not the main line of discussion here but I wonder how can this feature be leveraged for CSS preprocessors like Less/SASS where CSS reaching the browser is never edited directly.

Edit: Gramer and language improvement.


If you could somehow get sourcemaps for haml/sass/whatever it would make debugging css/html in the browser so much easier when working with serverside templates.


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.


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


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


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

I tried to clarify this in another comment: https://news.ycombinator.com/item?id=5326873 - let me know if I can clarify further.


That still doesn't why there are two separate developer tools. Is there something that an in-house tool tied into firefox is capable of that is impossible for a plugin to achieve?


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


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.


If Firebug isn't in house then I have no idea how a Mozilla employee could justify working on Firebug while their own "official" dev tools still has such a long way to go.


Why do both Firebug and the built in tools exist, if you guys are committing to both? Why not just put everything behind Firebug?

One thing I don't like about the Firefox debug tools is that they are split up into different tools. Developer Toolbar, Web Console, Debugger, Error Console. Why do we need all these to be separate?


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

> Firebug allows you to do that.

Please please tell me how to do this. I want the "Web Developer" menu gone. I want Firebug as a first-class entry in the Tools menu again. And while you're at it, it would be really nice to have "View Source" and "View Page Info" in the View menu again.

Perhaps I'm a little bitter, considering I saw the DOM Inspector ripped out of Firefox, relegated to Firebug, kicked around, and now that Firebug is awesome, I see weird versions of a Firebug subset getting in the way. Why couldn't it be part of the browser, and why not just put Firebug in the browser if you want it back in?


I couldn't agree with this more. I work primarily in Chrome and find it very frustrating nowadays when I have to switch to Firefox to debug. Back in the days when Firebug was the only show in town, I loved working in Firefox. Dev Tools gets in the way.

I appreciate the flashy experiments like Firefox Command Line but there's little chance of them entering into my everyday workflow unless I have the chance to learn them properly. I won't get the chance to learn them properly until I reach for Firefox as my main development browser.

On another note: The Chrome Network panel is invaluable to me and streets ahead of the Firebug Net panel. I find it hard to explain why I prefer it as the features are fairly similar, but the experience is much better. Maybe it's about the layout and clarity vs. density of information.


Just wanted to follow up this comment by saying that I've been playing with the latest Firefox nightly this morning and it's much more inline with what I want out of a browser's inbuilt dev environment. I'm really impressed.

Two things that still stand out as lacking when compared to Chrome are the JS console output and the Net panel output (really hate those popup windows).

But these things can be ironed out. Well done for getting Firefox moving in the right direction.


Couldn't agree more on this.


My needs exactly.


Firebug has a "disable built in tools" feature that prevents Inspector from loading already.


Btw this is done by opening about:config and setting devtools.inspector.enabled to false


Firebug key is "extensions.firebug.hideDefaultInspector"


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.


I thought that the latest browser tests showed that FF used less ram than Chrome. http://lifehacker.com/5976082/browser-speed-tests-chrome-24-...

Unfortunately, reputations stick.


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.


This is my current Chrome memory usage

  Browser	                                    	       
  Google Chrome 25.0.1364.97

  Memory 
  Private      Shared  Total
  3,950,040k 12,805k 3,962,845k

  Virtual memory
  Private      Mapped
  4,728,936 k 937,320 k
This is with 18 tabs and ~20 extensions. Chrome isn't really light on memory usage anymore. 1.5GB of that is split between Google Reader and the Spotify web player though, anything Javascript heavy seems to use an absurd amount of RAM after it's been left open for a few days.


I am back to using FF for my everyday browsing as Chrome takes about 2x as much ram with my 50 tabs (casual observations, not benchmarked).


We already have a team working on memory consumption (and we already made some gigantic progress). We also have a team working on improving addons APIs (see the new builin SDK).

We are also looking at existing extensions.


What about an easy way to redistribute customized versions of Firefox? What im thinking about is something like a software pack or plugin bundles, similar to ninite. Very much like the spf-13 vim distribution. Or like some of the bundled eclipse distributions, like PyDev or Aptana. It's a batteties included idea.

There are a lot of cool plugins, but new users don't always know what to get. But if if it was easy to fork Firefox and add some plugins and redistribute it in whatever forums or communities they prefer, that would be cool.

So there may end up being a Firefox for reddit, for image processing, for web design, for web dev, etc.


[deleted]


How exactly does this help web developers?

This has been considered and rejected as inferior to the current approach. The Android browser used this and it was rewritten to get rid of it.

Let's focus on doing things that improve the user experience rather than blindly copying features from other browsers without considering if they make sense.

Moreover, it has absolutely nothing to do with the question asked.


I'm not sure what he said, but I assume he said something about Electrolysis.

Didn't they ditch Electrolysis because of issues with many nsplugins? I am not aware of other reasons it was shitcanned.


Plugins and add-ons AFAIK. There are also memory/performance implications, which apparently were not insignificant on mobile platforms. Given that Chrome uses more memory than Firefox, it's perhaps not insignificant on desktop either.


Meh, if you're referring to making every tab its own process, I personally don't like that. I'm sure there's performance or stability reasons for Chrome's decision, but I also don't really like having 30 different processes open for the one application.


Why not? I'd say 30 processes is a lot better than 1 process. You also need to take into consideration that the number of cores is increasing pretty quickly. Pretty soon consumers will have 32 cores and whatnot. I'm a Firefox user but really it's the largest weakness Firefox is having. If I open two new tabs simultaneously, the whole browser can freeze for a bit.


    Why not? I'd say 30 processes is a lot better than 1 process.
1 process is better than 300 processes, and I sometimes have more than 300 tabs open. (I always have more than 100 tabs open.)

    If I open two new tabs simultaneously, the whole browser can freeze for a bit.
People who prefer one process per tab tend to mention that tabs freeze up their browser, and I believe them, but this never happens to me. Maybe it's because I use NoScript and have all plugins disabled, except for Flash, which I block with Flashblock.


Honestly (and I'm fairly certain this is a bad reason), it's a cleanliness thing. If I use top or the process manager, it gets annoying to scroll through countless variations of 'chrome'. Maybe if the process manager could group those into one heading where I just see "Chrome (30 processes)", I'd feel better about it?


My favorite thing about Chrome is that I can open up "View background processes", get a list of which tabs are using up how much memory, and then click-and-kill selectively.

But this is an end user experience, rather than a web dev experience.


That's what my "process manager" called pstree on Linux does:

├─firefox───36*[{firefox}]


Your comment is somewhat self-contradicting. Baking plugins into firefox will increase Firefox's memory footprint. Plugins are plugins for a reason -- some people will want the functionality and others will not.

How would you like to see the API for plugins/add-ons improved?


Dynamically-loaded libraries (.DLL, .so, etc) have been around for decades. A feature can be "baked in" and still loaded (and unloaded) on-demand.


We do lazy load the devtools.


Mozilla rocks!


This and tabs on the left. It feels like using Tree Style Tab is not really fully optimized.

I don't think you need to add a more things for developers. The tools already present are good enough, I saw someone suggesting a built-in sFTP. That's just too much.


Tree Style Tabs should be a core feature IMHO. It's the single most important feature for me.


I still don't understand why it isn't. We have wide screens and we use more and more tabs.


Yeah it's not a developer feature but I'd love this too. It's just a good way of managing lots of tabs and developers do have lots of tabs open.

Tree tabs are the more conventional way of understanding lots of items (and tabs are hierarchical -- parent tabs are where you opened the current tab from).


How much RAM do you find FF using? And how much do you have in your machine?

Just curious because I rarely find FF creeping up towards a gig and RAM is so ridiculously cheap most of what I have just sits around doing nothing. (Edit: shouldn't have said nothing, but I'm not maxing out even with 4GB unless I am working in Photoshop/Illustrator)


Mozilla is working hard to manage memory/RAM in the most efficient manner. In many 3rd party tests, Chrome uses more RAM than Firefox for the same set of tabs. Mozilla is tracking this here: https://areweslimyet.com/faq.htm


What about memory analysis tools for javascript? Im my experience ATM most developers don't have a clue about whether they have memory leaks and where the could optimize (javascript) memory usage. Chrome does have heap snapshots https://developers.google.com/chrome-developer-tools/docs/he.... Also chrome has some tools to analyze thos snapshots they are still far from what the Eclipse Memory Analyzer http://eclipse.org/mat/ can do for Java apps. Fortunately chrome heap snapshot support will be coming soon for the Eclipse Memory Analyzer. IE BTW now has similiar heap analysis tools.

Regards, Markus


When is the last time you compared memory use?

I have this thread, HN home, espn, and techcrunch open in both FF and Chrome right now

Chrome 454,920K Firefox 487,156K

a 30 meg difference is really _not_ a big deal.

Anywho I find myself using chrome for dev while FF is for browsing. The AngularJS and Speed Tracer addons are nice for Chrome. I browse with FF because they support tags with bookmarks, which I'm addicted to


Firefox uses much less memory than Chromium does on my Linux machine. How much memory is Firefox using compared to Chrom(e/ium) for you?


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?


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


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?


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


Thanks so much for the plugin -- I use it frequently. It's the one bookmarklet I actually use enough to keep on my bookmarks bar.


> Visualized event bindings

Yeah, we've been thinking a lot about that lately. Not a priority though (yet?).

> An aggregate repaint view

I filed a platform bug just about that today :) I think it can be done soon.

> An intelligent debugger that would automatically step over certain files

That's interesting. I never thought about this. I like that.


> > An intelligent debugger that would automatically step over certain files

> That's interesting. I never thought about this. I like that.

You haven't been reading your mail, paul!

We discussed this briefly in https://groups.google.com/d/topic/mozilla.dev.developer-tool... and are planning to work it in to our schedule.


Regarding repaint view, go to about:config, nglayout.debug.paint_flashing to true, and you can catch some repaint problem. Agreed, it is not the most discoverable feature. afaik, we don't have a tool for overdrawing. Hopefully this will change.


Last time I used the Firequery plugin for Firebug (way back in FF3), it would show the elements on the page that were also represented as jQuery objects... that plugin might be a jumping-off point for how to show visualized event bindings


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.


We do have plans/patches for that.


this sounds like a "plugin" use case?


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.


Not only are people doing this, but they're doing it with swank (as far as I know). Check out swank-js[1]. There is a really cool demo of on EmacsRocks[2].

[1]: https://github.com/swank-js/swank-js

[2]: http://emacsrocks.com/e11.html

But yeah, some sort of more official or maybe more extensive support would be pretty cool too.


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


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.


Just FYI: You can do exactly this with the latest Light Table[1]. :)

[1]: http://www.chris-granger.com/2013/02/27/light-table-030-expe...


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.


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


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.


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


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


I agree that source maps are the right solution, but even the ability to pretty-print the indentation and separate statements onto lines would work wonders.

I've had too many errors on line 1.


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.


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


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!


All you said has been implemented in Firefox Aurora.


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.


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.


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.


Firebug allows you to disable the builtin Inspector button.


The developer tools don't slow down Firefox if not used (lazy loaded), and the space used is very small.

Firebug allows you to disable the builtin Inspector button.


> Firebug allows you to disable the builtin Inspector button.

I believe the parent was saying it should be a joint effort and all the resources should be pooled into one. I prefer Firebug as well and would love to see it get better, faster.


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.


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.


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!


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.


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


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.


We have a plan for performance tools: https://groups.google.com/forum/?fromgroups=#!topic/mozilla....


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


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.


We have plan for performance tools. See: https://groups.google.com/forum/?fromgroups=#!topic/mozilla....


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!


Agreed - we've built extensions for Chrome, Firefox, IE & Safari ; Firefox and IE are on the same level with regards to debugging, that is : not pleasant. It's a shame because browser extensions have great potential : I'm increasingly turning towards them for a variety of use-cases, however currently limiting efforts to Chrome due to availability of tools.


I second this. I had to create an extension recently and found the entire process a nightmare. Having to use the Venkman debug tool was a large turn off.


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


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


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.


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


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.


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


Sourcemap support + unminification are coming.


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.


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


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!


As a workaround, you can close and reopen the console to get rid of the object browser. I also use Awesome, and it works for me.


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


Chrome does: http://i.imgur.com/KLmkYjH.png


Your DPI is insane! What are you using?


Maybe a MacBook Pro with Retina Display?


Oh, nice - didn't see that yet. Thanks for posting. But still - it would be nice to have it in firefox as well :)


+1


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


Thank you :) Network tab is our next tool.


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.


I get the idea :) Thanks.


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.


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.


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


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.


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.


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.


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


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


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.


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.


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


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.


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


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!


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)


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.


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


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?


Frame-by-frame debugging. Not the first time it's asked. Thanks.


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.


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.


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.


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.


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.


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


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


Merging these two tools would be by number 1 request.


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.


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.


There's an API for that.


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


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


That's great. Thanks.


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.


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.


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)


You should, I like that idea very much. I was also having a similar problem with mixing work & personal data. Now I am using Canary as development browser, that itself is enormous resource hog. If you will continue working on such a project I am happy to help!


I'm going to see about resurrecting the project and putting it up on Github soon!


You can get a lot of this by using Chrome's Users feature. This allows you to switch between user accounts and have clean, extensionless sessions.


Chrome Incognito is perfect for you. Blank slate, no extensions, every time.


You mean Chrome's incognito mode? But that means I have to use Chrome's devtools, which are not as good as Firebug by far.


What are you missing in the Chrome DevTools? I'd love to improve them for you.


It's small usability issues more than anything specifically missing. Some things off the top of my head:

* The "point to find in DOM" icon is tiny and squeezed in between other icons at the bottom of the page. It's one of the most important tools, imho, and it can't be tucked away like that. And it needs a keyboard shortcut to toggle it.

* The "point to find in DOM" is very flickery and just feels more shoddy than Firebug's. Firebug uses a rectangular border, which I think makes more sense than a colour overlay which obscures the content.

* The DOM tree view is gnarly; by which I meant that it's cramped, squeezed together, hard to edit and navigate, and just generally feels like one is fighting a jungle of vines and branches. It needs more spacing and more a consistent editing mode. Firebug's isn't great, either, but it's more spaceous.

* The CSS style view is also pretty gnarly in Chrome. The hit area for the checkbox to enable/disable a property is tiny, for example, and the overstrike is black, whereas Firefox wisely grays out disabled items. Chrome uses these dividers which are completely unnecessary given the source information on the right.

* The action to add a property is to click somewhere inside the CSS view that is not text. Yes, to click. It makes no sense, norwhere in any user interface do you add stuff by clicking in empty space. Firefox more wisely uses double-click, even if that's not great either, but at least has some precedence in GUI history.

* Chrome has no tools to add styles. Firefox has a right-click context menu for CSS properties allowing me to right-click somewhere and select "New property" or "Add rule".

* Chrome: The icons in the lower bar change depending on which tab (Element, Resources etc.) you're in. Pretty confusing since some of the icons apply to the tab you're in, and some are always enabled (like the "point to find in DOM" button).

I could go on. But that's a start.

In fact, to illustrate some of these points visually, here are two screenshots of Firebug (http://i.imgur.com/A4ZD1x8.png) and Chrome (http://i.imgur.com/uVYbsxz.png), each with the same height. Consider:

* Firebug shows in this case all the CSS information I need for the element. Chrome is information-poor in comparison.

* Chrome has inserted a useless "element.style" entry which is unnecessary unless you actually want to add style to the element; for inspection purposes it's superfluous.

* Chrome also wastes a whole line for the "computed style" part, which Firebug wisely tucks away in a tab.

* Chrome wastes the whole lower line on the DOM path, which I personally never use. In Firebug it's part of the DOM view and doesn't affect the CSS view.

Here's an improvement suggestion I'm surprised nobody has thought properly about. One thing I often need to debug is the flow between pages. For example, in some web app I click a "Login" link, get a login page where I edit stuff, then click "Log in", then the server does a few redirects and finally gets me to the "you're logged in" page. Now, Firebug and Chrome both have a "persist" mode for the network view which allows one to see the sequence of pages being requested, but since it's a strict log and mixes different content it's very hard to read, and very hard to figure out the true flow of events from. Here is such an exchange: http://i.imgur.com/aCs8pmF.png. To get it I had to select the "Document" and "Other" event types. But I have to spend 10x as much time analyzing this than if I simply go to Firefox and turn on the stupid but effective "Live HTTP Headers" add-on and then copy everything into a text editor. The HAR is too cooked to give me a proper bird's eye view.

Truly what I wish for is some kind of graph that's page-oriented. Here is a very quick Illustrator mockup: http://i.imgur.com/pQqOtPX.png. Obviously hovering/clicking on various elements would let you look at headers and what not. The idea is really a persistent timeline with a certain history, and which presents a logical view of browser navigation. It's important here to distinguish between user actions and stuff done by the browser (redirection, AJAX); it's important to know when something contributed to a page render or was just one link in a chain of redirects.

Again, I could go on, but I have better things to spend my evening on. :-)


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!


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


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.


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)


I think a general pattern is that the console should be smarter about the specific stuff people do in a console, in the browser. Every kind of DOM node should have specific representations appropriate for that DOM node, not just what falls out of some generic printer. There are array-like objects that get printed out funnily because they aren't real arrays – but {0: x, 1: y} is no more clear about the actual nature of the object than [x, y].

Why people won't code vendor prefixes into CSS tools I don't know; the obvious thing is for Firefox to ignore everything but "-moz-*" – and even then, to warn selectively (i.e., if there are old versions of Firefox that require a prefix, even if the new version doesn't, don't warn about it). Or hell, crowdsource the whole thing, when you encounter something invalid fall back on a community edited document about what is valid in other browsers, or represents a common and acceptable CSS hack. There's often good information in the CSS warnings, but there's too much useless information to find it. I'm annoyed things like LESS and SASS don't treat vendor prefixes specially either.


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


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


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.


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.


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.


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?


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

You are reinventing ETags.


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!


Why not just sign the file with GPG or openssl or something?

If you need to deal with clients that aren't aware of the mechanism, you could just put the GPG signature in a custom HTTP header.

If you need to use cloud hosting or the like, and you can't return custom headers, just put the signature in a file with the same name with .sig attached. In fact, I just downloaded a kernel tarball the other day, and kernel.org does exactly this [1].

I also found a few related articles and RFC's [2] [3] [4].

[1] https://www.kernel.org/pub/linux/kernel/v3.x/

[2] http://en.wikipedia.org/wiki/Magnet_link

[3] http://www.ietf.org/rfc/rfc3230.txt

[4] http://www.ietf.org/rfc/rfc6249.txt


Because the browser should have no way of verifying that the file was really constant, and to do that it would need to ask other authorities who have downloaded the file in the past.

GPG only allows you to sign something, not guarantee it was always constant.


I really like your first proposal. The second one is good too, but less pressing to me than the first. The software I'm working on uses static JS with a high security requirement, and is meant to be deployed on any host. Integrity guarantees would be valuable for that.


I really hope Mozilla does it!


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.


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.


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


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.


Noted.


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.


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


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!


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


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


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?


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.


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.


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.


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.


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.


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


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.


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!


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


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

-- A Vim user


http://bukk.it/beemodance.gif


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


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.


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.


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


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.


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.


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


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


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


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.


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.


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.


Indeed. Not the first it's asked.


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.


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.


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.


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.


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.


Oh, I really like that suggestion!


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.


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


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.


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.


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.


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.


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


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)


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


* 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


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.


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


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


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!


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.


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.


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


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.


+1 for the advanced REST testing/debug features too. I would really like to see / modify / replay REST queries easily.


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


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.


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


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


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.


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.


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


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.


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


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.


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


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


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.


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


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!


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.


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


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


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.


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.


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/


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.


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.


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.


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.


Keep "view selection source" !!


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


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.


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.


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.


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"


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.


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.


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.


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


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.


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


Depends on the addon, some don't even need a restart!


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.


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!


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?


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


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.


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.


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


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


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


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


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


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


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


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.


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


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


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


Firebug: Make testing hover and active classes easier.


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


Add some git plugins ,if possible ...


I want an IDE for Javascript.


Webkit


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


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.


> console-like tools to make programmers feel at home

A good portion of programmers don't use CLIs for development and only use IDEs. why would that be assumed to make devs more at home?


Webkit?


Copy Chrome?


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.


No Google Chrome is not perfect. bye


Make it exactly like the webkit dev tools?


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


Why settle for "exactly like" instead of aiming for "better than"?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: