Firefox Developer Tools for Mobile Devices
November 13, 2012
The Firefox Developer Tools team is working hard to improve the lives of developers targeting Firefox on Android and Firefox OS. We’ve made a lot of progress: our debugger was built with remote protocol support from the beginning, and our web console was recently ported. Others have good posts describing this stuff, so I won’t dwell on it here.
But we have a long way to go. Here are some of the challenges we have ahead of us. Some of them are close to finished, some haven’t been started yet. If you want to pitch in on any of these, come find us on irc.mozilla.org’s #devtools channel.
Developer Tools Window
As I described in my post about tools for browser developers, some of what we have to fix are relatively mundane UX problems: our tools are hosted in-tab and have nothing to tie them together when looking at a remote target. We have one-off solutions for all the remotable tools right now – attaching your JS debugger and your web console are two different actions.
The Developer Tools Window project and its associated Target API will tie this up. There will be one place to specify a debuggee, and all tools that are remote-protocol ready will share a window and connection information. There’s also work to be done to make the different tools share a single debugging connection.
This project is well underway. The first milestone of this project is aimed at Firefox 20.
Content Process Support
Firefox OS uses process separation for applications, and the debugging server doesn’t support that. For now you can get work done by disabling process separation for Firefox OS, but we’d like to do better than that. We don’t think this will require significant protocol changes, but it will take some changes. Each of the content processes will need to host a debugging protocol server. The toplevel debugging server will need to route messages to the right content process. We’re discussing our implementation plan in bug 797627.
Profiler Protocol Improvements
The SPS profiler works against remote debugging targets, but easily runs in to memory constraints. Some of the blame here is on our remote protocol implementation: it doesn’t make it easy to send large amounts of data efficiently. Work is underway to define and implement a data blob extension to the remote protocol. The current protocol change proposal is here and is being discussed here.
Probably the largest piece of remaining work is getting the page inspector working over the remote protocol. The inspector is a somewhat large piece of functionality, encompassing:
- The navigation breadcrumbs
- The markup view
- The style views: rule view, computed view, and layout view
- The highlighter veil
All of these currently assume direct, synchronous access to the DOM (boo). Porting them is going to take some work, not all of which is entirely straightforward. This is going to be a big focus of the inspector team over the next few months. We’ll keep you up to date with our progress.
The Other Tools
There are a few other tools that would be great to port to the remote debugging protocol, like the style editor and the scratchpad. These are a lower priority for the team at the moment, but porting them to the remote protocol should be relatively straightforward. If you’re interested in helping out, find us on #devtools.
Great tool support for Firefox for Android/Firefox OS is one of the highest priorities on the Developer Tools team right now. Some of our core tools already work (the debugger and the web console), some are coming soon (SPS profiler), and we’re working hard on the rest.