Summary

Firefox for Android (fennec) is arguably the most feature-rich browser available in the market however, slow startup responsiveness and performance have not been speedy enough for successful market adoption nor to generate amount customer love Firefox is accustomed to.

The advent of a prototype built with single-process architecture with the front-end written in Java creates new possibilities for Mozilla to make a faster, more responsive browser. There was a meeting in Toronto during the mobile workweek to plan what is needed to ship this new mobile browser to market.

Attendees: Damon Sicore, Mark Crandon, Jay Sullivan, Johnathan Nightingale, JP Rosevear, Mark Finkle, Doug Turner, Brad Lassey, Madhava Enros, Clint Talbert, Christian Legnitto, Jaclyn Fu, Grace Jimenez, Sheila Mooney, Martin Best, Erin Lancaster.

Schedule

Q4

• Dec 2011: Feature Complete

Q1

• Jan 30 2012: Beta
• Feb 27 2012: Public Announcement at Mobile World Congress
• March 30 2012: Final Release

Release Criteria

Tent Poles

• Security: maintain parity with the currently shipping version of Firefox Mobile
• Stability: achieve parity with the currently shipping version of Firefox Mobile. Ratio of number ADUs to number of weeks to be specified before 10/31/11.
• Performance: Raw Start should not exceed 200ms. Warm start with page load should stay within a certain % range of the built-in browser, and we should be faster than Opera. We will pinpoint the exact metric prior to 10/31/11.
  
• Memory Usage: Will stay conservative so that the browser is kept alive and supports swapping/round tripping from browser to apps.
• Responsiveness: Scrolling Panning, Zooming, and Frame Rate should meet or exceed customer expectations when compared to other mobile browsers. Numeric metrics and hardware targets to be determined prior to 10/31/11.
• Features and Design:Deliver all features with P1 and P2 priority and be opportunistic about improving Ux and UI design but not at the expense of performance and responsiveness.
• Be fabulous: Although this effort is about re-jigging for a fresh platform, we are on the lookout for differentiators. Jay will continue this orthogonal effort so as to not put the baseline plan at risk. Browser ID or Reading mode is a good candidate to get started with.

P0 Features

Required prior to cutover to Nightly

1. Tabs
2. Reload
3. Session History
4. App Updates
5. New Layout Manager

P1 Features

Needed prior to cutover to Beta, we need to decide at what level of UI polish customers will expect

1. Bugs Needed Faster Repaint After Zoom (stop reflow from double tap, dbaron)
   
2. Viewport Support (Support for Mobile Versions of Websites) 
3. Awesome Bar
4. Tabbed Browsing Support & Improved Design
5. Set and Display Preferences
6. Password Manager (Form Fill)
7. Content Modal Dialog Prompt Support
8. Download Notification, Progress, and Launch
9. Native HTML5 Video Controls
10. Secure Page Indication 
11. History: Browsing and Bookmarking
12. Content Permission Prompts (i.e. Geolocation)
13. IME Support

P2 Features

We will not gate any milestones on the below

1. Visual Indicators for Previously Visited Links
2. Incremental Decompression
3. Telemetry for Mobile
4. Sharing
5. Site Security
6. Touch Events
7. Forward
8. [Clean up mobile XPCOM components]

Open Issues (P1 Level)

The below reflects topics and issues we are currently landing a plan for. Please do not consider this a plan of record.

Release Plan

• One of the more concrete things discussed was being good with labeling an aurora quality app on mobile, as "beta"
• We need to specify specific quality, performance, and stability criteria around the above
• If Fx10 for mobile is a "go", we will target Fx11 as the version for this Java UI release

Test Plans

• Need test cases and plans for functional, performance, and stability
• elancaster and smooney are on point for this

Sync

• Built-in browser in ICS has bookmarks and history sync built-in and it is really easy to set up.

• Sync in it's current phase isn't really usable. Passphrase: 20 characters long has and nobody can remember it; it isn't user-friendly to set-up. Jay does not want to ship with Sync unless it is easy to set up.

• Product vote is that Sync by default should not be encrypted if we add passwords, we want to lessen the number of characters

• Password sync is damn awesome in fennec; we don't want to lose it

• Will write to the system store for history and bookmarks. Tradeoff: We will want to keep the passwords private b/c system store does not have the most optimal password protection. This should get better in ICS.

• Proposal: Make sync an APK to be installed on any device; will support history for browsing, bookmarks, passwords, and possibly form history.

Places

• Highly migrated throughout the gecko; can't just enable/disable.
• Colorizing Visited Links is broken; instead of leveraging places, we can fix this.
• There is currently no reason to include Places into the startup pane

Extensibility

• We need to closely evaluate whether Add-ons will add a memory hit
• Add-on support is extremely important to us; thew plan is to start by supporting restart-less add-ons
• Jetpack support for mobile is interesting, though we are going to decouple from their schedule
• Fabrice to build out ad-block plus
• For v1, we will not support add-ons touching Fx UI
• It will be way easier to re-write add-ons for Java than it was for re-writing electrolysis
• We should help port over no-script they just finished and the have a ton of UI, openID just came online, too.

L10n

• We do not have a complete plan at this point.
• Smooney is driving the l10n requirements.

Layout Transform API

• Roc confirmed it is there & ready for us to develop with

Update Snippets

• RelEng needed to make sure it was generated
• Christian is on-point for this; taken care of as of 10/26

Ts Expanded

• Home Tab and Twitter Pages; this will be a weekly, manual test owned by Mobile QA (Naoki, Kevin, Aaron)

Video

• Flash: pre-honeycomb support is being worked on. Jay is following up.
• h.264, Jay is following up.

ARM v6 (p2)

• Our hardware targets do not include ARMv6 phones
• We need to do some things to make it run: turn off the jit, possible pix- stuff
• Does it run, how quickly can I make it run, when I do and if it is slow, how much work will it be to be less painful?
• Ted is on this; elancaster is getting him an ARMv6 phone

JS Optimization for ARM

• We need to connect with the JS team on whether there is any low-hanging fruit
• We need to get better with v8
• Damon is on point to circle back with dmandelin

Fx10 for mobile

• Will complete the cycle; we will get good platform testing for c2p
• When Fx10 moves to aurora, there will be the usual cost associated with the cut overs
• Agreed to do a Final go/no-go

Marketing

• We sign-off in October
• We need a go-to-market plan