I’m a bit sad for Firefox. It used to be the fast, powerful, progressive browser that finally broke IE’s era of stagnant dominance and saved web developers’ sanity. Now, it’s a bloated, slow, unstable monster that’s often a pain in this web developer’s ass.

Siegler nods in assent. It’s funny to me because in my sphere Firefox is alive, full of new life due to efforts like memshrink and Jaegermonkey. The stability cry also rings hollow; this is a non-issue for me.

Then again, I have a few tricks up my sleeve that you may not. For web developers out there who love Firefox and its mission but worry about the bloat, I have a few suggestions:

• Try the Aurora or Beta channel to reap some performance benefits.
• Be stingy about your extensions. Mozilla is only beginning to address the tip of the iceberg that is extension performance, but for you, know that performance can be dramatically affected by them. If you’re using Chrome now, you’ve probably paired down anyway; try being zen about Firefox and you might be surprised. The same goes for plugins.
• Speaking of extensions, Firebug is one of the worst offenders for bloat. There were several memory leaks fixed recently that you may not know about, and I recommend using the latest and greatest here as well. Or: try some of the built-in developer tools that the Aurora channel now has.
• If you crash, be sure to look at about:crashes. If you report it, an issue will be created and you can check out any progress on it. In my experience, it’s usually Flash. If you are worried about bloat, keep an eye on about:memory.
• File bugs! Firefox is a community effort, and web developers have a responsibility for the future of the web. If you don’t want the big three (Google, Apple, and Microsoft) in a room deciding where the web goes next, Mozilla is truly the one voice that continues to make a difference in these discussions.

Is it tacky to quote yourself? I’m in a devil-may-care frame of mind this morning, so I’m doing it anyway!

From this post:

I’m an imperfect being and I know I should write much more tests than I do.
I will continue fighting the urge to just ignore tests and keep telling
myself why they are so crucial. I’m trying to be part of the solution, and
I’ve committed a few mochitest patches along the way. What Mozilla could do
to help me significantly is to give me great tools…

And then:

It’s worth noting that the details matter. I know we devs tend to think of
ourselves as very practical and rationally minded, but the longer I make
stuff the more I am convinced that an emotional feeling of using these tools
is crucial to a happy developer. So let’s get some ideas, and I’ll be happy
to file some bugs!

Etherpad here:
http://ietherpad.com/mozilla-test-tools

Brainstorm your ideas. We’ll sort them out and file some bugs! I’m particularly interested in what the web developers in the crowd have to say, as in my experience the tools there are a pleasure to use.

…[B]rowsers have historically been very friendly to learning web-making, in part because they keep protocol information in the address bar. My guess is that removing the http:// neither helps nor hinders someone from using the basics of the web—but it definitely makes it harder to learn what hypertext is.

Atul is rightly worried. The web is evolving rapidly, and one of its genes stands trial: the URL. It faces mounting pressure of extinction as a prominent piece of our user interfaces. The removal of the protocol is one minor example. Take the native application trend on mobile. Although the URL still remains the technical heart pumping data through our web, the URL no longer stands as the canonical identity of our web. On my phone, I don’t go to twitter.com. I tap on Twitter. I find myself spending more time outside the browser than ever before.

In truth, Mozilla is beginning to embrace this trend. We are now dreaming up open application markets and painting pictures of web applications that appear no different than their native cousins. The trend feels obvious. In this manner, native has already triumphantly secured its place in the gene pool.

Will the URL ultimately fade into oblivion? I can’t predict the future, but I can ask a better question. If the URL no longer stands as the bulwark defending the hackability and transparency of our web, what new things will we build up to replace it?

Then, imagine tapping on a link and immediately seeing a familiar interface that is loading your web page in place of a loading screen. This is the goal for startup shrink.

It’s been a week since our first meeting. Some important bugs:

• Near term
• Bug 94199: Fastload XBL methods and properties. A critical part of startup is loading Javascript methods and properties inside our XBL widgets. Next action: a leak needs to be squashed. Owner: Enn
• Bug 616057: Rebuild NDK5 with PIC. PIC stands for position independent code. If we generate non-PIC, the runtime linker must go through the binary code and replace code locations. Owner: bear
• Bug 668838: Implement improved flow for language choice. This means Firefox will normally only load one locale and hyphenation file during startup. Owner: wesj
• Bug 673253: Delay sqlite usage until first paint. Improve perceived performance by painting earlier. Owner: me
• Bug 673262: Gold linking on Android. Gold is a smarter linker than ld, and can typically generate smaller binaries. And, using LTO, gold can remove even more code. Owner: glandium
• Long term
• Bug 632954: Enable PGO for Android. Using PGO, we can figure what code needs to run at startup and what code runs later and reorder the binary appropriately. Later, we can even generate two different libraries that separate hot startup code from the rest. Owner: glandium

As usual, measuring startup time is generally very tricky. Using wall clock time for a warm startup doesn’t accurately represent real world scenarios. Here are some bugs that might help us with instrumentation:

• Bug 675233: Show when components are initialized. Useful for the bigger picture. This is wall clock time, so it’s important to try to swap out Fennec before starting it up. There are steps in the bug.
• Bug 673258: I/O data for startup using systemtap. No progress to report here.
• Bug 674986: Build profiler for Android devices. This is about getting a custom ROM that includes useful kernel modules, like oprofile and perf.

If you have ideas for improving startup time or ideas for tools, get in touch! Better yet, maybe you’d like to contribute some code. We can be found in #startup on irc.mozilla.org.

You may already be writing good browser chrome tests that properly reset any side effects your test may have caused, but do you always clean up? Instead of manually cleaning up your test after a successful run, please consider using registerCleanupFunction. You can register as many functions as you like, and they are guaranteed to run at the end of the test! I didn’t know this technique existed until recently, so I thought I’d pass it along.

Unfortunately, I’m not aware of anything similar for other mochitests.

Download the Extension
GitHub page

Update: Bugzilla Tweaks already has this functionality.

So, how did we do it? Through a major effort across the Firefox platform team and the front-end team, we split the rendering and processing done by web content into a separate process from the one that handles Firefox’s user interface. Firefox developers internally refer to this split as electrolysis, and you may be familiar with the concept from other browsers like Internet Explorer and Chrome. Furthermore, the content process can asynchronously render more content than is visible so that our main process can quickly pan and zoom by transforming the rendered content appropriately. In the meanwhile, the content process is informed of the new visible region and computes the new rendering quietly in the background.

For this post, I’d like to cover the platform foundation that made this possible for mobile Firefox.

Layers

One of the largest projects completed for Firefox 4 was the ability to quickly render common kinds of transitions and animations by splitting up rendering into separate parts and compositing them together quickly using.hardware acceleration. The layers system is responsible for compositing.

The layers are stored in a tree. A container layer holds child layers, and the leaf nodes are populated by layers that render content, such as thebes layers or color layers. Each node has properties like a transformation, a clip rectangle, and an opacity, which affect the rendering of it and its children. You can see what a node looks like in Layers.h. Applying transforms, clipping, and opacities are the kinds of operations that are straightforward operations for DirectX and OpenGL pipelines, so we can generate these accelerated layers on demand for fast web page animations.

For our desktop platforms, layers are already being composited using hardware acceleration, but we have disabled it for mobile platforms for now. We hope to significantly reduce mobile Firefox’s CPU load in a near-term release through hardware acceleration.

Shadow Layers

Layers are not only useful for fast animations. They also demonstrate a semantically clean break between expensive rendering and simple rendering for web pages. The expensive rendering is done in the content process, and the simple layers compositing is done in the main process. These layers generated in the content process and forwarded to the parent process are called shadow layers. In the main process, we manipulate these shadow layers using translation and scale transformations to achieve the effect of panning and zooming. When the layers are updated from the content process, we carefully compensate for any changes in the layers so that the procedure is seamless to the user.

Our first implementation of shadow layers used sockets to transport pixels back and forth, but we quickly found this was too slow. The main process would spend too much time shoving pixels to and fro, emitting obvious stalls during panning. We now use shared double buffered memory between the processes. The main process manipulates how the read-only front buffer is rendered, while the content process refreshes invalidated content in the back buffer.

Displayports

The final component allows Firefox to render more than what is visible on the screen. Otherwise, there would be no content to render for hundred of milliseconds when the user pans. We render extraneously by setting a displayport, which overrides the visible region and paints the specified rectangle we give it. The web page is none the wiser.

Conclusion

Using these APIs provided by our platform, mobile Firefox is able to give an experience that is responsive and fast. The experience isn’t perfect yet, but we have a solid foundation to iterate on top of.

The majority of this great work was done by Chris Jones with the assistance of Robert O’Callahan and Timothy Nikkel. Without them, this project would not have happened. Thanks guys!

Mozilla is a unique force in the browser market whose primary goal is to keep the web available for everybody. Recently, we acted on our mission statement by taking a stand on the Ogg Theora video decoder. For HTML5 video, Mozilla chose to support Theora (and only Theora) for two reasons:

• Desire: We want (really, really want) an unencumbered video format for everyone.
• Ability: We think we can use our market share to make a difference.

Frankly, this isn’t about idealism or sophomoric zealotry, it’s about ensuring a healthy future for the web. We, after careful consideration, decided this was worth fighting for. I can’t tell you what the future holds for video formats, but Mozilla will ultimately do what’s best for consumers and publishers.

What’s more interesting to me is our ability to cause such a stir. Our stand loses its meaning without our market share, illuminating how important our user base is. In general, take a step back and recall where the web was just 4 years ago. Mozilla and our users played an (dare I say the?) important role in where the web is today. That’s actually pretty amazing for free software with grassroots origins.

I’ve come to see Mozilla in a different light from this video debate. As Firefox users, our choice is not only colored by features, or speed, or extensibility. It’s also about using a browser built by people whose vested interest is, well, everyone. You really are voting with your software, with every vote adding a discrete boost in volume to Mozilla’s voice. For us, it’s about the big picture. So let me gush a little here: thank you, our amazing users <3! For my part I will do my best to repay your choice with a better browser that gets out of the way and lets you get things done.

One other thing: we’ve turned off Flash and are keeping it off for 1.0. We tried hard to get Flash performant, consistent, and stable in 1.0, but at the end of the day it wasn’t up to our standard of quality. At the cusp of releasing, a hard decision was made to cut out a bullet point for the sake of usability. We have a stopgap solution in the works targeted particularly at YouTube (because it’s the one Flash site that works pretty well and adds a lot of value), and we still want Flash in mobile Firefox long term.

1.0, here we come!

Fennec’s kinetic scroller needed some tweaking, though I didn’t start out knowing exactly what it needed. As I played with a few algorithms I eventually came up with three goals:

• Predictability. The same gesture should roughly get you exactly the same distance every time, independent of outside factors like frame skipping.
• Smoothness. Your eyes are good at noticing changes in distance. If a frame or two is out of step, you will notice or possibly even see something unexpected! More on that later.
• Speed. The total time the animation takes should be reigned in; the animation is there to give weight to the content with subtlety, and stay out of the way.

Each goal isn’t so hard in itself, but I found when I focused on one the other two would slip out of my grasp. As far as I’ve seen, only the iPhone really gets it right. You can spin an hour or minute scroll wheel with amazing consistency once you get the hang of it. Android gets it all wrong. The friction is so low that the animation can last forever. If Android misses a few beats while you are dragging your fingers, it will interpret that as a super-fast finger pan and will set your initial velocity to infinity minus one. Android also has poor responsiveness: sometimes on my Cliq I don’t know if I’ve panned until I’ve let go of my finger. By then it’s far too late.

My work focused on changing how we determine the distance moved in every frame of the animation. In Fennec, we keep it simple and assume we can get away with friction being a constant deceleration. Given an initial velocity and deceleration rate, how do we get from our start position to our end position?

Previous solution: Newtonian approximations with fixed dt

Don’t let any of those words scare you if your math is a little rusty. Think of the position of the scrollbox as a function of time. At the beginning, position(t=0) is where the scrollbox was at before moving. At some final time, the scrollbox’s position will have settled to a stop further down the page. Newton’s approximation is just a very simple application of a derivative:

# general application
f(x+dx)=f(x) + dx*f'(dx)
 
# physics application
# note: velocity is the derivative of position
pos(t+dt)=pos(t) + dt*vel(t)
vel(t+dt)=vel(t) + dt*acc

Derivatives tell how a function’s value changes. For this algorithm, a derivative helps approximate a function’s value at nearby places. If I know the velocity at a given time (vel(t)) and the position at a given time (pos(t)), I can make a really good guess about what the position will be at a small time increment from now (pos(t+dt)). Set dt to a fixed constant (like if the position is updating every 15 msecs, 15 msecs might be a good value for dt). So subtract a fraction of the velocity from the position, subtract a fraction of the acceleration from the velocity, and bam! Newtonian approximation. Many programmers have written this algorithm without knowing an iota of calculus just because it’s so intuitive. Maybe Newton and his fancy calculus aren’t so precious after all. You going to take that Newton? Oh, you have to because you’re dead!

Downsides

By fixing dt, the animation is not over until the fat lady sings. And operas last a really long time. Yeah the sets are cool and the singer-actors are amazing virtuosos, but god don’t you get tired of watching the subtexts? It’s like Italian is only capable of conveying shock and melancholy. If my phone is crunching and each frame takes an average of 100 milliseconds, the scrolling animation is going to last more than six times longer than it should! Although holding a note 12 seconds is nothing for an opera superstar, an animation of similar length isn’t acceptable.

Newtonian with varying dt

The first fix I tried is the obvious one. Plug the real elapsed time between frames into dt and problem solved. This is where the reality of programming comes in and shouts “oh no you didn’t” and twists your tidy algorithm into the user experience equivalent of a pretzel. All of the sudden, everything’s jerking around a lot! And oh crap how did I get to the bottom of the stupid-long planet.mozilla.org so fast? All I did was smudge my finger on the screen.

Downsides

Let’s plug in some numbers and see what happens:

50msec elapse: pos(0+.050) = 0 + .050 * 600 = 30 respectable pixels
800msec elapse: pos(0+.8) = 0 + .8 * 600 = 480 I guess that's OK pixels
3200msec elapse: pos(0+3.2)=0 + 3.2 * 600 = 1920 ridiculous pixels

Unfortunately during intensive operations like page load, Fennec can often see three second delays between timer callbacks. This is the antithesis of smooth; it’s possible to completely lose your context of what you are reading. Not only that, but the total distance traveled is now dependent on how much time Fennec spent teleporting goats or whatever the hell it’s doing. This is why I consider good kinetic panning a “slippery” problem; here I’ve fixed the speed problem at the total expense of predictability and smoothness.

Verlet integration

This is a more sophisticated way of calculating the scroll position based on the previous step, with less error. I won’t delve into the details, but verlet integration had the same basic problems as Newtonian approximation did. Ultimately, step-based solutions were not getting me the results I wanted. Taking a step back, I realized I was using approximations of a function that I could easily calculate myself.

Closed form of position: a parabola

If the scrolling animation has a velocity that decelerates constantly, the movement is actually that of a parabola. I don’t want to dive into integration methods here, but there’s an easier way to explain it. If you are a gorilla and you’re throwing exploding bananas at buildings, the arc that your banana makes with deadly grace as it moves through the air is a parabola. The banana initially has an upward velocity, but gravity decelerates the velocity at a constant rate causing the banana to come down and hit unsuspecting office workers, detonating on impact. This motion is analogous to our scrollbox movement over time, except at the peak of the scrollbox’s parabola the motion is cut off.

Here’s the formula:

pos(t) = v0*t + 1/2*a*t^2
vel(t) = v0 + a*t

Now I was getting somewhere. I could calculate the time and position at which the movement is at its peak, when the velocity is zero:

vel(tf) = 0 = v0 + a * t
tf = -v0 / a
 
pos(-v0 / a) = v0 * (-v0 / a) + 1/2 * a * (-v0 / a) ^ 2
pos(-v0 / a) = -1/2 * v0^2 / a

So I now have an equation that gives me exactly what I want: when the animation should end, and more importantly, where the animation should end. Assuming the initial velocity is calculated robustly, I can pan down a page and consistently get the same distance covered every time.

Downsides

This formula nails down the animation’s speed and predictability as best as anything can, but smoothness has suffered. To add insult to injury, our mobile VP Jay noticed something bizarre: the scrolling sometimes sped up in the middle! I checked my algorithm with a data dump:

time 30 distance -50
time 72 distance -67
time 119 distance -70
time 167 distance -67
time 215 distance -63
time 263 distance -58
time 310 distance -52
time 358 distance -49
time 405 distance -44
time 463 distance -48
time 510 distance -34
time 558 distance -30
time 606 distance -25
time 655 distance -21
time 703 distance -16
time 750 distance -11
time 798 distance -7
time 856 distance -2

The numbers look pretty good, but unfortunately the time dumps are in Javascript and don’t reflect exactly when the screen is repainted. If the times between the scroll call and the repaint are constant, the graph would just shift (and still look like a parabola). My theory is that this time offset varies in a specific way per animation causing the velocity hump.

Parabola with time mean

I then fudged time a little, like I imagine the protagonist in Braid would do in a similar spot. I wanted all the smoothness of a fixed dt solution but with the ability to control how long the animation takes like in varying dt. The velocity hump also needed to be flattened out. After some experimentation, it hit me that I could literally blend the two solutions together with a time average:

time = (elapsed time + elapsed frames * update interval) / 2)

It’s immediately obvious that the animation can last no longer than two times the “ideal time” the animation should take (plug in final time for time, 0 for elapsed frames as a worst case, and solve for elapsed time). In contrast, if the animation is lagging behind the ideal time, the frame skipping will be blended in with a smoother animation. If the above formula is made to be a weighted average, the trade-off between smoothness and total animation time can be tweaked with predictable results.

Putting the algorithm to the test, I noticed that the velocity hump is smoothed out by the time interpolation as well, so I had finally approached a robust kinetic panning algorithm that hit all three of my goals.

Final thoughts

Because I’m fortunate enough to be at Mozilla, you can find the distilled version of my efforts in code. If you’re a Javascript hacker, you’ll find this a satisfying thing to play with because you don’t really need to know a lot about Fennec beforehand. It might be a great way to get into Fennec development (here’s how to set up a build; ignore anything Maemo-specific to build on your desktop).

This problem required lots of neat stuff: basic calculus, data analysis, attention to detail and polish, a surprising roadblock, and a neatly contained end result. These are the kinds of problems that keep me excited about programming.