From the top of my mind:

1. HTTP Request builder (think cURL with a nicer GUI and the ability to save presets);

2. Web Proxy, able to "stop-and-modify" requests (think Fiddler or Charles);

3. Network conditions simulator for throttling, packet dropping and limited bandwidth, with profiles (e.g. GPRS);

4. Local Mock REST API, with a few predefined endpoints (e.g. /users/) + the ability to create new ones (with configurable values such as random integers between X and Y or a random string which is a valid e-mail);

5. Multi-touch simulator (with a modifier key);

6. A usability test facilitator, able to create test scripts and automatically record timing and extra information (e.g. define a task that ends when user clicks the element with id X; when said user clicks #X, you annotate the time, the number of misclicks, etc). You could also implement this for static images, with clickable regions. I would love you for this one.

I see that concerning point one and two there is option 'edit and resend' visible if you hover over request in network tab, and there is also option 'enable persistent logs', that shows what happens between refreshes. Don't know how it works, just playing around for 10 minutes.

Overall I'm impressed with new network panel, much better than before.

That's pretty excited. Unfortunately when I try to edit and send a POST it gets changed to an option. Anyone know why?

The OPTIONS request you're getting is probably just a preflight request related with CORS policies.

Very nice list. I would also add the ability to associate breakpoints with DOM elements. As in "break on any attempt to read/modify a given element". That would be extremely helpful in debugging the hodge-podge of Javascript libraries that many modern web pages are.

The break on modifications should already be possible, by adding breakpoints to Mutation Events (as you can do already with e.g. mouse related events).

However, Mutation Events were marked as deprecated by allegedly bad design. We should be using MutationObserver[1] instead (which, I believe, will be equally helpful in observing changes).

[1] https://developer.mozilla.org/en-US/docs/Web/API/MutationObs...

The second one is possible with the Tamper Data plugin: https://addons.mozilla.org/nl/firefox/addon/tamper-data/

It would be very handy to be able to modify the payload of requests/responses as well without resorting to MITM proxy applications.

Tamper Data is not a MITM proxy. It's a browser add on that modifies the request before the browser executes it.

The best channel for these suggestions is our user voice [0], or devtools bugzilla component [1] though lot's of Mozillian's hang out on HN (and subsequently ring vote themselves out of oblivion).

[0] https://ffdevtools.uservoice.com/forums/246087-firefox-devel... [1] https://bugzilla.mozilla.org/enter_bug.cgi?product=Developer...

I've replicated the suggestions in user voice.

I'll share the link here, as HN readers may wish to vote for them: https://ffdevtools.uservoice.com/users/59733168-paulo-reis

Yeah on all this stuff.

> What tools do you need?

Safari 8 introduced "breakpoint actions" similar to Xcode's: when a breakpoint is set, it can be configured to not actually break (keep running even if the breakpoint condition matches) and if it matches:

* log a message

* play a sound

* execute code

* run a probe

Each action type can be used any number of time on the same breakpoint.

It's not the most stable and almost undocumented — the only documentation I've found is the second half of WWDC'14 Session 512 "Web Inspector and Modern JavaScript" (starting ~37mn in) — but it's a great system, one I've been waiting for for a long time, and one I'd like to see more of. Especially with all the other features in e.g. the Xcode version: Xcode can ignore the first n hits of a breakpoint and can capture an OpenGL ES frame. In a browser, the breakpoint could allow capturing the DOM state, the renderstate or a WebGL frame.

You can do this in the current dev tools by setting a conditional breakpoint. Conditional breakpoints allow you to write an expression which you can force to always be falsy. For example, "console.log()" returns undefined so it's falsy and it won't actually break.

> You can do this in the current dev tools by setting a conditional breakpoint.

It only performs one of the possible actions, is not extensible and the UI is terrible. So no, you can not "do this", you can do about 20% of it (possibly less so in the future) and stab your eyes out while doing it.

I know about that option, and I'd very much like to stop having to use it thanksbutnothanks.

Sounds great. I'd love to see it in https://ffdevtools.uservoice.com/

Hmm, interesting!

A MitM proxy like Charles (http://www.charlesproxy.com/) would be incredible. Debugging SSL issues is always difficult, and it would be great to have the tools all in one place.

Also, a shout-out to mitmproxy (https://github.com/mitmproxy/mitmproxy) which I've used on several occasions.

> What tools do you need?

I wonder where do you draw a line for a developer oriented browser. Is a good 'line' be tools for 'whatever loads on page'?

Since we already have color picker etc, I think good candidates are

* Onscreen ruler

* Gradient generator

* Builtin JSfiddle

* CSS sprite generator

* Image to base64

* JS/HTML/CSS formatter

* JSON tools - tree-viewer/formatter/validator

* XML tools - tree-viewer/formatter/validator/xpath

The JavaScript view in the debugger already has a built-in prettifier – look for the {} icon in the lower left corner.

It'd be really nice to have that for CSS, particularly if it could do a side-by-side view for e.g. source-mapped original and prettified CSS-as-used.

++1 for JS/HTML/CSS formatter and json tools

One of the most powerful tools in my chest is Firefile (https://addons.mozilla.org/en-US/firefox/addon/firefile/).

Firefile allows you to edit CSS in firebug and save to your stylsheet right from there. It's incredible how this smooths out my workflow and I can't work without it.

Firefile, though, doesn't appear to be in development anymore and it's latest release is broken. (I had to make some manual edits to get it working).

Any chance we'll see Firefile's functionality coming to FF Dev Edition?

If I'm understanding what you want, this is built in already.

https://developer.mozilla.org/en-US/docs/Tools/Style_Editor

Pretty sure you can. What would be nice would be if the same functionality worked with SASS (and LESS), so you could not only trace back to the original sources using source-map, but also edit the SASS, see the results in the browser, then save the SCSS files.

It would require a SASS interpreter built into the browser, not sure if that's practical or realistic. But it would help a lot for when you need to make edits locally and see the results on a remote server.

I use compass to watch the folder where my SCSS files are stored and compile automatically on save. That way I can use mapping to find the relevant SCSS, edit it in the browser, and save it to view the changes. It isn't as convenient as seeing the changes before save, but it's pretty close.

There is even a Hacks article about that https://hacks.mozilla.org/2014/02/live-editing-sass-and-less...

You know you can do this with the CSS inspector in Chrome, without any extension, right?

How?

Haven't used it in a while, but IIRC in the Sources tab of Chrome's Dev Tools, right-clicking a directory brings up a context menu with an "Add folder to workspace" option, which has you pick a local directory to map to the source directory. Then if you edit a file in the dev tools and command-S, it'll save that file where it appears in the local directory you picked.

Not just that, I recently found out that it also auto-saves changes that you make right in the css panel of the DOM inspector. It backs up your original value by commenting it out, but be aware of this when you experiment with this! Fiddling in with css in the inspector will make it persistent!

And also, it creates a history so you can revert to any version whenever you want.

Would you be able to share your edits?

I think they meant the edits to Firefile itself that got it working with the most recent Firebug.

I would love to have FF profiles as dotfiles that I can actually check into source control and use reliably. I blew a couple hours a few months ago trying to make FF fit into my existing system of dotfiles in git and it was extremely frustrating.

Every other program I use lets me check config into git, but FF insists on storing config data into profiles with randomly-generated names. It's very resistant to automation. I understand there is an FF-specific sync solution, but I want all my config in one place.

You can use the -profile switch to direct Firefox to use a specific directory for its profile. We utilize this for Firefox Portable at PortableApps.com.

Incidentally, if you're on Windows, you can actually check all of Firefox Portable into source control since it runs in a single directory. You'll get 'changes' each time its run from a new location, of course.

I feel like I tried this, but it was a while ago, so I'm a bit fuzzy. I'll give it a shot; thanks.

I am not sure why the names are randomized, but you can still check in the folder if you wish. The outer profiles.ini is all you need to map in the right folder name (on Mac / Linux at least...).

They're randomized to make it harder for an attacking program to find the location of it in a worst-case scenario when a Javascript or similar bug gives it read access to the local machine. The script in this scenario would be able to read files it knew the path of but not browse the drive properly. Without randomization, it would be a safe bet to try things like %USERPROFILE%\AppData\Mozilla\Firefox\Profile\Cookies and be able to pull your cookies for examination. If you can't get the USERPROFILE environment variable, the script could also do C:\Users\Admin\... and replace Admin with common names as well like John, Sue, etc. It also helps make it harder for malware to find. Not much harder, mind you, but it does require specific code to look for the Firefox profile as opposed to a single check.

I'd recommend using Firefox Sync to store your preferences and keep it synched across all your foxes.

I understand this is an option, but it's super frustrating that the FF profiles mechanism wasn't built the right way from the ground up.

There are significant advantages to having all your config in dotfiles beyond just keeping everything in one place: easy branching, getting rollback for free, human-readable diffs, etc.

Just be glad they eventually managed to kill Mork!

https://en.wikipedia.org/wiki/Mork_%28file_format%29

I'd love it if the Responsive Design Mode had multiple viewport support so you could have the same page visible at multiple breakpoints simultaneously

Add my vote to this one.

Also, having more than 6 presets would be better. There's so many devices with different viewport sizes now. Chrome at least has a fairly deep list of devices you can test with their responsive tool. It would be nice to see a more robust list in the Developer Edition.

This is not quite the same but still helpful: http://ami.responsivedesign.is/

>What tools do you need?

User agent spoofing for every tab. Mobile development is hell without it and nowadays almost every site needs to be developed with mobile devices in mind, which makes FF a bad tool for web development. Just copy Chrome in this regard, they do it right.

A really small thing that would be immensely useful to me would be a quick way to to copy or save as plain text a full HTTP request & response, with a little bit of nice formatting to make it human readable. I often find myself passing this data along to API developers via email or chat to debug issues.

I can always just copy and paste directly from the request inspection dialog, but that loses all of the useful formatting, making it hard to parse, or requiring me to go in and add line breaks if I want to be nice to my fellow developers.

Small, but it's the sort of detail that makes for a nice, easy experience.

If I may offer a shameless plug...if those requests are on public DNS, you can capture and share them with Runscope: https://www.runscope.com/docs/debugging https://www.runscope.com/docs/sharing

> What tools do you need?

A WebIDE that isn't focused on mobile? Not sure if this is already possible with WebIDE but the focus on mobile-first makes it confusing.

I do a fair amount of prototyping on WebGL and the web platform. However my current flow involves managing my project files, serving them to FF, and building the final bundle via a collection of third-party tools, libraries, and applications. I then run, test, profile, and tweak in FF.

It'd be nice to have a source editor and project manager built in. Give WebIDE an option to develop for desktop FF or something. Focus everything on live-coding: a DOM-enabled source editor could detect new nodes and tell the context to redraw the page; the debugger could highlight the source lines as I step through; the scripting engine can update the DOM-aware editor and highlight added nodes; I can connect source buffers to a namespace REPL to recompile and execute definitions on the fly.

Either that or add a chrome-less mode that allows me to embed FF inside my development environment and open up the remote APIs to allow for more interactive debugging, profiling, etc (eg: http://www.emacswiki.org/emacs/WebKit)

Built-in Postman-alike API builder.

This!

Critical path performance profiling:

1. Performance timeline which shows major events (e.g. DOMContentLoaded, load event) and the network / scripts which blocked them

2. Initiators for reflow, layout, etc. events. Currently it's really easy to identify a JavaScript hotspot if it's pure JS but it's hard to learn what's triggering hundreds of reflows, particularly in non-obvious cases such as CSS transitions.

A simple way to edit Host: header so that it doesn't necessarily match the url host part used to get to the site. Debugging name based virtual hosts configs via editing host files is a huge pain point for me.

Integrated Unit Testing, mocked after PHPUnit+Selenium.

Would love to be able to save scripted unit tests, preferably per URL. Right now it is a bit of a pain point with test suites in JS, PHP, etc... what if we want to switch to another language? It would be better if the tests were local to the browser, unhinging us from some of the language dependencies.

Ability to set the task switcher icon of the Firefox instance.

If I'm alt-tabbing it helps identify which FF instance I am switching to

> 1. The Firefox Tools Adapter ("Valence"), which lets you use the Firefox dev tools to inspect and debug pages in Chrome for Android and Safari for iOS. The goal: one set of tools to debug any browser.

That's amazing. I can't wait until we have standard wire protocols for all of this so that I can stay in an IDE while writing GWT/Coffeescript/JS/etc., e.g.:

https://github.com/sdbg/sdbg

(AFAICT both the FF and Chrome teams seem hot on building IDEs into their browsers, but, sorry, that's a step down the all-in-one Netscape Suite road IMO. :-))

I wonder if this implementation will allow the GWT debugger to work with Firefox again. The last version of FF that works with it is, I think, 26. When they removed the NPAPI layer.

Well, the code is better than that of Communicator :)

It'd be nice to have the URL bar entries as combobox dropdowns

Hand editing by moving the cursor is so fiddly and error prone.

Take:

  http://my.app/path/to/node?a=123&b=A34

it would be nice to be able to type into the parameters. Say change path to path1 or value of the b parameter from A34 to B67 .

Having MRU entries for each param value in a dropdown would be quite useful too.

You can double click 'path' on Window but not on Linux.

https://bugzilla.mozilla.org/show_bug.cgi?id=926249

Treestyle tabs like layout by default.

Seriously, FF without treestyle tabs IS NOT USABLE, and treestyle tabs breaks now and then in Aurora. Having such a layout actually being supported would be very nice.

As a long term Aurora user, a working profile switcher that actually respects resetting the default profile to the usual one would also have been nice.

I want to control / inspect Internet Explorer and Chrome desktop and Firefox in one consistent app. Moving between different devtools sucks. Browserstack and VMs have horrible latency.

It would be cool for Developer Edition to help me test websites everywhere. I'm not sure how technically you would do that though.

2 and 4 alone are reason enough to use it, nice work.

EDIT: Wow after trying it out it seems like a long-time bug I've been experiencing has been fixed, I'm willing to bet it's not just the clean install either because I tried resetting Firefox multiple times before and it hadn't helped.

Considering eighty-something percent of people who responded to the survey despised Australis, I could see a lot of people choosing it for #4 alone.

I want a command-line tool I can invoke from a Makefile, to refresh pages affected by the compile I just did. Existing solutions for doing this are awful and this represents more than half the time between saving and seeing the result on screen for me.

Probably not the right place for suggestions. However...

Developer or not, I have long waited for the possibility to: 1. Store bookmarks in "unsorted bookmarks" by default when I use ctrl-D. This option lacking, my bookmarks menu is so much cluttered that it is useless. 2. Edit bookmarks comments, with ctrl-D. 3. Query bookmarks and tags precisely (a bookmark with tags t1 and t2 which title contains regexp r).

Today, with small hacks, I manage to search bookmarks and trigger web search through the address "awesome" bar. But a bit of syntax like in w3m.el would be so much better.

I should try to prototype it in an app. These functionalities should not be very hard to implement. But it seems to be too much of a burden :(

The current debugger lists the current execution stack horizontally. This is bad UI because it's hard to follow. It is more convenient for short stack hops but for deep traversal, it is worse than Chrome's vertical stacking in a tree.

Check the left hand side. There's a tab next to the file list that has a vertical stack trace.

I would really like to switch to this to get away from Chrome but there is one thing stopping me. Which is that in Chrome when I'm debugging JS I can see a full list of files in their folders and can open them up to see them and add breakpoints and things. Like this http://derp.co.uk/1ae64 But in Firefox all I get is http://derp.co.uk/3be04 which is of zero use to me and it means I can't use it over Chrome. Am I missing something or is this just not a feature that Firefox has?

Thanks

It does work for me, though: http://i.imgur.com/Hj6IlvM.png

I feel the same on that. FF should present that like a folder tree.

Does it inspect Safari on iOS 8?

(Google's ios-webkit-debug-proxy doesn't appear to yet)

Sure does! https://www.youtube.com/watch?v=eH0R10Ga4Hs

So did you start with ios-webkit-debug-proxy?

If so can you contribute the changes back - WebPagetest relies on this for driving iOS Safari

Firefox is unusable for developers with poor eyesight that use OS-level accessibility features such as high contrast on recent versions of Windows.

There is an open bug but no love: [ https://bugzilla.mozilla.org/show_bug.cgi?id=790706 ]. Firefox forces high-contrast colors, completely destroying HTML rendering, with no option to disable this behavior.

Using a high contrast theme in Windows doesn't mean i don't want to see web pages as their developer intended.

Chrome gets it right, why can't Firefox?

I am not familiar with this part of the code, but generally, the answer to this question is « lack of manpower, but if you volunteer to implement it, we'll be glad to help you out and have you onboard. »

If anybody motivated to help us implement features reads these lines, the next step is to join us on IRC: irc.mozilla.org, channel #introduction .

I moved that bug to a place where someone who might know something about the matter might actually see it...

I have to say I rather like it that way but I guess I am not the target user group for such accessibility features.

Cool, thanks for all your hard work on FF dev tools!

One thing I could really use is something that helps me understand how Firefox treats TCP/TLS/SPDY connections. It would illustrate the benefit of using CDN and maybe, with enough instrumentation, would help me tune asset sharding.

I put some thoughts in the uservoice here: https://ffdevtools.uservoice.com/forums/246087-firefox-devel...

Inspect element is not working properly. Will this be fixed? http://www.youtube.com/watch?v=Q-ucHgQ2PvQ

I'm having the same issue. For now, you can click the first icon on the left of the devtools top bar and then click on the element you want to inspect.

Oh awesome. Never knew that even existed! Still though, I hope they fix inspect element on right click.

I would like to be able to copy the JSON received in the network tab. As it is now, I only get to see a tree-view and can't easily copy the full JSON as text.

+1 for this - also would love to be able to copy and paste an object that has been logged to console (this is only a problem if its a large object and its being 'abbreviated' inline within the console).

Just a basic request, but maybe in the developer edition you could default the '3d view' button being available in the dev panel. It took me a while to figure out how to get that cool (and distinguishing!) feature of FF. Thanks!

Edit: To enable 3d view you have to check a box in the settings menu in the Dev Panel, which makes a little 3d box icon appear if anyone else is wondering.

Wait, so this "Edition" will deliver the things that aren't even Beta? Is that only for development-only tools or also for features which will appear in "normal" Firefox?

I think I'd prefer to develop for the current state of my user base and not for some "maybe it will be so" target.

Can you please clarify what the "new rules" are?

The release process might help explain it: https://wiki.mozilla.org/RapidRelease or, if you're familiar with Chrome's stable / beta / dev / canary channels, it's largely the same model.

As far as fundamental web platform features are concerned, the Developer Edition is a normal pre-Beta channel. It's primarily that more willing to promote new tooling up from Nightly into the DevEdition or to set different default preferences, for instance.

I see, the "new rules" are easiest to summarize as one more "let's do it like Chrome" step.

No, that's not the "new rules", that's the "rules that have been in place forever, but if you are familiar with Chrome, these are the same." The new rules is that Developer Edition takes place of Aurora in that scheme.

Your "in place forever" conflicts with the comment to which I have asked for an explanation what the new rules are:

callahad:

"5. We have a new channel, which new rules." (sic)

Note that the Developer Edition is definitely new (1), and callahad also explains in his reply where it is positioned:

"As far as fundamental web platform features are concerned, the Developer Edition is a normal pre-Beta channel. It's primarily that more willing to promote new tooling up from Nightly into the DevEdition or to set different default preferences, for instance."

1) https://hacks.mozilla.org/2014/11/mozilla-introduces-the-fir...

We've done that frequently with the Aurora channel too, so in terms of release management rules, it's just a new name and focus for an existing channel.

Does it mean

Developer Edition == Aurora + different default settings + additional tools?

Or, what are the exact differences between Aurora and Developer Edition?

Yeah, pretty much. "Developer Edition" is the new name for the Aurora channel. There is no more "Aurora."

(Well, almost. The "Developer Edition" stuff is desktop-only for now, so the alpha-branch builds for Android are still branded as "Aurora." But Aurora for Andoid and Dev. Edition for desktop are built from the exact same source code.)

These aren't new rules; this has been the Firefox release process since Firefox 5 was released (3.5 years ago).

Good software projects aren't afraid to borrow features and practices that are working elsewhere.

It seems like they are referring to UI tools, not new HTML5 specs. Also, you can still debug with the other versions of FireFox.

I would love the ability to easily spin up multiple profiles at one time. Having the separate profile for Dev Edition should help, but sometimes I want a few others as well (depending on the task at hand).

Ideally, It'd be best to be able to open a new tab inside of a different profile and just be able to tab back and forth between the different profiles.

If you're running from the command line, you can use the `--ProfileManager` option to create new profiles, and then you can start separate browser instances with `-P <profile> --no-remote`.

> What tools do you need?

A better profiler, chrome flamechart is probably the best out there, it would be really nice to have the same for Firefox. Also allowing to operate in "count every call mode" and "sampling" (with control over sampling)

The ability to save the current state of cookies under a given name for loading later.

Having different named profiles for remembered users/passwords for a given site. Chrome can do this but I've never cared for it's interface that much.

Great information here. Please paste your comment here onto the web page for the Developer Edition. I got the impression from the official page that it was just for Web IDE and the dev tools Firefox already had.

It'd be great to be able to post feedback to the UserVoice channel, or anything else, from a dialog in the devtools. That way devs wont forget their great idea while they finish their new neat feature.

Since it's named WebIDE, what's your plans for it in future?

The WebIDE is currently pretty targeted at mobile web apps, especially on Firefox OS. We want it to be a more generally applicable tool for authoring web content.

The Tools Adapter that lets you debug Chrome/Android or Safari/iOS tabs from the WebIDE is a first step in that direction.

Would like multiple profiles in sync. e.g. a Work profile, a Home profile, maybe a mobile.

Some things belong just at work or just at home.

Some things aren't ever accessed on mobile.

Drag and drop nodes in the Inspector like Chrome does.

On HTTPS where the warning triangle comes up due to mixed content, tell us what the insecure resources were.

One request. I think it would be great if you were able to view the `&nbsp;` symbol in the Inspector!

In the "Responsive Design Mode" you should be able to see the size in ems.

As a longtime fan of the dark theme in the Firefox devtools, I'm enamored by the new theme of the developer edition. But you really should document how to turn it off for the people who don't like it. :)

EDIT: Ah, I see there's a link to restore the theme at the bottom of the welcome page.

Where exactly? I can't find it anywhere on this page https://developer.mozilla.org/en-US/Firefox/Developer_Editio...

EDIT: Aha, https://news.ycombinator.com/item?id=8584207

> 4. And, for all of you who hated Australis, a compact theme with square tabs.

Right, because that's totally the problem with Australis. Nothing to do with screwing up customization or the general theme, treating users like idiots etc. It's the rounded tabs!

Try vertical tabs: https://github.com/darrinhenein/VerticalTabs

They are imho much more useful on todays widescreen displays than normal tabs.

I wish the same thing existed for Chrome, but I've been unable to find anything remotely useful.

> 4. And, for all of you who hated Australis, a compact theme with square tabs.

Seriously, there has to be a better reason than that for square tabs. If there isn't, I question the usefulness of doing so.

built-in "firecookie" would be great addon.

+1 for Firecookie, super convenient to read and modify cookies on a site-by-site basis and one of the few reasons I still have Firebug installed albeit I always dread how much slower it is vs. the built-in developer tools.

A native terminal right in the browser.

CSS Media emulation like in Chrome.

Correct me if I'm wrong, but that feature is still not included even though there are feature requests for it. I am interested in it in order to emulate print.css . I'm sure it's not the highest priority.

You have print preview. No easy way to inspect/debug in it, though.

Light theme please.

There are "light" and "dark" themes in the Developer Tools options pane. Click the "gear" icon near the top right of the toolbox:

https://pbs.twimg.com/media/B2Fj8vbCUAMfjwj.png

Changing the DevTools theme changes the whole browser's theme too.

http://i.imgur.com/NJzTpG9.png