Upgrade to Pro — share decks privately, control downloads, hide ads and more …

The State of Firefox Mobile

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.

Lucas Rocha

February 09, 2012
Tweet

More Decks by Lucas Rocha

Other Decks in Technology

Transcript

  1. The State of Firefox Mobile

    View full-size slide

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

    View full-size slide

  3. 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.

    View full-size slide

  4. The web is going mobile
    Mozilla has to be mobile

    View full-size slide

  5. 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.

    View full-size slide

  6. Firefox Mobile
    Firefox Sync
    Boot to Gecko
    Open Web Apps
    Pancake

    View full-size slide

  7. 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.

    View full-size slide

  8. Positive feedback
    • Great HTML5 support, fast JavaScript
    • Built-in Sync, innovative UI design

    View full-size slide

  9. 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.

    View full-size slide

  10. Current architecture
    • JavaScript + CSS + XUL are very portable
    • Code sharing with Desktop Firefox

    View full-size slide

  11. 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.

    View full-size slide

  12. Negative feedback
    • No Flash support
    • Poor video support

    View full-size slide

  13. 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.

    View full-size slide

  14. The top end-user complaint is...

    View full-size slide

  15. But when it comes to our current Firefox Mobile release, the top end-user
    complaint is pretty clear. Can you guess what this is?

    View full-size slide

  16. Yes, Performance. Let us talk a bit more about what we mean by performance here.

    View full-size slide

  17. Slow startup
    • Up to 30 seconds!
    • libxul is... chunky
    • Gecko on critical path

    View full-size slide

  18. 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.

    View full-size slide

  19. Not responsive, slow
    • Rendering overhead with e10s
    • Reliance on Gecko's render performance
    • Lazy-loading components

    View full-size slide

  20. 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.

    View full-size slide

  21. Uses a lot of memory
    • Overhead of having two processes (e10s)
    • Frequent background killing

    View full-size slide

  22. 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.

    View full-size slide

  23. The Native UI
    • Remove Gecko from critical path
    • Use native Android toolkit
    • Gecko, of course!

    View full-size slide

  24. 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.

    View full-size slide

  25. Threaded rendering
    • Remove Electrolysis
    • UI and Gecko run on separate threads
    • Messaging system

    View full-size slide

  26. 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.

    View full-size slide

  27. Graphics
    • Layered compositor in Java and GLES

    View full-size slide

  28. 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.

    View full-size slide

  29. Replacing Places
    • Can't wait for Gecko
    • Native DB as an Android ContentProvider

    View full-size slide

  30. 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.

    View full-size slide

  31. Native Sync
    • Native Android Sync Account
    • Syncs even when Fennec isn't running

    View full-size slide

  32. 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.

    View full-size slide

  33. Start Page
    • Can't wait for Gecko
    • Native Android UI

    View full-size slide

  34. 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.

    View full-size slide

  35. Revamped design
    • Looks native
    • New tab UI

    View full-size slide

  36. 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.

    View full-size slide

  37. 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.

    View full-size slide

  38. Support for addons
    • XUL overlays are not possible
    • JS API to integrate with native UI

    View full-size slide

  39. 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.

    View full-size slide

  40. Flash support
    • Flash support for Froyo and Gingerbread
    • Amazing ICS support coming soon

    View full-size slide

  41. 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.

    View full-size slide

  42. Schedule
    • Aiming at Firefox 11
    • Might be delayed

    View full-size slide

  43. 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.

    View full-size slide

  44. Nightly
    http://nightly.mozilla.org
    Aurora
    http://aurora.mozilla.org

    View full-size slide

  45. What's next?
    • Native tablet UI
    • Home screen widget
    • Reading mode

    View full-size slide

  46. 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.

    View full-size slide