Below is the schedule for the Browser Miniconf on Monday, 16 January 2012.
|10:40|| Crash Reporting at Mozilla
|11:20|| Notes on Reducing Firefox’s Memory Consumption
Robert O'Callahan, Cameron McCormack, Silvia Pfeiffer, Mike Lawther, Shane Stephens
|13:20|| There’s something on my ARM
|14:00|| BrowserID: distributed identity in the browser
|15:10||BREAK (Afternoon tea)|
|15:40|| Web Standardisation – how browser vendors collaborate, or not
|16:20|| Implementing CSS3 calc() in WebKit
|16:40|| Browser Accessibility in Linux
Alice Boxhall and Jason White
Every day, Mozilla collects three million Firefox crash reports from around the world. The data in these reports drives the bug-fixing priorities of Firefox engineers, and is critical to understanding the stability of our platform. In this case study, I'll describe the challenges we've faced, the types of questions the system can be used to answer, and the architecture and infrastructure we use to process, store, and analyze approximately 110TB of crash reports using Python, Hadoop, PostgreSQL, and a few other things thrown in for good measure.
All the software we use in our stack is Open Source, including the Breakpad client embedded in the browser, and the Socorro collection and reporting system. Other projects and companies are now using the Breakpad/Socorro combination.
Laura Thomson is an Engineering Manager at Mozilla. She is the co-author of “PHP and MySQL Web Development” and “MySQL Tutorial”. She is a veteran speaker at Open Source conferences world wide.
Nicholas Nethercote · Slides
I started the MemShrink project in June 2011 with the aim of reducing Firefox's memory consumption. In this talk I will discuss various improvements made and their effect on Firefox's performance.
Joel Stanley · Slides
How much power does it take to load your website? Come along and find the answer!
Chromium, an open source browser developed by Google, has brought a new level of speed and security to web browsers, but what is the cost of these new features? Today's netbooks are required to be low powered, and the new ARM-based netbooks will push power budgets even lower. Chromium uses WebKit, the same rendering engine used in low power devices such as the iPhone and Android devices. Does this low power herritage carry over to Chromium? How does Chromium compare to other desktop browsers?
In this talk I will cover my work porting Chromium to the Beagleboard, a ARM development board. It will cover the challenges faced, the work that has been done track memory and power usage, and the patches that have resulted from this work. Look forward to a demonstration of Chromium running on the Beagleboard, and a look at the impact on power usage that browsers and modern web applications have.
Joel is a embedded hardware and software hacker, who has been seen at LCA over the past decade playing with OLPC XO laptops, rockets, balloons, Arduino and quad-core FPGA based gameboy emulators. He hacked on the Linux port of Chromium as part of his second stint as a Google Summer of Code student.
Identity on the web is a complete mess. While there have been a few attempts (like OpenID) at solving this global problem, most sites out there either ask you to remember a unique username/password combination or choose to entrust a popular third party (such as Facebook or Twitter) with the task of holding user records for them. This sucks.
BrowserID is the open source solution we have been waiting for: a new web login mechanism with strong privacy protection where your browser is the trusted intermediary. Backed by Mozilla, it is based on the simple idea of a user proving that they own an email address, with a generous sprinkling of crypto under the hood. What makes this solution different is that it is designed to be simple (both for users and developers), distributed and privacy-protecting.
This talk will answer three questions:
Robert O’Callahan · Demos
Mozilla wants to support flexible processing of real-time media in Web apps. We want to tie together various media sources --- microphone and camera input, real-time network streams, <audio> and <video> elements, and more --- and let JS work directly on audio and video data to produce whatever effects the Web author wants. We want it to work reliably, without glitching and without loss of synchronization. I'll describe some proposed Web APIs for doing this, and how they're being implemented in Gecko.
Silvia Pfeiffer · Slides
The basis of the Web is interoperability. Five browser vendors are involved in the standardisation of HTML5: Opera, Mozilla/Firefox, Microsoft/IE, Apple/Safari, and Google/Chrome. With the development of HTML5 and the large amount of new features that are being introduced, interoperability is not always a given. Not only do browsers implement new features at different speeds, they also disagree on what functionalities should be implemented, and frequently fail at interpreting the specification in the same way. The opportunity of HTML5 is innovation, so we want browsers to implement and show off new features. But at the same time we want them to be solid and usable and, above all, interoperable. So, how do we solve the dichotomy between progress and interoperability?
Silvia is involved with the standardisation of HTML5 video features both in the WHATWG and the W3C and is happy to share some experiences and lessons learnt from the war front of Web standardisation.