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.

If that were to happen, how big an impact would that have on Firefox OS development? I admittedly don't understand the project too well, but they had to port Gecko to work in Gonk right? Would there be significant overhead getting Servo working under Gonk?

A few things:

- currently browser.html runs on top of a gecko runtime (called graphene) which is based on the one we use for FirefoxOS.

- getting gecko to work on gonk is not different from adding support for other platforms like linux/mac/windows/android. Basically you need to provide implementation for low level windowing and input events. On non-posix systems there's a bit more to do in the nspr library, but that's not the case for gonk.

- we already have a port of servo that runs on gonk.

FirefoxOS has been using a 100% html UI since about 4 years, so it has been leading the way here.

Very cool, thanks for the information. I'm obviously more ignorant of Mozilla projects than I even thought.

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://hackertimes.com/item?id=5326873 - let me know if I can clarify further.

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