What I intend to work on for the Firefox 38 cycle
The Mozilla Corporation as a whole has been investing in a deliberate 2015 planning process, and some teams, in particular Cloud Services, have done a fantastic job of circulating their first quarter goals. I really applaud their efforts to be transparent, so I figured I would mimic them (the sincerest form of flattery and all that).
I was quite deliberate when choosing my Firefox 36 cycle goals, and then fell off the wagon for the 37 cycle. I found writing my goals for the 36 cycle personally helpful, but I only shared them with my direct supervisor (@mfinkle). One way that I surfaced them more broadly was that I included my goals as top-level items in my section of the weekly team meeting wiki page and updated my status over time.
In the spirit of transparency, and because I find knowing what my colleagues are building interesting, here’s what I anticipate working on for the reminder of the 37 cycle and the 38 cycle.
End of the Firefox for Android 37 cycle
I have been pushing the Firefox for Android work that will migrate Old Sync users to Firefox Accounts. The work is tracked by meta Bug migratesyncandroid.
I’ve landed the Firefox Accounts client-side UI code that prompts the user to finish migrating by logging in (Bug 1098667). I’ve landed the Old Sync code that recognizes if another device in the same device constellation has migrated and uploaded a migration sentinel (Bug 1091189).
The final piece of functionality is to message Old Sync users who have not migrated (Bug 895526). We expect this set to be small, since all Android Old Sync users needed a Desktop Old Sync device in order to pair their Android device, and those users are certainly going to be convinced by our Desktop messaging. We hope. This messaging only needs to be on the release channel before we start deprecating the Old Sync server farm, which is some number of releases after the start of migration messaging (Firefox 37).
There’s an open request from rnewman for some tracking of the Android-side migration process, be it FHR, telemetry, or whatever. I intend to investigate this but I haven’t committed to it yet.
Sometime in the far future, we can rip out the existing Android Sync code (tracked by meta Bug 957845).
Firefox for Android 38 cycle
We intend to expose our first Firefox Account attached service (Reading List) on Firefox for Android in the 38 cycle. The auth layer will be FxA OAuth. I’ve written some of the OAuth code that we’ll use; Bug 1117829 tracks rehabilitating the old code and adding the Android Account authenticator to it. This is a hard blocker for the Reading List service, so it’s a high priority for me. (But there’s no particular reason another developer couldn’t pick it up.)
We have ongoing build system battles to fight and continual feature and improvement requests. Solidifying mach bootstrap for mobile/android provides outsize value relative to my time invested. I will try to maintain and incrementally improve the IntelliJ configuration that I have glued together, but really pushing the Gradle/IntelliJ integration forward is not going to happen in the 38 cycle. It is my opinion that investing effort into the build system to use new Google-provided features (split Google Play services, shrinkResources, etc) is a bad use of our time. We should instead put the effort into transitioning our build to Gradle (or a competitor) and get these incremental features cheaply. Given this assessment, I do not expect to spend time improving our APK size this cycle.
Firefox for iOS 38 cycle
I’ll be building as much of the Firefox Accounts front-end and back-end as I can get done for Firefox for iOS. This is a soup-to-nuts affair, roughly tracked by meta Bug 1092561.
The first order of business is to decide between a native UI for signing in and signing up or whether to host this UI on the web, using a hybrid jelly-doughnut approach. We built a native UI for Firefox for Android, but we’ve used a hosted web UI in Firefox for Desktop. Both work; both have advantages and disadvantages. I’ll be evaluating and making a recommendation for which approach to pursue in the first weeks of the 38 cycle.
Concurrently, I’ll be writing the HTTP clients and token-passing plumbing required to keep a configured Firefox Account in a good state and prepare the client to Sync. The abstractions we built for this in Firefox for Android have weathered very well; this will be a "judicious re-implementation" of the same ideas into Swift.
Conclusion
That’s what I’m going to be doing. But I’m always trying to make things better for contributors and I love to mentor tickets. Get involved with Firefox for Android or help build and test Firefox for iOS.
Discussion is best conducted on the mobile-firefox-dev mailing list and I’m nalexander on irc.mozilla.org and @ncalexander on Twitter.
Notes
About Nick Alexander
Mathematician. Mozillian. Runner. Master of Disguise.
