campd

Like pcwalton said, we already use Gecko to render the UI. But we're using a less well-optimized, less well-maintained corner of Gecko.

Improving performance is an explicit goal of this work.

It's not not the first step.

That's not the primary driver of this plan. But it might be a happy side effect.

Servo is still in early stages, we aren't making product plans around it.

console.mihai() is in at least Nightly and Developer Edition so far.

It doesn't tab complete, and it's not available from content. Mihai didn't like too much attention ;)

This is a thing, on Firefox Nightly or Developer Edition.

And that work is key to the stuff we're doing. Thanks again, Chrome folks!

Integration with external editors/IDEs is a very important part of this project. A lot of what WebIDE brings to the party on top of normal editing is device/simulator management as well as the usual Developer Tools inspection and debugging.

So there are three layers of compatibility we expect to see with external IDEs:

0) No integration - Open a WebIDE window with editing turned off and use it (or command line tools that drive it) to manage device connections/pushing/etc. 1) Simple integration - Most of the basic device connection management will be available through command line tools, it should be incredibly easy to drive that through editor/IDE configuration. 2) The whole nine yards: Speak a remote debugging protocol and get full control over the debuggee.

As far as the whole nine yards, you can either use remotedebug's protocol and proxies (although development seems to have trailed off there?), speak each browser's protocol natively, or maybe down the road the protocol abstraction we're working on at Mozilla.

Resource usage of devtools that aren't running is near zero (there's a tiny bit of overhead to manage the menu items to launch it).

Download size is affected, although for larger parts of the developer tools (things like firefox OS simulators and adb) we use addons. We think that tradeoff is worth the benefits - users can look under the hood (even if most of them won't), developers have quick and easy access to tools, and we don't have to worry about things like version mismatch/testing concerns/etc.

The team here is dedicated to developer tools full-time. We have no intention of slowing down.

https://hacks.mozilla.org/2013/10/firefox-developer-tools-an... has the current description of that relationship.

> To be quite frank, this is really ridiculous to me. Why in heck are there TWO separate developer tools for one browser that are both in-house?

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

Jan Odvarko, the current maintainer of Firebug, is on our team. He's currently the only Mozilla employee dedicated to the Firebug project. He's joined by a healthy community (you can follow the project at https://github.com/firebug/firebug).

Jan and the Firebug team are actively improving Firebug - not just maintaining it so it doesn't break. The bulk of the Mozilla staff (and our volunteer community) is focused on the built-in tools, but a lot of it ultimately benefits the Firebug team.

The standby example is our debugger. A lot of the performance and stability problems Firebug has are a symptom of the old Spidermonkey debugging API (JSD). The developer tools and Spidermonkey team built a new debugging API[1] along with a remote debugging server. The Firebug team is currently working to update Firebug to the new debugging API/remote server.

Most of our work is dedicated to the built-in developer tools. But those also support Firebug development.

[1] https://wiki.mozilla.org/Debugger

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

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

You haven't been reading your mail, paul!

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