Hi! Just a heads up that folks from the dev tools team will be monitoring this thread and are on-hand to answer questions. We'll try not to thread sit too much. :) In brief, the Developer Edition is a new release channel for Firefox, replacing Aurora (our pre-Beta channel). Everything else about the release cadence is the same.
There are four major new features here:
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.
2. Side-by-side profiles. The Developer Edition defaults to a profile named `dev-edition-default`, which makes it easier to run Developer Edition at the same time as a normal release version of Firefox. You don't have to deal with the profile switcher each time.
3. Developer-friendly defaults. Developer Edition ships with things like remote debugging and browser-chrome debugging enabled by default.
4. And, for all of you who hated Australis, a compact theme with square tabs.
But those are just consequences of the single biggest change:
5. We have a new channel, which new rules. And we want to use it to build the best possible browser for web developers. We can ship new tools that aren't yet ready for the Beta channel, and we can change the browser's appearance and defaults specifically for web developers.
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.
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).
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).
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.
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.
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?
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.
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!
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 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 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.
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.
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.
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)
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.
> 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.:
(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.
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.
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.
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?
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.
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 .
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'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.
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.
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.
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."
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.
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.)
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`.
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)
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.
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.
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.
> 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!
+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.
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.
There are four major new features here:
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.
2. Side-by-side profiles. The Developer Edition defaults to a profile named `dev-edition-default`, which makes it easier to run Developer Edition at the same time as a normal release version of Firefox. You don't have to deal with the profile switcher each time.
3. Developer-friendly defaults. Developer Edition ships with things like remote debugging and browser-chrome debugging enabled by default.
4. And, for all of you who hated Australis, a compact theme with square tabs.
But those are just consequences of the single biggest change:
5. We have a new channel, which new rules. And we want to use it to build the best possible browser for web developers. We can ship new tools that aren't yet ready for the Beta channel, and we can change the browser's appearance and defaults specifically for web developers.
We'll be watching this thread during launch, but you can always submit feature requests on UserVoice. The right people will see them: https://ffdevtools.uservoice.com/forums/246087-firefox-devel...
This isn't a finished product. It's an invitation.
What tools do you need?