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.
I think it really should not prompt to be the default browser when you launch it (and maybe never show this prompt like Chrome Canary).
A colleague had a weird race condition (I guess) with this prompt + the "how-to" overlays and Firefox Developer Edition stopped responding to clicks 3 seconds after launching it…
Kudos for using a different profile than the classic Firefox/Nightly :)
At installation, there's also a checkbox to set it as the default browser, and it's pre-checked. I think, even full-time web developers wouldn't want to set it as default, and Mozilla should retain themselves here.
FWIW I'm using it as my default browser. Maybe it's just me, but a developer browser is more than just for debugging websites. I really like the way they've customised certain things to be power-user-friendly (e.g. no patronising "Show Advanced Settings" buttons)
I've always used the bleeding edge Aurora and Chrome, have never had substantial problems with that.
Angelina Fabbro introduced this tool on a Web developer conference in Hungary [1] a couple of days ago. Here is a short summary as far as I can recall:
- a couple of decades ago alert() was used by pretty much everybody for debugging, even her :) [2]
- most of the developers use(d|s) Chrome for web development
- this is the first serious dedicated tool for web developers which is not just a browser plugin
you don't have to close a million tabs during development
- they worked together with the Firebug team, there will be no duplicate functionality in the plugin and the browser
- seamless Firebug integration. You can switch between Firebug and default theme, it will not break your workflow
- NOT a new browser which you have to support, same engine as in Firefox, nothing new or special about it
- multiple profiles
- developer friendly default settings like enabled experimental CSS features, etc.
- UX improvements for changing config, like switches for features, so you don't have to dig about:config
- support debugging Android, even the iOS simulator or attached device real time
- the dev team is really looking for feedback, they want to make web developers' life easier and put in features based on feedback
- there will be no built in REST API tester tool like Postman REST Client at first, but I was not the first dev who asked for it, so they will consider it for sure
- it will replace the firefox dev channel
- themeable
- much stable than nightly, but you can try out experimental browser features, so it's a good compromise
In case it's already light, but looks a bit unclean then you might have set it to Firebug theme which apparently comes with Firebug. For some reason this was the default for me.
Doesn't look like I can debug websockets? Chrome's network tab allows you to see websocket frames, but you have to navigate away from it and back to it again to refresh it -- which is a pain.
I'm not seeing where/how to view frames in the network tab here, but perhaps I missed it?
Websockets have been around for years, and are becoming normal in day to day internet. Mozilla was one of the biggest promotors. I'm using them more and more.
It just doesn't make sense that I can not debug websockets in Firefox.
Exciting stuff! If you're already on Aurora, when you auto-update to developer edition, you'll switch over to the new dev profile and your bookmarks and settings will be gone. You can get at those by opening the profile manager and switching back to the default profile, or by using a stable version of Firefox.
In my case this was unnecessary and the update to Developer Edition preserved everything. Might have something to do with the fact that I already make use of multiple profiles.
EDIT: Wait! The default profile was used when clicking "Restart" from within the updater, but when closing and reopening the browser manually it did indeed start up with a new profile.
You don't need to manually fiddle with profiles, just untick "Allow Firefox Developer Edition and Firefox to run at the same time" in settings to go back to your old profile rather than the segregated one
If you don't like setting up your Browser again, you can go to about:preferences#general and uncheck Allow Firefox Developer Edition and Firefox to run at the same time
This will cause Firefox Dev to use the Firefox profile with all your settings and Addons.
First, using a browser which includes fancy experimental features might result in the page looking or behaving differently in the users' (stable) browsers. I see this as kind of risky, that's why I usually develop against stable browsers and use the nightly/aurora for personal browsing.
Second, having browser-chrome debugging on by default is not very helpful for web developers, it actually gets in the way. It might be more useful to activate these features in the nightly channel, where people are more actively debugging the browser itself.
Third, if this channel is the intended one for developers, why ship the development tools with the stable release?
There are new features (tools adapter, side-by-side profiles, compact theme, developer-friendly default preferences).
But what's larger than any of that is the change in Mozilla's policy / conception of the pre-Beta channel. This is very much a v0 offering, of course, but it's an indication that we genuinely want to take developer feedback seriously and co-design this with you.
We've given ourselves the freedom to ship tools into Developer Edition that aren't yet ready for Beta. We're willing to change the browser's appearance and defaults specifically for a web developer audience.
If you have feature requests, please submit (or upvote) them on UserVoice: https://ffdevtools.uservoice.com/forums/246087-firefox-devel... the DevTools team actively monitors and responds to requests there. Your ideas will get seen, and now, we have even more freedom to actually execute on them.
Hm, so if I develop on this I will still have to test in the regular stable Firefox release, that seems unfortunate.
Having more tools in a developer edition compared to the regular version of the browser seems fine, but at least for me I would like run it with the same rendering engine my users are likely to run.
I don't understand the problem. Responsible web developers test across multiple browsers anyway, and this edition allows you to hook the developer edition tools into other browsers.
I think the idea is Nightly/Aurora/Beta builds aren't just for Firefox Developers but Web Developers too and it would be beneficial if more web developers used this branch for development.
Of course, don't forget to test in stable.
Another thing I can think of is rather than prefixing CSS/JS, experimental features could always be enabled in the developer builds and it then kicks into life on stable when it's ready for the general public. Right now you need to change various flags for that to happen.
It has some addons installed by default (ADB Helper, Firefox Developer Tools Adapter and Web IDE is turned on by default).
I like the Firefox Developer tools but it feels like this one isn't that different from a nightly build with some plugins.
I noticed there's a checkbox for "make FirefoxDeveloperEdition my default browser," is that just a vestigial thing from the regular FF installer, or is it actually safe for me to use FFDE as my regular browser?
This page says "We'll include experimental tools that aren't yet ready to ride the trains to release." But https://hacks.mozilla.org/2014/11/mozilla-introduces-the-fir... says "It’s a stable developer browser which is not only a powerful authoring tool but also robust enough for everyday browsing." So maybe the browser part is stable, but the tools are experimental? And it uses a different profile by default, so a broken plugin can't step on your history, bookmarks etc.
From other comments, it's ~aurora (pre-beta) but it may get new tools from nightly much sooner, very soon after nightly and long before they move to beta.
So the browser itself should be pretty stable, but the devtools may not be.
It may also gets developer-specific UI customisations which never get merged into the beta/release channels.
The developer tools are the only thing stopping me from switching back to FF from Chrome.
The tooling in Firefox does seem to be improving rapidly (kudos to the devs for that, I'm not trying to trivialise the hard work that they've been putting in, by any means), but there are still several basic(?) features missing from the script debugger. Calling this a "developer edition" is IMO a misnomer until you can reasonably use it to develop pages/sites/applications - currently every other major "not-for-developer edition" browser already gives you almost everything this does, and in some areas quite a bit more.
What would make it a developer browser to me:
* Folder grouping on resources
* Allowing webide or the script web tools tab to work with local folders (Chrome workspace equivalent)
* Dynamic updates to scripts (Chrome workspace/dev tools equivalent)
* The ability to open and/or display more than 1 script at a time. Tabs in developer tools should operate like browser tabs (orderable, poppable etc)
I hope that this isn't just a re-branding exercise - the video, site and fanfare make it sound like Mozilla's aiming to make something great for developers (not to mention that the FF tools are headed in the right direction), but the first release and associated posts/comments seem to indicate that it's essentially a nicer packaging of what used to be aurora.
This is largely the codebase that used to be Aurora. However, it's not a "nicer packaging", it's a complete change of direction for Aurora.
Now regarding your needs, the devtools teams is watching this thread, but just in case they miss your message, you might be better off making your requirements known here: https://ffdevtools.uservoice.com/
I've always used Chrome since I started developing, and I liked their Developer Tools. Since I switched to Firefox four months ago I've had a lot of trouble with FF DevTools:
* debugging is too slow (or my computer is weak, but Chrome DevTools run smoothly);
* debugging is very slow;
* the debugger has some unpredictable behavior, like stopping at all calls that lead to some error, when I expected it to stop at the error properly.
For some reason, I convinced myself that Valence was going to allow us to change the engine to Webkit and Trident as well as Gecko. While testing iOS and Android is awesome, this would have been downright incredible.
Not to be the guy to bring this up again, but if this is targeted for development why are sessions still limited to consuming 2GB of memory? Why is nightly still the only branch with 64bit builds?
You'd be amazed how small a difference 64-bit makes in browsers. And in most apps for that matter.
Source: I package apps for portable use for PortableApps.com. We analyze many of our apps for whether the trade-off of a size increase including both the 32-bit and 64-bit versions of an app is outweighed by the performance or stability advantages of the 64-bit version of a given app. Including the 64-bit version is worth it in VERY few instances. Even then, it won't help most users.
Editing JavaScript functions on the fly is the main feature I hear devs complain about Firefox devtools (anecdotal). Chrome allows you to edit the JavaScript in the script tag which is amazingly intuitive. I realize editing variable values is possible while debugging, there are console commands and Scratchpad is neat, but it's not the same. Being able to edit the JS directly in the tab, save and see the changes on the page is a huge time saver.
Wow, so Firefox's Preferences panel is being redesigned, or is this a "Developer Edition" thing? I like it - hopefully they'll also add searching capabilities. Yes, like in Chrome, that was a good design choice.
On the theme, I personally don't like dark themes for my browser. But I like that this theme is space efficient, so I hope to see an equivalent for the stable Firefox, as I for one would use it, but please make it light instead of dark :)
I do hope to see Electrolysis get some love. It's available in Nightly, but not in this developer preview. From what I understand, the next version (36) is the first version in which Electrolysis starts being moved between channels.
The preference panel redesign has been a long time coming (years, it feels like), and yes it does look fantastic compared to the prior tabbed popup window.
Also, you can get a light version of the same compact theme by opening the devtools (Ctrl+Shift+I), clicking the gear in the upper-right, and selecting the "Light theme" radio button. It looks great!
Thanks! I've essentially been using a developer profile in Firefox for some time, but the OSX dock doesn't play well with profiles, so this makes things a lot easier.
Have you tried the profiler in the devtools? If there's anything that you think is missing, don't hesitate to mention it here: https://ffdevtools.uservoice.com
I managed to get this when downloading Firefox Aurora over the weekend while reinstalling my OS. I wasn't expecting the dark UI when I opened it. I personally found it a little garish and I couldn't immediately see a way to turn it off. Anyone know if there's a way to switch it back?
You can change the theme in the customization menu (there's a theme drop down on the bottom left), or by using the about:addons and going to "appearance"
Mozilla doesn't own this PPA, it's third party. Chris Coulson, the maintainer had mentioned he doesn't have the time to maintain this anymore as I recall. Suggest just getting Aurora on aurora.mozilla.org
Why all the negativity? It's an early release and a great idea, not to mention they're actively soliciting feedback and answering questions in the thread. Thanks for this, Mozilla!
Just downloaded it and gave it a try. I've been using chrome for development for a long time and I must say this looks really good and I'd really like to switch cause I like the firefox image/mission much more. However I'm experiencing some problems editing my .less files directly from the browser. They don't show up in the list of style sheet files, even though I have "show original sources" checked. Where do I submit an issue for this?
Unfortunately, I can't acces HackerNews with this new browser. Just a heads up to the team, liking the browser so far!
Secure Connection Failed
An error occurred during a connection to news.ycombinator.com. The OCSP response contains out-of-date information. (Error code: sec_error_ocsp_old_response)
The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
Please contact the website owners to inform them of this problem.
I thought it was a bug in my install. You can't even close the top-most tour window, because of the covered prompt.
Apparently, the wide button where all the text is hidden sets Firefox as default browser. I accidentally clicked it when trying to give the prompt focus. Thankfully, OS X asked me to confirm that I wanted to do this.
I'm not sure what's worse, purposefully tricking me into setting default browser by hiding the text of the prompt, or starting with such a buggy first-run experience!
That's really cool. Big thanks to the team behind this!
The biggest feature for me was that it can run alongside the normal version of Firefox so I could tinker with it without disrupting day-to-day workflow.
Not like it's a big deal or anything, but it still shows a warning when you enter about:config even though it's targeted at devs :)
It's an experiment with WebRTC -- you can start peer-to-peer voice/video calls with it. No accounts or special software needed. Just modern browsers. :)
The only issue I have with the inspector tools in its current guise, is the fact you can't open an XHR request logged in the console in the network tab so you can view the nicer layout of parameters and stuff.
Which is really annoying and the main reason I stick with firebug.
I don't know if this belongs here, but my Aurora installation automatically replaced itself with Developer Edition, which would be fine if it did not also delete all history, bookmarks, saved passwords, plugins etc. Is there anyway to get that stuff back?
I honestly thought that Valence was a way to view renderings of the desktop versions of Chrome, Safari, Opera and IE within Firefox. Anyway, congratulations at the team at Mozilla for creating this. Can't wait to try the WebIDE for editing remote code.
Looking forward to see how much of a 'Web IDE' can actually be achieved. I continually feel like I should be making things in the browser, but there's no adequate editor still.
Please tell me there is a feature like in chrome when you do shift-esc. I really would like to see CPU usages in a browser a memory breakdown like about:memory
Is it possible to create regular static websites using the webIDE? I couldn't find anything but it seems like everything is there to be able to do this.
Why the black theme? I think that as developers/designers we should use environments which closely resemble that of the users we're creating for. Colors influence people's emotions, as well as how they perceive a specific design. Even if you are a designer, you're still a user; a user of your own creations. And when you change the mindset to that of a user, why not change the environment as well?
I suspect the motivation is to make it easy to distinguish the developer edition from the normal browser when you're running them side-by-side. There's a light theme that you can switch to from within the developer tools panel.
I agree, although obviously it needs to be smart about how widely it disables. There was an addon available but it got removed from addons.mozilla.org I assume because it violated security. The developer still hosts the addon though.
I mean end users. I'd love to develop using one of these, but if 80% of the rest of the world can't see what I've done the way I see it when I do it, there's no real benefit here.
Got it. The "when I do it" part is the tricky one. They will see things the way you see it when Google/Mozilla/MS release the new version. I understand that might be an issue but releases have been moving much faster lately. There is hope!
WebIDE still feels like a toy for now. Very little customization for the text editor for now. Also the browser has a shiny new dark theme but the text editor doesn't seem to support themes (and has a light theme as default).
I have been using it for a few weeks, and I find it extremely useful. Not the editor itself (I'm currently test-driving Atom), but the ability to quickly send my app to all my devices and emulators, and remote debug it.
AIUI, it replaces the Aurora channel in the Firefox release schedule (which historically went Nightly -> Aurora -> Beta -> Release). In addition, whereas previously all experimental browser features would be held back in Nightly until fully-baked, this new channel will receive experimental developer tools from Nightly while still holding back all experimental non-developer features, so that the browsing experience itself isn't affected.
(Also, it has a darker and more compact visual theme by default that echoes that of the built-in devtools.)
I think you're probably reading too much into the 'free' bit - it says the same on the download for the normal Firefox. If anything, it's a play on it being "free as in freedom".
They don't seem to have anything akin to Chrome's mobile emulator. They have "Responsive Design View" but it is much less feature complete than Chrome's mobile emulator, only seems to set a resolution.
If you launch WebIDE, you'll see that it can install Firefox OS emulators. I think it can connect with an Android emulator, too, but I haven't checked.
Will this version survive months of usage with multiple open tabs without performance deteriorating massively like the regular firefox? I left FF after my 10th profile reset / reinstall to get back to "normal" performance.
I'm kind of hoping that Eloctrolysis never becomes main-line. Right now I have a browser that isolates misbehaving web pages (Chrome) and a browser that allows me to have a million open tabs simultaneously (Firefox).
If I could only choose one I'd choose the browser that isolates misbehaving web pages but both is even better.
Electrolysis will initially only have two processes: one for chrome (i.e. UI) and one for web content. More content processes may be used in the future, but we will move very slowly and carefully in that direction. I consider the several-hundred-tabs-open use case to be an important one, and will do my best to ensure it continues to work in the future.
I personally think the number of browser processes shouldn't exceed the number of tabs because you won't get any responsiveness improvements beyond that, and it'll keep the memory usage reasonably low.
Chrome doesn't isolate misbehaving webpages. The pages are grouped together under a few parent processes. The more pages you have open, the larger the group and a page crash will take out many more pages at the same time.
Originally the idea was for every page to be isolated but that didn't scale so well.
In my experience this kind of response was typical a few years ago, but Firefox's performance has improved so much over the past few years that complaints are much less frequent, and when they do occur there is now typically quite a bit of pushback.
Electrolysis will help with some performance problems, but not all.
I haven't followed (and probably don't know nearly enough anyway) details of e10s, but their claim is contrary to your view:
> Performance would improve because the browser UI would not be affected by poor performance of content code (be it layout or JavaScript). Also, content processes could be isolated from each other, which would have similar security and performance benefits.
This is almost certainly caused by an extension. If you use Firefox with few or no extensions (e.g. 1Password doesn't cause problems) you'll find this doesn't happen.
Although badly-written extensions do cause a lot of problems, please don't assume they cause every problem. It's not always true and comments like these give the impression that Firefox developers simply pass the buck every time somebody complains.
Having said that, if someone is experiencing bad performance and they do have extensions enabled, temporarily disabling them is a good diagnostic step. If performance improves, it's clear that it's an extension at fault, and then bisection can be used to work out which one. Otherwise, it's clearly a Firefox problem and a bug report (bugzilla.mozilla.org) would be very helpful!
Isolating a problem is always a good idea – but scope is also a factor: the original claim that Firefox becomes slow simply from normal usage would require everyone at Mozilla not to have noticed during a multi-year performance push. I've never worked there but that seems unlikely.
Pretty much. I never close Firefox on my laptop, and haven't seen any performance degradation for over a year now.
Chrome on the other side, starts degrading my entire system's performance forcing it to hit swap memory the second the string of tabs on my top bar threatens to stretch across the screen. No need to wait for 'months of use without closing'...
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?