Archive for Mozilla

Firefox for Android: Page Load Performance

One of the common types of feedback we get about Firefox for Android is that it’s slow. Other browsers get the same feedback and it’s an ongoing struggle. I mean, is anything ever really fast enough?

We tend to separate performance into three categories: Startup, Page Load and UX Responsiveness. Lately, we have been focusing on the Page Load performance. We separate further into Objective (real timing) and Subjective (perceived timing). If something “feels” slow it can be just as bad as something that is measurably slow. We have a few testing frameworks that help us track objective and subjective performance. We also use Java, JavaScript and C++ profiling to look for slow code.

To start, we have been focusing on anything that is not directly part of the Gecko networking stack. This means we are looking at all the code that executes while Gecko is loading a page. In general, we want to reduce this code as much as possible. Some of the things we turned up include:

  • Writing extra and/or redundant page information to the history database
  • Saving session restore information too frequently
  • Looking up Android system proxy information was slow
  • Drawing unused view backgrounds
  • Animating the pageload spinner consumed a lot of CPU cycles
  • Extra messaging between the Java UI and Gecko
  • Opportunities for predictive networking hints

Some of these were small improvements, while others, like the proxy lookups, were significant for “desktop” pages. I’d like to expand on two of the improvements:

Predictive Networking Hints
Gecko networking has a feature called Speculative Connections, where it’s possible for the networking system to start opening TCP connections and even begin the SSL handshake, when needed. We use this feature when we have a pretty good idea that a connection might be opened. We now use the feature in three cases:

  • When a touch occurs on a link in web content, we speculatively connect to the HREF. Technically, we need to wait before really opening the link to make sure you didn’t really start panning the page or start a double-tap.
  • When starting to type a URL in the titlebar, we load the current set of search engines. We speculative connect to the default search engine, since it’s somewhat probable that you will perform a search.
  • When typing into the titlebar, Firefox tries to use domain autocompletion and searches your history for recent URLs. Both the current auto-completed URL and the top-most search result are speculatively connected.

Animating the Page Load Spinner
Firefox for Android has used the animated spinner as a page load indicator for a long time. We use the Android animation framework to “spin” an image. Keeping the spinner moving smoothly is pretty important for perceived performance. A stuck spinner doesn’t look good. Profiling showed a lot of time was being taken to keep the animation moving, so we did a test and removed it. Our performance testing frameworks showed a variety of improvements in both objective and perceived tests.

We decided to move to a progressbar, but not a real progressbar widget. We wanted to control the rendering. We did not want the same animation rendering issues to happen again. We also use only a handful of “trigger” points, since listening to true network progress is also time consuming. The result is an objective page load improvement the ranges from ~5% on multi-core, faster devices to ~20% on single-core, slower devices.

fennec-throbber-and-progressbar-on-cnn

The progressbar is currently allowed to “stall” during a page load, which can be disconcerting to some people. We will experiment with ways to improve this too.

Install Firefox for Android Nightly and let us know what you think of the page load improvements.

Comments (12)

GeckoView: Embedding Gecko in your Android Application

Firefox for Android is a great browser, bringing a modern HTML rendering engine to Android 2.2 and newer. One of the things we have been hoping to do for a long time now is make it possible for other Android applications to embed the Gecko rendering engine. Over the last few months we started a side project to make this possible. We call it GeckoView.

As mentioned in the project page, we don’t intend GeckoView to be a drop-in replacement for WebView. Internally, Gecko is very different from Webkit and trying to expose the same features using the same APIs just wouldn’t be scalable or maintainable. That said, we want it to feel Android-ish and you should be comfortable with using it in your applications.

We have started to build GeckoView as part of our nightly Firefox for Android builds. You can find the library ZIPs in our latest nightly FTP folder. We are in the process of improving the APIs used to embed GeckoView. The current API is very basic. Most of that work is happening in these bugs:

  • Bug 880119: Improve the API for GeckoView
  • Bug 880121: Add support for host application interfaces to GeckoView
  • Bug 880123: Add support for content callback interfaces to GeckoView

If you want to start playing around with GeckoView, you can try the demo application I have on Github. It links to some pre-built GeckoView libraries.

We’d love your feedback! We use the Firefox for Android mailing list to discuss status, issues and feedback.

Note: We’re having some Tech Talks at Mozilla’s London office on Monday (Oct 21). One of the topics is GeckoView. If you’re around or in town for Droidcon, please stop by.

Comments (13)

We <3 Interns!

If Mozilla had secret weapons, I think our Interns would be included on the list. These hard working troops descend upon us during their school breaks and end up working on some of the hardest problems Mozilla has to offer. Our primary Intern “season” is wrapping up and I wanted to touch upon some of the work completed or in-progress.

Firefox for Android

  • Shilpan Bhagat: Shilpan ramped up quickly on Android UI work, tackling some of the tablet work for the new Home page in Firefox for Android, as well as, investigating and implementing some performance improvements. He also created a way to inject “pageactions” into the URLBar and an add-on API to go along with it. Shilpan then took pageactions and added unobtrusive support in Firefox for launching native Android apps registered to handle given page URIs. [presentation]
  • Shane Tully: Shane did some hard work getting the new Contacts API for webapps implemented on Android. In the process, he got to spend some time working through issues that come up with new API specs. He also picked up the work to get a GeckoView widget building and packaged, so Android applications can bundle the Gecko rendering engine instead of the system WebView. Shane really pushed the GeckoView project past a hurdle that now means we can start adding new features to the widget. [presentation]
  • Chris Kitching: Chris did the foundation work for supporting the new ActionBar when selecting text. He converted the Search Engine UI from XHTML to native Android. He also picked up work to enable ProGuard in Firefox for Android. This could yield >10% performance improvement in some areas. He had to write an automatic code generator that annotated parts of the code, allowing ProGuard to do its job. He stumbled into a problem with the Favicon system, which turned into a large rewrite – with significant improvements to behavior, performance and appearance. He persuaded me to install IntelliJ. [presentation]

Firefox for Metro

  • Jonathan Wilde: Jonathan was the front-end team on Firefox for Metro last year, writing the first UI nearly entirely by himself. He returned this year to continue working on the new browser, including work on the Findbar, combined Appbar and autocomplete UI and the hairy UI interactions that accompanied those features. He probably has more lines of code in the UI attributed to him than any other team member. He also worked with the UX team to prototype some cool ideas around new ways to save sites that preserve the user’s context with them, including Highlighting and Clipping. [presentation]

One of the things I like about the way Mozilla utilizes interns is that it shows them exactly what happens in real software development. They learn that code reviews can take a lot of time. Your feature might not make the desired release, or even get backed out at the last minute. They learn that large software projects are painful and carry a lot of legacy baggage, and you need to deal with it. I think it’s also a great way to learn how to communicate in a team environment. They also get to ship features in Firefox, and who doesn’t love shipping stuff?

Interns of 2013, we salute you!

Comments off

Firefox for Android: Team Meetup, Brainstorming and Hacking

Last week, the Firefox for Android team, and some friends, had a team meetup at the Mozilla Toronto office. As is typical for Mozilla, the team is quite distributed so getting together, face to face, is refreshing. The agenda for the week was fairly simple: Brainstorm new feature ideas, discuss ways to make our workflow better, and provide some time for fun hacking.

We spent most of our time brainstorming, first at a high level, then we picked a few ideas/concepts to drill into. The high level list ended up with over 150 ideas. These ranged from blue-sky features, building on existing features, performance and UX improvements, and removing technical debt. Some of the areas where we had deeper discussions included:

  • Sharing: We talked about ways to improve the current Quick Share system by making it more context-aware, adding support for default providers and supporting Quick Share from more than the main menu. We also discussed adding support for more explicit sharing with integrated services. This would allow more control than Android’s Intent system supports by itself.
  • Cloud Services: We found that there are plenty of ways we can integrate with cloud services. Whether it’s a way to backup parts of your profile, pull external search results into the Awesomescreen, or use other services as a source for the Reading List. Lots of project ideas were created from this concept.
  • Focused UX: There were a lot of discussions around how specific types of users could benefit from new features. We ended up grouping some of these together around commonalities, which include: Privacy oriented features, parental control and child web-safety features, and hardening the application by reducing ways to corrupt the state and providing ways to rollback to a good state. While these ideas might fall into common groups, we decided that many of the details would benefit all users.

We also took some time to examine our workflow. We found some rough edges we intend to smooth out. We also ended up with a better understanding of our current, somewhat organic, workflow. Look for more write-ups from the team on this as we pull the information together. One technical outcome of the the discussions was a critical examination of our automated testing situation. We decided that we depend entirely too much on Robotium for testing our Java UI and non-UI code. Plans are underway to add some JUnit test support for the non-UI code.

The Android team is very committed to working with contributors and have been doing a great job attracting and mentoring code contributors. Last week they started discussing how to attract other types of contributors, focusing on bug triage as the next possible area. Desktop Firefox has had some great bug triage support from the community, so it seems like a natural candidate. Look for more information about that effort coming soon.

There was also some time for hacking on code. Some of the hacking was pure fun stuff. I saw a twitterbot and an IRCbot created. There was also a lot of discussion and hacking on add-on APIs that provide more integration hooks for add-on developers into the Java UI. Of course there is usually a fire that needs to be put out, and we had one this time as well. The front-end team quickly pulled together to implement a late-breaking design change to the new Home page. It’s been baking on Nightly for a few days now and will start getting uplifted to Aurora by the end of the week.

All in all, it was a great week. I’m looking forward to seeing what happens next!

Comments off

Patterns of Effective Teams

I have been lucky to build software products for a few different companies, each with a distinct culture. It’s help me form opinions about people, tools and processes that make teams effective at shipping software products.

Who makes up a software product team? Mileage may vary, but I like to include:

  • Developers
  • Testers
  • UX Designers
  • Project Managers
  • Product Managers
  • Support

Lots of companies organize people into functional groups: All the developers in a group, all the testers in a group, all the designers in a group… and so on. This doesn’t make it easy to ship software. It can create walls and make it harder to communicate. You also lose the “team” feeling, as well as the focus and drive that comes from that.

Product-centric teams seem to be more effective at shipping. These multidisciplinary teams embed members from the various groups on the team, all working together to create and ship a software product.

Over the years, I’ve seen productive teams using a few basic concepts. Some are process related, some can be aided by tools, but most deal with relationships between people:

  • Trust each other: Each member has a role, and members need to trust in each other’s ability to perform.
  • Talk to each other: Lots of open communication is important. The team is a safe place, so there are no stupid questions. Meet as a group often to discuss progress.
  • Support each other: You win and lose together. Help others, even if not asked directly.
  • Be passionate: The team needs to be passionate about succeeding and hungry to ship a great product. There will be rough spots on the way. There always are, but the team needs that passion to be able to power through.
  • Move as a single, focused group: Speed is important. Decisions, implementation, feedback – all need to happen ASAP. Distractions kill speed.
  • Plan work as a group and document the plan: If everyone is part of the planning, everyone is committed to the plan. Keeps the team focused.
  • Create a roadmap: You need a Big Picture too. What’s the vision and strategy? It helps set the tone for everything else.
  • Break work into small tasks and track the tasks: Small tasks are manageable and trackable. Small tasks are easy to scope and keeps the team focused. Watch out for scope creep.
  • Create milestones and track progress: Deadlines are a good thing, even if just internal. Forward progress is essential for shipping and milestones are great for tracking progress.
  • Adjust as needed: Don’t be afraid to adjust anything: schedule, milestones, tasks. You are collecting data every day. Use it to make informed decisions ASAP. Triage your work often.

I like to keep things lightweight. This includes tools and processes. Focus more on your product and the work at hand. Processes and tools can be distractions. The best ones are those that stay out of your way.

Update: Taras reminded me indirectly about the importance of passion, so I added it to the list.

Comments (2)

Firefox for Android: Subscribing to Feeds

Firefox on desktop has nice support for previewing and subscribing to syndication feeds (RSS and Atom). There is even support for creating Live Bookmarks. Firefox for Android does not support anything related to syndication feeds… until now.

We just landed basic support for subscribing to feeds discovered on a web page. This is only initial support, so many things are not supported.

How it works:

  • If feeds are discovered on a page, Firefox will enable a menu action on the URLBar long-tap menu. Yes, we have a URLBar long-tap menu!
  • Tap the “Subscribe to Page” menu action.
  • If there is more than one advertised feed, choose the feed you want.
  • Pick the online web service where you want to add the subscription. The choices really depend on the locale, but initially Google Reader (but not for long) and Yahoo are supported.

The limitations:

  • We only support online web services right now. We are looking into local application support too, but have not seen a universal way of listing feed reader applications. We are working on a proposal and want to get support from native feed reader apps like Feedly and Newsblur.
  • No support for feed previews. No plan to add support
  • No support for adding new web service handlers. We are working to add this support.
  • No support for Live Bookmarks. No plan to add support.

In pictures:

Long-tap on the URLBar


Choose “Subscribe to Page”


Choose the feed


Choose the web service

Comments (1)

Following the Firefox for Android Team

On The Web

If you want to stay up to date on any new developments in Firefox for Android (Fennec), check out the new Tumblr and Twitter stream. Lots of updates on what’s landing in Fennec Nightly, tips and tricks and summaries of the Mobile Engineering Team meetings.

Mailing List

We have a new mailing list at mobile-dev-firefox@mozilla.org. The newsgroup at mozilla.dev.platforms.mobile is being closed. Use the new mailing list to following along and give feedback on topics being discussed, or post your own ideas.

On IRC

As always, you can jump on Mozilla IRC and talk directly to the Mobile team in the #mobile channel. This is great if you want to start working on the code, need help writing an add-on, want to help investigate a bug or just rant about some design decision.

Comments (2)

Firefox for Android: Running on Android x86

Intel and Lenovo launched the first Android device based on the Intel Atom processor in 2012 at CES. Some of the current Android x86 devices include the Lenovo K800, the Orange San Diego, the ZTE Grand X IN, and the Motorola RAZR i.

Mozilla has been internally testing Android x86 builds of Firefox. Firefox runs really well on the Motorola RAZR i. Once we get Android x86 nightly builds stood up and running automated tests, we’ll start planning for a release.

In the meantime, you can try a developer build of Firefox for Android x86 yourself. Just like the ARM version, Firefox runs on Android 2.2 or higher. It should run fine on the Lenovo K800, which shipped with Android 2.3.7 (Gingerbread).

WARNING: This is not an officially released version of Firefox. It will only run on Intel-based (x86) Android devices.

If you don’t have an Android x86 device, you can still try the build using the Android x86 emulator. It’s the same as standard ARM emulator, but since it’s x86, it runs a lot better on your PC. Just make sure you update your Android SDK so it has the latest AVD images, and make an AVD using the x86 image. Also make sure you enable Use Host GPU as well:

Please let us know how the build works on your Android x86 devices and remember to file bugs.

Comments (15)

Firefox for Android: Remote Web Console is Here

I already blogged about support for remote debugging in Firefox for Android. Now we have support for remote Web Console too!

The remote console, like remote debugging, requires using Desktop Firefox to connect to Mobile Firefox over USB using ADB. Remote console is supported in Firefox 19 and newer releases. Here’s a quick guide to getting started:

  1. USB Connection: Connect your Android device running Firefox to a host machine running desktop Firefox using USB. In a terminal, forward the TCP connection using: adb forward tcp:6000 tcp:6000
  2. Firefox Desktop: Use about:config to enable remote debugging. Set the “devtools.debugger.remote-enabled” pref to true. Restart. You should see a “Tools > Web Developer > Remote Web Console” menu.
  3. Firefox for Android: Use about:config to enable remote debugging. Set the “devtools.debugger.remote-enabled” pref to true. Restart.
  4. Firefox Desktop: Choose “Tools > Web Developer > Remote Web Console” and a Remote Connection dialog should open. If you changed none of the other remote debugging preferences, just use the defaults. Press OK.
  5. Firefox for Android: You should see a remote connection prompt appear. Press OK to initialize the connection. You have 20 seconds, by default, to accept the connection. You can retry 3 times.
  6. Firefox Desktop: Once the connection is accepted, you should see a scope prompt. The prompt is used to pick the tab, or global, scope you want to attach to the web console.
  7. Firefox Desktop: After picking a scope, you should see a Web Console window appear.

Once you have the Web Console up and running, you can do pretty much everything the desktop version can do. For example, you can load a web page and monitor the network activity, including viewing the network request details:

You can also use the JS console to execute JS code in the scope of the web page running on the Android device! Pretty cool!

A big thanks goes out to Mihai Sucan, who did a mountain of work to get the Web Console remoted. Mihai also blogged about the remote Web Console and you can find some of the underlying details on the remoting API on MDN.

Happy (remote) Debugging!

Comments (5)

Firefox for Android: Remote Debugging is Here

Lucas blogged a while ago about some of the initial work on creating a remote debugging system for Firefox on Android. The desktop patches Lucas mentioned have landed, and remote debugging Firefox for Android is now possible.

Remote debugging requires using Desktop Firefox to connect to Mobile Firefox over USB using ADB. Remote debugging is supported in Firefox 15 and newer releases. Here’s a quick guide to getting started:

  1. USB Connection: Connect your Android device running Firefox to a host machine running desktop Firefox using USB. In a terminal, forward the TCP connection using: adb forward tcp:6000 tcp:6000
  2. Firefox Desktop: Use about:config to enable remote debugging. Set the “devtools.debugger.remote-enabled” pref to true. Restart. You should see a “Tools > Web Developer > Remote Debugger” menu.
  3. Firefox for Android: Use about:config to enable remote debugging. Set the “devtools.debugger.remote-enabled” pref to true. Restart.
  4. Firefox Desktop: Choose “Tools > Web Developer > Remote Debugger” and a Remote Connection dialog should open. If you changed none of the other remote debugger preferences, just use the defaults. Press OK.
  5. Firefox Desktop: You should see an empty debugging window appear.
  6. Firefox for Android: You should see a remote debugging connection prompt appear. Press OK to initialize the connection. You have 3 seconds, by default, to accept the connection. You can retry 3 times.
  7. Firefox Desktop: Once the connection is accepted, the empty debugging window will fill with scripts running in the Firefox for Android web page.

Thanks to Lucas, Panos Astithas and the rest of the DevTools team for making this happen. Happy Debugging!

Comments (7)

« Previous entries Next Page » Next Page »