The State of Firefox Mobile

1f461eee0b22011d0bccf4e882d9149f?s=47 Lucas Rocha
February 09, 2012

The State of Firefox Mobile

An overview of what the Firefox Mobile team has been working on and the future plans for Firefox Mobile (aka Fennec). Presented by Lucas Rocha and Chris Lord. The deck alternates between slides and speaker notes.

1f461eee0b22011d0bccf4e882d9149f?s=128

Lucas Rocha

February 09, 2012
Tweet

Transcript

  1. The State of Firefox Mobile

  2. Hi everyone, thanks for coming! We're here to talk about

    Firefox Mobile.
  3. Lucas Rocha lucasr@mozilla.com Chris Lord clord@mozilla.com

  4. I'm Lucas, this is Chris. We work on mobile team

    at Mozilla. Given that we don't have much time, we'll focus on the work we've been doing the new native UI for Firefox on Android.
  5. The web is going mobile Mozilla has to be mobile

  6. First, a bit of context. Why are we doing Firefox

    Mobile? Why is it important? As you know, a good part of our online interaction is happening through mobile devices these days. All market predictions point at a direction where most of the online access will be done from phones, tablets, etc. A big part of the online world is, of course, the Web and Mozilla should go where our the Web users are. So, it's not option, it's not nice-to-have product. Mozilla has to have a strong presence on the mobile space in order to stay relevant and be able to drive the open Web wherever it is.
  7. Firefox Mobile Firefox Sync Boot to Gecko Open Web Apps

    Pancake
  8. This is why we're doing all sorts of things on

    the mobile space now. Firefox Mobile is one of them. But there's also Sync, which is not mobile-only but has a strong mobile side to it. B2G and Open Web Apps are a big deal as well. Pancake will most likely have a strong mobile focus as well.
  9. Positive feedback • Great HTML5 support, fast JavaScript • Built-in

    Sync, innovative UI design
  10. Current Fennec (latest release being Firefox 10) has got some

    pretty positive feedback in areas like HTML5 support, JavaScript performance, the built-in Sync suppport, and our UI design that has actually inspired the UI of certain competitors.
  11. Current architecture • JavaScript + CSS + XUL are very

    portable • Code sharing with Desktop Firefox
  12. The current XUL-based architecture in Fennec has its advantages. e10s

    brings responsiveness, especially on multicore devices. XUL allows us to share code with desktop Firefox and could potentially allow us to quickly port to other mobile platforms. Addons support is natural due to the familiar platform.
  13. Negative feedback • No Flash support • Poor video support

  14. However, the current platform used in Fennec has its drawbacks.

    The current architecture makes flash very hard to support and makes it even harder to do video fast. While we have support for Flash on Gingerbread and older, you'll notice that the experience is quite poor.
  15. The top end-user complaint is...

  16. But when it comes to our current Firefox Mobile release,

    the top end-user complaint is pretty clear. Can you guess what this is?
  17. Performance

  18. Yes, Performance. Let us talk a bit more about what

    we mean by performance here.
  19. Slow startup • Up to 30 seconds! • libxul is...

    chunky • Gecko on critical path
  20. We're having some poor startup times on mid-range devices. libxul

    is a rather large library. This pretty much destroys startup time on devices with slow filesystems (e.g. Galaxy S). And because we use XUL for UI, the user can't really do anything until Gecko is up and running.Given that one of the main use cases for mobile browsers is to open links from other apps, we have to deliver a much better performance if we want to be competitive.
  21. Not responsive, slow • Rendering overhead with e10s • Reliance

    on Gecko's render performance • Lazy-loading components
  22. Not only we start slow but also we feel slow.

    e10s gives us the opportunity to split user interface from content rendering and increase responsiveness, but it comes with the overhead of having to communicate everything over IPC, and there are hard-to-overcome limitations on what you can share between processes on android, such as texture memory.
  23. Uses a lot of memory • Overhead of having two

    processes (e10s) • Frequent background killing
  24. There's also the increased memory use of having two quite

    heavy-weight processes running, meaning we frequently get background-killed and users have to endure are quite-slow start-up again.
  25. The Native UI • Remove Gecko from critical path •

    Use native Android toolkit • Gecko, of course!
  26. Performance is the main reason why we've decided to rewrite

    Fennec's frontend. We've been working on the native UI of Fennec since October last year. The whole mobile team is focused on that right now. What is it about? Architecture-wise, the native UI removes Gecko from the critical startup path to allow us provide a usable UI immediatelly to our users. This means replacing XUL with native Android toolkit for UI development.
  27. Threaded rendering • Remove Electrolysis • UI and Gecko run

    on separate threads • Messaging system
  28. Rather than use two processes to stop web rendering from

    holding up the UI, we now use threads. We have three main threads in the application; One is Gecko, another is the main application, which does touch input handling, IME (input method) handling, bookmarking, history, etc. And the last thread is the rendering thread. This architecture lets us remain responsive at all times, as screen updates are almost never held up by Gecko, or anything else for that matter. To handle messaging between Gecko and the rest of the application, we inject events into Gecko's event queue. While there is a list of specific events, to remain flexible, we have generic events that we can send between the Gecko browser object and the Java application, which we encapsulate in JSON.
  29. Graphics • Layered compositor in Java and GLES

  30. Graphics-wise, as we're now a native Android application, it's very

    easy for us to take advantage of GLES without breaking compatibility with devices. We use a similar system to that which the old Firefox Mobile used to provide asynchronous rendering, but we rather than relying on Gecko's layer-rendering code, we have our own layered compositor written in Java and GLES. So today, we have very smooth update. For the overwhelming majority of the time, we render at 60fps and we respond instantly to user input. There are still issues to resolve with checkerboarding, and we hope to have done that by the time we release.
  31. Replacing Places • Can't wait for Gecko • Native DB

    as an Android ContentProvider
  32. I guess everyone here is familiar with Places. It's the

    system that stores your bookmarks and history on Desktop Firefox. Places runs inside Gecko and, as we said, one of the main points of native UI is to remove Gecko from the critical startup path. This means we can't wait for Gecko to be up and running to give access to history and bookmarks. For instance, We want users to start Fennec and be able to use the AwesomeBar straight away. We replaced Places with a native Android bookmarks and history store implemented as a ContentProvider.
  33. Native Sync • Native Android Sync Account • Syncs even

    when Fennec isn't running
  34. To provide the right integration with Android, Sync has also

    been written from scratch as an Android sync adapter using the new bookmarks and history ContentProvider. The UX is much better as it's more integrated with Android, and this makes it possible to sync your data even when you're not using Fennec. Right now, it's possible to sync bookmarks and history Password sync will land soon. Tabs might not be in our first native release.
  35. Start Page • Can't wait for Gecko • Native Android

    UI
  36. The Start page in in XUL Fennec is loaded when

    Gecko is up. But, again, we don't want Gecko blocking UI interaction on startup. So, we implemented the start page in native android UI. This means we can show it immediately while Gecko is loading in background.
  37. Revamped design • Looks native • New tab UI

  38. The design team at Mozilla is doing a coordinated work

    to streamline the UX of Firefox in different devices (desktop, tablets, phones). As part of this effort, they've come up with a new design for Fennec. It's inspired by the design work made for tablets—that has been released in Firefox 9.
  39. None
  40. You have now have clear feedback on how many tabs

    you have. The tabs UI doesn't require panning web content—an interaction problem we had in XUL Fennec.
  41. Support for addons • XUL overlays are not possible •

    JS API to integrate with native UI
  42. For add-ons, you can no longer use XUL overlays as

    our interface isn't written in XUL. Instead, we have prescribed APIs that add-ons can use that expose native functionality, such as menus and door-hanger dialogs. This is still work-in-progress, but having an API means we can make large changes to how the UI works and maintain add-on compatibility in the future.
  43. Flash support • Flash support for Froyo and Gingerbread •

    Amazing ICS support coming soon
  44. We have better Flash support for Froyo and Gingerbread now.

    While it's still not as great as we'd like it to be, it's much better than it was before and works reasonably well. We have great support for Flash on ICS, which you can experience in Nightly builds.
  45. Schedule • Aiming at Firefox 11 • Might be delayed

  46. We're right now working hard to get the native UI

    released with Firefox 11. However, we'll consider delaying the release if necessary—given the amount new code is involved. It's important to have a solid first native release to create momentum around the new UX. You can help us test everything we talked about here by installing either Aurora or Nightly. We don't have a Beta build yet as we'd like to fix a few serious bugs and missing features before doing it.
  47. Nightly http://nightly.mozilla.org Aurora http://aurora.mozilla.org

  48. What's next? • Native tablet UI • Home screen widget

    • Reading mode
  49. We have some ideas for new features in future releases.

    We're obviously focused on getting the first native release out right now. Design team is working on an improved design for tablets that will be implemented in the same fashion than our native UI for phones. A home screen widget to give you quick access to AwesomeBar data and more. And a reading mode and adapts the UI and content for a better reading experience.
  50. Questions?