Margaret Leibovic

Almost two years, I experimented with using the dominant color of a favicon to give a small icon a colorful background. And over the past week, I wrote some patches to incorporate this design into Firefox for Android!

The simple algorithm I wrote long ago was done in JS with canvas, but to use this in our native Android UI, it’s simplest to just do it in Java. Luckily, we already had a dominant color utility method in the tree, but creating a background and border with different saturation levels was trickier than I thought it would be. To solve this problem, I gave the ImageView a background drawable with a solid white interior and a gray border, then applied a transparent version of the dominant color as a color filter. This worked pretty well once I figured out which PorterDuff mode to use, but it made me appreciate the simplicity of CSS.

When testing with various icons, I found that our dominant color algorithm could use some improvement. Our Java algorithm is different than the one I experimented with in JS mainly because it uses the HSV color model as opposed to RGB. Instead of counting every distinct color, we split the range of hues into different bins and find the bin that holds the most colors. For the winning bin, we compute the average H, S, and V values within that bin, and return that as the dominant color. To make sure we only return colorful colors, we ignore transparent pixels, as well as pixels that are close enough to black or white. This simple algorithm may not be perfect, but it works pretty well for us, especially for small favicons.

As an interesting bit of history, after I blogged about my dominant color experiment, Mardak wrote an add-on that used an improved version of my JS snippet. At the time, Wes saw this add-on and incorporated the code into XUL Fennec to create icons for homescreen shortcuts. During the Fennec Native rewrite, Wes reimplemented this feature in Java, and that’s the code I found myself in last week. And for those interested in a more robust solution implemented in JS, there’s actually a toolkit service that does this now.

This past weekend I attended MozCamp EU in Warsaw, and it was really energizing to see so many awesome Mozilla contributors come together. The theme of this MozCamp was “Mobilize Mozilla”, and I co-hosted a session about developing add-ons for Firefox for Android.

In the first part of this session, we walked through the basics of developing a simple restartless add-on. After that, we set developers loose to start hacking on their own add-ons, encouraging them to start with a bootstrapped add-on skeleton. Before long, we saw a bunch of excited developers pointing to test menuitems and notifications appearing on their phones, followed by discussion about all the cool things they wanted to build. This was one of my favorite parts of MozCamp!

Although this session proved that it’s not too hard to get started with mobile add-on development, there are definitely some pain points. Here are some things we need to work on:

• Create an easier workflow for getting an add-on from your development machine to your phone. Right now the easiest way to do this is using adb, but some developers want to be able to test their add-ons without installing the Android SDK.
• Fully support using the Android emulator to develop mobile add-ons. Some of the developers attending the talk didn’t own Android phones; we had extra phones on hand to lend to them, but that’s not a long term solution. I know that work has been done to run Firefox in the emulator, but I don’t know of anyone on the mobile team actively testing this to make sure it always works.
• Better documentation! This is always true of everything, but I want to call it out. In particular, I think we need more documentation about manipulating content from mobile add-ons. Even though this is very similar to what you would do for a desktop add-on, getting at the content window is different, and this confused some developers.

I’m looking forward to seeing more mobile add-ons, and I’d like to know if there’s anything else we can do to make it easier to develop add-ons for Firefox for Android. The mobile team is always hanging out in #mobile on irc.mozilla.org, so please jump in there if you have any ideas, or if you need help developing your add-on! 

I finally landed basic support for text selection in Fennec Native, and you can check it out in the latest Nightly build! Similarly to how text selection worked in XUL Fennec, you can long tap on some text to start a selection, and use draggable handles to change the selection area. A single tap inside the selection area will copy the selected text to your clipboard, and a single tap outside the selection area will cancel the selection.

There are definitely still a lot of known issues to work out, including full support for RTL pages, support for selection in inputs, and some problems with the handles. Text selection bugs are being marked as blocking bug 695173, so that’s where you can follow our progress. That’s also where you can file the bugs we haven’t found yet!

For the past few months, I’ve been spending most of my time helping the mobile team with the Fennec NativeUI rewrite, and a few weeks ago I officially became a member of the mobile front-end team. Although working on a native Android app has been painful different, I’ve found my desktop browser knowledge to be really useful, especially when working on Fennec features that I also helped make on desktop Firefox. I’m hoping that this will encourage the desktop and mobile teams to work together more closely, since we’re really just all part of a bigger team trying to make an awesome Firefox experience across all of your devices.

I’ve neglected to blog about the mobile work I’ve been doing these past few months, but I’ll use the excuse that I was too busy writing code instead! Among other things, I’ve been working on click-to-play plugins, doorhanger notifications, site settings, bookmarks, and our form assistant UI. Grab a Nightly build to see our most recent changes, or check out Aurora for a more stable experience.

This post is co-written by Margaret Lebovic and Sid Stamm. This article is cross-posted on Sid’s blog.

As the web becomes more and more complex (and AWESOME), it’s important that you can manage your relationship with the variety of sites out there. Sure, Firefox 4 has a Page Info dialog that lets you control what a web page is allowed to do, including whether you want to let it store data on your computer, access your location information, open pop-up windows, and on and on. However, this dialog only lets you manage your relationship with the one page you’re currently visiting, not the entire set of sites you visit on the web.

We think it’s important to be able to manage your whole relationship with web sites in an intuitive way, and that’s why we’re exited to show you what we’ve started working on: a site-based permissions interface.

This feature is still experimental, but you can give it a shot. In the future, we’ll be putting some polish on the UI, adding more controls like “always access securely” (HSTS), and hopefully giving you a better view of what a site knows about you. We also want to integrate this permissions manager with the site identity block in the location bar for quick and easy access.

Try it out! Grab an Aurora build and try out the feature by typing about:permissions into the location bar.

It’s only been a month since I joined Mozilla as a full time employee, but it feels like it’s been much longer. Joining the Firefox team late in the Firefox 4 development cycle meant diving into a pile of blockers, so I had to get up to speed right away. By the end of my first week, I was the assignee on five blockers, wrote a few patches, and even broke the tree! I couldn’t remember everything I’ve done this past month, so I had to search through bugzilla to jog my memory. It turns out I did a lot! I was able to group most of the larger bugs I worked on into a few categories:

• About window: I refreshed the “About Firefox” window to include language about the Mozilla mission, important links, and update functionality. Compare a screenshot of the old about window…
  
  …to a screenshot of the new one!
  
  (bugs 579547, 571127, 571424, 585475, 591013)
• Doorhanger notifications: Continuing work that Frank Yan started, I converted the “Remember Password” and “Change Password” notifications from bar-style notifications to doorhanger notifications. Compare a screenshot of an old notification…
  
  …to a screenshot of a new one! (Please note that the styling of these doorhanger notifications is being handled by separate bugs.)
  
  (bugs 567814, 573536, 588309, 594572)
• Progress lines: I added progress lines to the location bar and tabs, eliminating the need for the progress bar in the status bar. (The styling on these lines is also being handled in follow-up bugs.)
  
  (bugs 544818, 578028)

Besides these bugs, I also worked on implementing a quick prototype of a “Share” menu to replace the “Send Link…” menu item with a list of sharing services (bug 588508). There are some tricky decisions to be made about how we’ll generate this list of services, so this feature isn’t going to make it into Firefox 4, but look out for it in future releases!

This summer I created an experimental prototype of an about:me page for Firefox, and I am proud to announce that it is now available for download as an add-on on addons.mozilla.org! The goal of the about:me page is to give you a more interesting view of statistics about your browser usage, providing a fun way to see personalized patterns in your interactions with Firefox. The current version includes graphs that illustrate trends in your browsing and downloads histories. The “Activity Stats” section graphs the websites you visit most, including the individual pages you visit most within each top-level site. This section also graphs your hourly browsing activity, which can reveal patterns in websites you visit most at various times of the day.

The “Downloads Stats” section illustrates the distribution of different types of files you download, as well as daily trends in your download activity.

I plan to continue to develop the about:me page to include more sections from our brainstorming list, such as statistics about bookmarks and tabs. Please let me know if there’s anything you would love to see next!

I recently finished work on a sprint to improve perceived performance in Firefox. Unlike code improvements that actually make the browser faster, perceived performance improvements make the browser feel faster. There is currently a long list of brainstormed ideas for these improvements, but Alex Faaborg identified improving mouse wheel behavior in Windows as a quick way to make the browser appear noticeably more responsive. In native Windows applications, scroll events triggered by long flicks of the mouse wheel are not distinguished from events triggered by single wheel clicks, which can result in frustratingly slow scrolling when traveling a long distance down a page. Mac OS X, on the other hand, applies an acceleration effect to mouse wheel events, increasing the distance the page moves in response to multiple successive mouse wheel events. In order to create this acceleration effect in Windows, I wrote some code that changes the way we process mouse wheel events. This code uses some logic and arithmetic to increase the distance the page should move if there are multiple successive mouse wheel events, using the values of three different preferences to determine exact behavior.

• mousewheel.withnokey.numlines: The number of lines the page moves with one click of the mouse wheel. This value is used to determine scrolling distance before acceleration computations are applied. Increasing this value will make scrolling feel faster for all types of scroll wheel actions, including individual scroll wheel clicks.
• mousewheel.acceleration.start: The mouse wheel click number at which acceleration begins to take effect. This value determines whether or not acceleration computations are applied to a given scroll event.
• mousewheel.acceleration.factor: The multiplicative factor used to determine the rate of acceleration. The acceleration computations create a constant acceleration effect, but this value can control the level of acceleration.

These preferences can be configured from the about:config page, and although the default values are not set in stone, they seem to create a reasonable acceleration effect. Feel free to play with these preferences on a nightly build and let me know what you think!