Wondering what the Windows 8 Metro UI will look and feel like? See the great work of Stephen Horlander and Yuan Wang here:
In case you missed it, Harvey Anderson - Mozilla General Counsel, just published a great blog post about what's going on with Windows on ARM support.
Without competition there is no innovation. You can read the post here:
Windows on ARM Users Need Browser Choice Too
To be clear, we will still have a Metro browser as previously blogged about on non ARM platforms.
To see why ARM matters, see Asa's post here: Why Windows Classic on ARM Matters
Two weeks ago, the Firefox team got together for a work week in Toronto. It was amazing. Walking through a room with that many excellent people doing excellent things was inspiringhumblingunbelievable and the hits kept on rolling.
The combined mobile and graphics teams cut the beta blocker list for Fennec Native in half. The desktop team banged together a working prototype of sign in to the browser. The firefox tech leads worked with product and project management to nail down the kilimanjaro bug list for desktop. Madhava gave a great talk about the future of Firefox UX. I would have scored it as a strong success based on those outcomes alone.
And then this happened:
I know I’ve missed things. I know some of it is still being written up. In fact, I’m not even the first to write a round up post. Here’s Finkle doing the same, and dcamp, and cwiiis.
FX-Team is big enough these days that it’s quite an undertaking to get us all together in one place. But man, it’s phenomenal when we do.
On Monday, May 7th, 2012, there will be a public call to discuss the Web Cryptography API. Via the W3C public-webcrypto mailing list:
Join us next Monday 7th of May, from 19:00-20:30 UTC (3:00pm-4:30pm Boston local)
* Zakim Bridge +1.617.761.6200, conference 27978 (“CRYPT”)
* IRC irc.w3.org:6665 #crypto
Please dial in if you would like to discuss or find out the plans for this important specification.
Last week fx-team got together in Toronto to talk about what work we’ve done, the work we have planned for the rest of the year, and to kick start some work on Kilimanjaro-related bugs. We had a round of lightning talks on Wednesday, and I gave one entitled “you should review code”. It’s a little bit audience specific – the call to action at the end of the talk is targeted to core Firefox contributors, but the earlier points about effective code review is relevant to anyone who reviews code, even outside of Mozilla. I posted my slides from the talk, as well as a video (WebM, also available on vid.ly).
Every year the Firefox team gets together for a week of working together. Last week I attended the 2012 Firefox work week in Toronto. As part of the work week a number of people did a talk on various awesome topics.
Here is a talk I did on Windows 8 and Firefox:
The slides for the talk can be found here. The slides were built in HTML5 from this slides sample at html5rocks.com.
Last week in Toronto, the Firefox team had a work week. One of the activities was a session with lightning talks about various aspects of Firefox development. I gave a lightning talk on how to use Olli’s about:cc add-on to find a leak in the front-end code, understand it and fix it. I tried to emphasize the importance of not creating leaks not only for memory use but also for the browser’s responsiveness, and preparing for it was a good exercise as it helped me learn more how to use it myself.
Here is the video for it, and the awesomely-formatted slides and links are here.
As an alternative, Honza created a similar add-on that uses the same underlying API and has a more user-friendly UI. It’s called about:ccdump and you can find how to use it in his blog post.
Shameless plug:
if you liked the subject and are interested in helping: both about:cc and about:ccdemo uses the cycle collection API to get the cycles data and analyze it. It would be great if this API was also used as part of our testing framework to analyze the data after a test run and help prevent new bugs being introduced. If you would like to work on it, this is filed as bug 728294.
This past week the Firefox front-end team had a work week in Toronto, and had the chance to give a lightning talk about the new Fennec Native UI. This talk is geared towards developers who are already familiar with working on desktop Firefox, but it will give anyone a quick overview of how our mobile front-end is built. I also made the slides available, since they include some links.
Update: Here’s a direct link to the video.
We've made steady progress over the past 3 weeks on Firefox for Windows 8 Metro.
Platform Integration:
We have secondary tiles working, you can pin secondary tiles temporarily via a menu item. Like Internet Explorer 10, you can pin any number of sites to your start screen. When you click on the secondary tile, it will load the pinned site in Metro whether or not Firefox is already open.
We also hooked up the Windows 8 settings contract which means you can access Firefox preferences via the Windows 8 Settings charm.
Work is in progress for the Play To contract and the print contract.
Accessibility and Input:
We now support the soft keyboard which is especially important for when a keyboard is not attached and you are using a touch device.
We are also working on hooking up Windows 8 touch events, Windows 8 gestures, and W3C DOM touch events.
Core Changes:
We added support for XAML interop. This means that we can overlay XAML controls on top of our XUL / HTML rendered DirectX surface.
We don't know all of the use cases for this yet but we'll probably use this for at least the app bar.
The app bar is a bar of controls you can slide up from the bottom edge or your screen or popup via right click.
We also figured out PRI files in Windows 8. PRI files is an undocumented file type for storing resources.
We were using another program's PRI file until recently.
We fixed up some memory leaks on shutdown as well; these were not introduced but happened on Win32 Fennec which we are based on.
Approval for Current Plan:
We're hoping to get approval for the tentative plan which includes moving over the work to the main mozilla-central repository. The mozilla-central repository is where Nightly builds are made.
Up until now we've been developing and landing code on the elm repository.
Open Questions:
There are still several open questions, but the one we've been investigating during the period of this update most is how to handle compiling with the Visual Studio 2011 Beta tools and still have support for running those binaries on Windows XP.
To compile Firefox on Metro you have to use Visual Studio 11 Beta, but VS2011 cannot build binaries that are compatible for Windows XP. In bug 744942 we're discussing either patching the CRT, compiling a DLL with the WinRT code separately (2 compiler build process), or packaging a Windows 8 installer separate from the existing Windows installers and updates.
In any case, we will be supporting Windows XP in the same way we always have. I'm personally disappointed that VS 2011 drops XP support given that Windows XP has extended support up until April 8th, 2014.
Firefox Work Week:
Perhaps some of the most exciting work so far will happen this week coming up.
On Monday I'm heading to Toronto for the Firefox work week. One of the hacking goals during this week is to get some significant initial work done on the UI for Firefox on Metro. This work will be based on the UX work from Stephen Horlander and Yuan Wang. In the initial work we'll have the tab bar and address bar on the top and site specific options such as pin site on an app bar accessible from the bottom edge.
“Far out in the uncharted backwaters of the unfashionable end of the western spiral arm of the Galaxy lies a small unregarded yellow sun. Orbiting this at a distance of roughly ninety-two million miles is an utterly insignificant little blue green planet whose ape-descended life forms are so amazingly primitive that they still think digital photo filters are a pretty neat idea.”
A couple of years ago, I made a simple addon to remove the icons from bookmarks in the bookmarks toolbar in Firefox. It was a fun hack, but I knew then that it wasn’t the right way to do this. Nevertheless, easy is the enemy of perfect (or something) so I kept on using it, and AMO kindly kept on updating it when new versions of Firefox were released.
All was right in the world.
Then this week, some changes to Firefox’ toolbar caused the add-on to stop working. It still works if you do the enable-disable dance in the Addons Manager, but that’s no way to live everytime you restart your browser or open a new window. Something had to give!
To banish your bookmarks icons forever, add the following to your userChrome.css file (it’s in your Profile Directory‘s chrome subdirectory). If it doesn’t exist, create a new file named userChrome.css and add:
scrollbox#PlacesToolbarItems > toolbarbutton.bookmark-item > .toolbarbutton-icon {
display: none;
}
Save the file, restart your browser and your icons should be gone forever.
I've been looking for high leverage ways to contribute to Mozilla now that my spare time is virtually non-existent. Luckily, mediawiki-bugzilla is gaining a lot of traction at Mozilla and looks to be really helping out. Seeing as I started the project I decided to add some much needed features! These aren't rolled out on wiki.mozilla.org yet but they will be soon (I have a couple of little things to finish first). Code can be found in my github repo (yes, I am currently working to rectify the mozilla/personal dual repo situation).
First up, a minor yet helpful addition. When showing bug data in a table, the rows are now colored by their status. Spiffy.
Screenshot of colors
And the code:
<bugzilla>
{
"whiteboard": "[mediawiki-bugzilla]"
}
</bugzilla>
A couple of notes:
Once people started using the extension the first question was "can I choose which fields to show and hide?" With this change you specify fields in the "include_fields" setting of BZ REST API options as you normally would. Mediawiki-bugzilla will then a) only fetch those fields and b) display those columns.
Custom fields selected and columns shown
And the code:
<bugzilla>
{
"whiteboard": "[mediawiki-bugzilla]",
"include_fields": "id, summary, whiteboard, status, resolution"
}
</bugzilla>
A couple of notes:
Large lists of bugs on a wiki page can get a bit unwieldy. It was requested to be able to sort by columns, search through the results, and paginate to keep vertical space to a minimum. I beefed up the support for client side jquery/Datatable rendering.
Administrators can turn on client-side jquery table support
And the code:
<bugzilla>
{
"whiteboard": "[mediawiki-bugzilla]",
"include_fields": "id, summary, whiteboard, status, resolution"
}
</bugzilla>
A couple of notes:
You can currently make bar graphs by setting type="count", display="bar", and including Bugzilla REST API /count parameters. I actually had support for other chart types stubbed out and decided to implement pie charts.
Pie charts of three different sizes
And the code:
<bugzilla type="count" display="pie">
{
"whiteboard": "[mediawiki-bugzilla]",
"x_axis_field": "status"
}
</bugzilla>
<bugzilla type="count" display="pie" size="medium">
{
"whiteboard": "[mediawiki-bugzilla]",
"x_axis_field": "status"
}
</bugzilla>
<bugzilla type="count" display="pie" size="small">
{
"whiteboard": "[mediawiki-bugzilla]",
"x_axis_field": "status"
}
</bugzilla>
A couple of notes:
We can make tables, we can make bar charts, and we can make pie charts...why not a simple list? While I was adding support for pie charts I added a simple unordered list display.
Bugs can be displayed in a list
And the code:
<bugzilla display="list">
{
"whiteboard": "[mediawiki-bugzilla]",
"include_fields": "id, summary, whiteboard, status, resolution"
}
</bugzilla>
A couple of notes:
It's not perfect, but I've put in a little more support for detecting errors. If the JSON is invalid or your "display" and "type" combination are invalid you will get a message saying so.
Invalid JSON input now shows an error
And the code:
<bugzilla type="count" display="bar">
{
"whiteboard": "[mediawiki-bugzilla]",
"x_axis_field": "status",
}
</bugzilla>
A couple of notes:
“I’m going to be a shrill and rigid idiot.
“I’m going to blindly refuse to listen to contrary opinions. I’ve already made up my mind, and will invent reasons why alternatives won’t work. Most importantly, I’m going to get this done my way, regardless of whether it’s actually the best decision, or even a good idea.”
You’ve never approached a problem that way. No one has.
But you’ve probably told yourself that story about someone else. You’ve been on the receiving end of one of these mindless and petty tyrants, in a bug or a mailing list or a standards body, and you’ve decided that you were seeing a rigid idiot in action. I know I have.
My philosophy of science prof used to talk about how the two important tests of a scientific model are whether it allows you to make accurate predictions, and how well it helps you discover new things. This matters more than its elegance or its intuitive appeal, though a really nice model has those, too.
The Rigid Idiot model does, for better or for worse, predict. It predicts more rigid idiocy, and people using that model to inform their interactions are likely to get precisely that. But it’s a pretty hollow model for generativity; it doesn’t help you make progress.
Here’s an alternate model:
Stress response pre-dates our neocortex, and outranks it. It is wired more deeply into us than language, much less rational discussion. And it has predictable effects. A person under stress (personal, professional, social, physical) will lose patience more quickly, anger easily, resist change, and consider fewer alternatives before making decisions. It’s an ancient, optimized cognitive path: less waffling when there are lions nearby. That it impairs our ability to function in this 10,000 year old thing called ‘civilization’ is evolutionary postscript.
You get to choose which model you bring to a conversation. When you assume that the person you’re dealing with is acting atypically, from point-in-time stress instead of born-in idiocy, you give yourself follow-up questions to ask about timelines, or conflicting pressures, or hidden assumptions. You give yourself ways to understand motivations, and implicit guidance about tone.
Not every asshole is a stress response waiting to be defused, but I swear to you that the single greatest improvement you can make to your success rate with these conversations is to switch models. I have seen people turn on a dime once their stressors are addressed. Suddenly there are lots of solutions, and confrontation turns to collaboration. It’s like a god damned secret decoder ring, to be honest.
With practice, you may even start to recognize the descent into idiocy in your own interactions, though it won’t make you immune. This is old, lizard-brain stuff. Like drunkenness, you can get better at detecting it, but you can’t think your way out of it. And, as with drink, my hope is that if you see someone a little worse for wear, you remember that it’s fleeting. Give them some time to sober up before assuming that’s who they really are.
I was feeling a little bit ornery today, and decided to take a look at unowned reviews in Bugzilla (aka patches with a review request “to the wind”, instead of requesting review from some specific person).
After a bit of head scratching to figure out _how_ to get a list of such bugs through the search form, I gave up and use Teh Googlez to get my search query.
When I started there were ~130 requests (in ~110 bugs) across all of Bugzilla. Surprisingly, many of the requests (maybe 2/3rds?) were in bugs that were already resolved fixed/invalid/dupe/wfm, and were thus easily cleared out — along with a comment to take action if there was some non-obvious reason to keep the patch active. (And I use the word “active” loosely as most of these patches were _years_ old.)
For the patches in bugs which were still open, I generally assigned to a reviewer I knew was active in that area (to either close the bug out, perform a review, or reassign to someone else). In a few cases, where patches were really ancient (e.g. 6+ years waiting for a review!) I cleared the review and asked that the patch be updated or bug closed. Reviews of that vintage are simply not useful, and stand in the way of driving this list of reviews to Zarro.
Currently, there are now ~35 unassigned review requests (in ~25 bugs). Most of those are in in Rhino/Tamarin or addons.mozilla.org, and I wasn’t sure what to do with them. I’ll ask around this week.
Progress.
Lately, Asa Dotzler posted to dev.apps.firefox regarding the download size of Firefox:
“This evening I noticed that my full win32 mar update for Firefox was 21MB. That caused me to look at what our full win32 installer size was. I was a bit surprised to see it’s up to 17MB. When we shipped Firefox 1, our Windows installer build was 4.7MB. [...]
Firefox 12 is a 16.1 MB download.
Firefox 4 was a 12.0 MB download.
Firefox 3.6 was a 7.7 MB download.
In less than three years we’ve more than doubled in size. (fuller chart here http://grab.by/cSHA)”
While there’s no doubt that adding new features and supporting new platforms are good reasons for increasing the build size it’s definitely a metric that impacts users. It hits them the hardest when downloading Firefox the first time, especially with slow internet connections. It still hits them every time we provide application updates.
To better illustrate the steady growth over the last few years I created http://arewesmallyet.com/. It’s updated daily, shows differences between nightly builds and links to the corresponding changelog if one would like to investigate the cause of increasing build sizes.
While this surely isn’t the most important battle we have right now I hope this will turn out useful to anyone willing to pick this up and tackle some build size optimizations.
Data: http://arewesmallyet.com/files/data.json
GitHub: https://github.com/ttaubert/are-we-small-yet
You may already know the story of how I became a Firefox contributor. Back in early April of 2011, having volunteered full-time for three months (a rather short time compared to other core contributors), I was given the opportunity to start as a paid contributor working for Mozilla.
Over the year I met a lot of great people and had the chance to visit our awesome offices in Mountain View, San Francisco and soon Toronto. I attended JSConf.eu, MozCamp and FOSDEM, with the JSDay yet to come.
But Mozilla isn’t about traveling or attending conferences. It’s about passion for open source, passion for the open web. Working for a non-profit, where decisions are driven by reason and mission, is something that not many software engineers will ever experience in their whole professional career. That’s only one of the reasons I’m really glad to be a part of the global Mozilla community.
Inspired by Lucas Rocha I’ll end this post with some neat statistics about my contributions to the Mozilla project (we Germans love statistics):
I fixed 223 bugs and reviewed patches for 116. I pushed 417 changesets, 110 of them being merges between trees. I changed roughly 1367 files (31862 insertions(+), 19081 deletions(-)).
I was at IKEA the other day (for the first time ever!), and juuust as I was about to make it out the door with minimal expense I saw their assortment of fake flowers, and knew what had to be done.
Adds some nice color to my desk at work, when I get bored of it I’ll probably move it so some conference room. :)
Make your own!
1 REKTANGEL vase.
19 SNÄRTIG flowers (5 blue, 1 yellow, 3 yellow-orange, 7 orange, 3 red).
1 red SMYCKA flower.
I had the red and black filler sitting around from some other store, but it’s easily available. (Note symbolism in Firefox being anchored in the rock of Mozilla.)
My cat, Munchkin, is not available for sale. Sorry.
(…i can haz flowers?)
The Firefox Roadmap lists a 2012 Q2 goal of providing a working Firefox prototype on Metro.
As of last week, we have a working browser in Metro. It currently looks and feels the same as the Android browser. You can navigate the web, create tabs, bookmark pages, build history, retain cache, adjust preferences, and more.
I don't consider that 2012 Q2 goal met yet, we still have some open design questions, and a ton of platform integration work to do.
Early tile design from Bug 735008 - design still in progress
Our prototype in its current form is based on the Fennec XUL code. We used to use Fennec XUL on Android, but changed to a Native UI on Android for startup performance reasons. We haven't seen the same types of startup performance problems we've had on Android yet, even on VMs.
Firefox Metro screenshots - UI will be changing, Metro specific UI guidelines and Mozilla UX work feedback has not begun yet.
We're currently writing up a proposal on how we should proceed with the Metro work and we will post it on dev.planning. If we are able to keep using Fennec XUL we'll be ahead of schedule, but I anticipate some serious discussions once that is posted.
Since our prototype is based on Fennec we have a multi-process capable browser for free. Currently there is only one content process, but I believe the longer term plans are to increase that.
Jim put together an installer this week as well so that UX can get hands on with Firefox on Metro and provide design feedback and guidance.
Platform integration
As of this week, we have a lot of Metro platform integration working.
We have Metro snap working, you can snap another Metro app to the right or left of Firefox and continue browsing.
We also have HTML file input controls tied up to the Metro file picker. We've implemented support for opening a file, opening multiple files, and saving files in Metro. Unlike a normal sandboxed Metro application, the user can select any file from the computer. The picker also allows you to select files shared by other applications.
We also implemented the Windows 8 search contract, you can use the Search Charm from any screen on Windows 8. If you enter a URL, it will be loaded. If you enter anything else, it will be searched in your default search engine.
We also implemented the Windows 8 share contract, you can use the Share Charm from any Firefox page to share that page to another application. Once you select the Share Charm it will list the applications you can share to, for example: Mail, Twitter, or Facebook.
Searching for the text "Firefox Windows 8" and Sharing while playing BrowserQuest
Metro file picker after clicking on an input file form control
Why Windows 8 Metro support is really important
If a browser is awesome on Metro, the only way to use this awesome browser in Metro is for it to become the default. If a browser is default on Metro, it will also be default on the Desktop.
If a browser does not support Metro, it is seriously at risk of losing the default browser status, and therefore significant market share. A browser without support for Metro, if default, would be taking away a Metro browser completely from the user's computer.
Even if a user spends most of their time in the Desktop interface, having a really good Metro browser may be enough for the user to change their default browser. A browser with great Metro support can gain significant browser market share for this reason.
It is extremely important that we deliver an awesome Firefox experience on Metro, one that is tightly integrated with the platform, fast, and feature rich. Windows is by far the platform with the most users and which has the biggest effect on market share.
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.
In a recent thread on dev.apps.firefox, someone suggested we shift our 6 week release schedule to avoid Microsoft Patch Tuesdays, or other unfortunate timing coincidences. I’m not announcing any changes to our release schedule, but I did make a point there that I want to repeat a little more broadly (and with emphasis added):
Let’s go back to first principles for a minute. Releasing every 6 weeks is a cadence we set for ourselves to satisfy several constraints. Constraints like:
- Delivering security and stability fixes on a regular basis.
- Getting new features out to our users promptly, and being able to iterate on the feedback we receive.
- Containing the amount of code change and change-interaction that happens per release.
- Giving ourselves time to react to problems discovered before release (on Nightly, Aurora, or Beta)
Releasing daily wouldn’t work very well; it runs afoul of the last constraint. Releasing yearly would hurt us on the first 3. But the constraints are just about as well satisfied by 40 days or 44 days as they are by 42 days.
We derive great benefit from our current schedule. It satisfies these constraints much better than the old, monolithic release model did. But that is not to say that we should treat 42-day cycles as inviolate. We will adjust. We will add or drop days, or add or drop weeks when we need to. We’ll be respectful of the fact that other people build plans around our plans, and try not to alter schedules without notice, but at the end of the day we’ll do right by our users first and foremost.
Right now we’re not looking at moving the release to another day of the week (Tuesdays do have some nice properties), or adding a skip week somewhere to take us off-cycle for the next patch Tuesday, but those discussions are absolutely on the table when they make sense.
No religion here. 6 weeks is a nice spot in the constraint space, not a law. The first time we miss it, people will talk about us “slipping,” but the tail doesn’t wag the dog here. Firefox still ships when it’s ready.
I will answer some commonly asked questions relating to the series of tasks that make up the silent update project in this post.
Will silent updates first land in Firefox 13?
No, the silent updates work is a series of tasks, and some of it has already landed.
Three of the biggest pieces of work in this new series of tasks are:
Add-ons default to compatible landed in Firefox 10.
The Mozilla Maintenance Service fixes the problem of updates not being truly silent on Vista and above due to UAC prompts. Silent updates will occur without this UAC prompt as of Firefox 12.
Firefox 13 (or possibly Firefox 14) will have background updates.
Are background updates the same as silent updates?
No, background updates is a task that makes silent updates better, it is a component of the silent update project.
In Firefox 12, updates will be silent, but they will still be applied at startup. Meaning when there is an update, it will take slightly longer to startup.
In Firefox 13 (or possibly Firefox 14), updates will be applied in the background while Firefox is running. Meaning when there is an update, it will take about the same amount of time to startup as normal.
Will Firefox force me into silent updates?
No, you have always been able to configure how you get updates.
Simply go to: Options -> Advanced -> Update.
These options are not changing, in fact you will have more control over how your Firefox updates as of Firefox 12.
You can choose to:
Furthermore, you can specify whether or not to use the Mozilla Maintenance Service to apply the update. If checked on, you will not have a UAC prompt.
If I uninstall the Mozilla Maintenance Service will the next update just reinstall it?
No, the Mozilla Maintenance Service will only be installed once. If you uninstall the service after that, it will never be installed via an update again.
Will Firefox silently install other things than updates?
No, the only things that will be silently installed, if the silent update option is on, are Firefox updates. The updates cannot be tampered with, if they are, they will not be installed.
Will the Mozilla Maintenance Service slow down my computer?
No, the Mozilla Maintenance Service will take up a small amount of disk space and only be run during an update. If an update is not in the middle of being applied, the service will not be running and will have absolutely no effect on the performance of Firefox and your machine.
Will the Mozilla Maintenance Service make updating less secure?
No, we have worked closely with the security team to ensure this feature was delivered securely. Firefox will only apply updates issued by Mozilla designed specifically for Firefox.
Is updating more often less secure?
No, if you are not updating your browser, then you do not have the most recent security fixes. These are the most dangerous security problems because they are well known and can be exploited.
Will I see the effects of the silent update service in Firefox 12?
No, although the Mozilla Maintenance Service will first be installed in Firefox 12, users will not experience the benefits of the service until the first update after Firefox 12.
The update that installs Firefox 12 will install the service, and so the service itself can't be used to install that update.
The next update after Firefox 12 may be Firefox 13 or may be a minor update after Firefox 12.
Last week we got the whole DevTools group together in beautiful, sunny London England to hang out and hack on a few things. Sunny? Yeah, unexpected, but made for some great picture taking.
At the risk of saturating Planet with developer tools-related updates, there was some pretty magical stuff happening.
Our own Debugger task force put together the start of something wonderful. It’s a very early prototype at the moment, but with a bit of bug filing and polish, I think we’ll be able to get it into something that’s functional and not hard to look at in the next few weeks.
stay tuned…
Since everyone loves not having to look at tbpl, I'd like to point out some basic hints to make mozilla-inbound sheriffs happier. For any questions, or if you need help with the trees, ask to a sheriff in #developers IRC channel.
Finally, thank you for all the appreciations that are daily sent to the sheriffs for their hard job, and all the help in monitoring, starring and backouts.
I’ve made some additions to the list of Firefox reviewers:
These guys have been living by and helping promote the Firefox review guidelines for a long time already, so it’s about time that I get around to recognizing that officially. You should ask them for review next time you’re patching Firefox code!
This post is a continuation of the Windows 8 status update first started on this blog post.
We're now past the hardly documented parts of development we were fighting with last week, and things are really starting to heat up. From here, most WinRT development topics should be nicely documented because they are now similar to any work done in a C++ Metro application.
We're keeping organized via an etherpad similar to how the snappy project stays connected. Please ping someone on #windev on IRC if you'd like the URL.
Languages we'll be programming in
We're moving ahead with C++/CX and dropping down into WRL when needed. It is still possible that we will one day port the C++/CX parts to only WRL.
In the end though, with C++/CX you get native code, code that is 10x less the size, and code that is less prone to leaks. Less code means less to maintain and faster innovation. C++/CX is also documented and supported a lot better than WRL.
We have a XAML window and we use DirectX to paint to it taking up the entire area of the screen.
Development milestones
This week Jim Mathies was a rock star and made significant progress in many areas:
This week I spent some of my time finishing an old project and the rest on Windows 8 work:
HWND and instead has a CoreWindow, so extra new code was needed inside the graphics module.
In particular I added most of this new code in gfx/thebes and in gfx/cairo. We don't have support for the Azure back end yet. The new code added in the graphics modules does not use C++/CX.Firefox on Metro will not simply be Firefox desktop copied into the Metro environment, we are embracing the framework instead of fighting it.
How to get the development environment setup yourself
The code for this project is happening in the elm branch, you can see the changelog and checkout the project using hg here. The metro subfolder contains our research but most of the new code is going in widget/windows/winrt.
We're currently compiling and working with a fennec mozconfig setup with the following options added:
ac_add_options --enable-win8metro
ac_add_options --with-windows-version=602
The option --enable-win8metro adds in the -ZW flag in the widget/windows/winrt module only, which makes it so C++/CX code is allowed.
This LIBPATH environment variable must also exist.
UX milestones
Stephen Horlander started work on the Metro splashscreen and tile. You can see some experimentation on the tile and splashscreen here.
I added these resources into the elm repository, it's definitely more exciting to develop when you click on a meaningful tile and see a cool splashscreen.
New contributors
Several developers have expressed interest in helping the project including Tim Abraldes, Wes Johnston, David Woolbright, Burak Yigit Kaya, and Berker Peksag. I'm excited to have more hands on the project in the coming weeks.
Next development steps
Now that we have event handling and thebes hooked up, we should be pretty close to getting something resembling a browser. We're still very early in development but we're making great progress.
Meetings
We didn't have a meeting this week because we were actively keeping each other up to date on #windev on IRC.
Next update
I'll be away next week so probably won't write another update for a couple weeks. Feel free to email me if you'd like to get involved.
I am totally enjoying the Mozilla Memes blog. Hilarious. I just submitted one tonight that I made a while ago. Makes me laugh every time.
Also, when heard about the blog I couldn't help but think of this amazing video that was making the rounds when we started the new release process:
http://www.youtube.com/watch?v=kq8s-Rubs5w
Happy Friday!
We quietly shipped Firefox 11 with a bunch of performance fixes that both reduce the amount of memory that Firefox uses, and improve the responsiveness of it’s user interface.
These types of changes are not easy to talk about. Often they’re very technical, and meaningless to anyone but the developers involved, which is probably why we usually don’t enumerate them in the the release notes or other public announcements. “Firefox is 74% faster when you open menu X, and twice as fast in some garbage collection scenarios!” Yeah, not an eye-popping headline. We could do a lot better in communicating these improvements in broadly meaningful ways though – nice graphs or some competitive site like arewefastyet would help a lot. But until then, here’s a short summary of the improvements in Firefox 11. And if you know of other performance fixes that don’t fall into the categories below, please add them in the comments!
The Memshrink project has been going for quite a while now, led by Nicholas Nethercote. He blogs weekly updates on the project’s activity. According to Bugzilla, there were 29 memshrink bugs marked fixed during the Firefox 11 development cycle – four of which were P1, or very high priority. Some of the fixes were related to tools and detection methods, but many are actual reductions in memory use. The changes that made it into Firefox 11 include fixes for detected leaks, removing of zombie compartments, lazy-loading data, reducing the size of some caches, reducing memory used while scrolling, and many more.
The Snappy project started last December, and is run by Taras Glek. Its aim is to improve the responsiveness of the Firefox UI. Taras has been posting weekly updates on Snappy activity on his blog. Bugzilla shows 15 snappy bugs marked fixed during the Firefox 11 development cycle. The project had just started, but there are still some significant wins in this release! Firefox 11 includes reductions in queries in the bookmarks system, reduced preference lookups, faster data collection for session restore, and various improvements in the DOM code.
While it’s not related to performance, I do want to call attention to something that many people don’t seem to know: In Firefox 10 (yes, the previous release) we stopped marking most add-ons incompatible when you upgrade. That means that a LOT more of your add-ons will continue to work when you upgrade Firefox from here on out. The only add-ons that still require compatibility bumps are those that have binary components, since they need to be recompiled against the current version.
As of Monday of this week, development work began on Firefox for Metro.
A bit of background on Windows 8 Metro and Firefox
It turns out that on Windows 8 there are 3 types of applications:
Firefox will fall into the third category, meaning you can run Firefox as a desktop application, and you can run it as a Metro application. Supporting the Metro side of things will require a lot of new code, so this is a very large project.
Unlike Metro applications, Metro style enabled desktop browsers have the ability to run outside of the Metro sandbox. Meaning not only can we build a browser, but we can build a powerful browser which gives an experience equal to that of a classic Desktop browser.
Metro style enabled desktop browsers have access to most Win32 API and the entire new WinRT API.
Unfortunately a browser can only participate in Metro mode if it is the default browser. So if Firefox is not the default browser on a system, you can't use it in Metro mode. This is a decision made by Microsoft.
The Firefox Metro enabled desktop browser can be, and will be included and packaged in the traditional way. I'm not certain if it will be allowed on the Windows store or not since it is not of Metro application type.
Languages we'll be programming in
We will be using the Windows Runtime C++ Template Library (WRL) which is similar to C++ / ATL.
We may also be using C++/CX which does compile down to native code but has some non-standard C++ extensions that allow for code to be about 1/10 the size.
Our hesitation in using any C++/CX code is that it will definitely require a new build environment. Personally I think it would be worth using C++/CX in the long run. WRL and C++/CX code can freely be mixed even in the same source file.
The GUI will be made mostly by painting to DirectX. XAML may be used in a very limited fashion. XAML is the main presentation layer in Windows 8 Metro if you are using a .NET enabled language or native C++. XAML is a declarative XML-based language similar to Mozilla's own XUL. XAML is familiar to WPF and Silverlight developers. XUL will most likely still be rendered to the DirectX surface.
Windows 8 has a minimum requirement of hardware that supports Direct X 9 and I'm not aware of any alternative like GDI available. So the Direct X blacklist of graphic cards we currently maintain may not be applicable in Metro mode.
Development milestones
Our first major goal is to get an experimental build of Fennec or Firefox running in Metro. This work is mainly being tracked in Bug 732518.
To get started we read the MSDN whitepaper entitled Developing a Metro style enabled Desktop Browser. This document lacked quite a bit of information though so a lot of registry hacking was needed to get things working. Jim and I documented a lot of this missing information here and here.
Most of our week was spent with registry exports, diffs, Process Monitor logs, and other tools. The first couple minor goals were to get a recognized Metro tile showing up, getting it to launch our process, and then finally displaying a Metro app.
Jim and I hit those first milestones and made a basic application which launches in Metro mode as a medium integrity process. The application doesn't do anything exciting except display a DirectX surface and draw some text to the surface that tracks mouse movement.
As a developer, your job gets pretty hard when you do a Google search for topics surrounding this barely supported third Metro application type and consistently get zero, one, or if you are lucky, two search results. All results being only slightly on topic.
Next development steps
We have several smaller goals that we want to tackle next week:
Meetings
We had our first weekly developer meeting half way through the week with attendees: Robert Strong, Tim Abraldes, Jim Mathies and myself (Brian R. Bondy).
Helping out
We're still extremely early in development so we're not ready for help with things like how the UI should look yet.
If you want to help with the development effort to get Firefox up and running in Metro, we'd love to hear from you. Please sync up with us in #windev on IRC or email me directly at netzen at gmail.com.
Over in bug 727398 I'm planning on making a change to restartless extensions that could potentially affect addon authors who use the Add-ons Manager API. This only affects code that registers a AddonListener or InstallListener event listener to get notified of add-on and install events, while also interacting with the startup of restartless extensions. I couldn't find any add-ons on AMO that would be affected by this, but I thought it would be worth blogging about anyway.
Currently, when a restartless extension is installed, it's startup() function is called before the onInstalled and onInstallEnded events are fired. This meant that a restartless extension would run it's initialization code before anything else thought it was installed.
However, that causes some issues. For example, if a restartless extension uninstalled itself on startup[1], then it could be uninstalled before it was installed. Unsurprisingly, the Add-ons Manager UI broke when this happened (since it uses the same APIs that add-ons use).
So bug 727398 will change the order of those operations. When a restartless extension installs, the following will happen in this order:
[1] Why would an addon immediately uninstall itself, you ask? Imagine an add-on whose sole purpose was to flip a preference to disable a newly-shipped but buggy feature, that would get re-enabled on the next application update. This is one of the things that a hotfix add-on could do. Additionally, I've been playing with various ideas for restartless extensions as a user support tool - the extension installs, does some work or collects some diagnostic data, then immediately removes itself.
Related posts:
I went a bit underground after leaving Mozilla as an employee. Now that I am situated in my new role, I can talk a little bit more about what I am doing and how it will relate to Mozilla.
I am currently at Facebook and recently graduated bootcamp. I'm on the Release Engineering team with Chuck Rossi working on release related things. Right now I help out with the Facebook.com web releases but I'll be moving into mobile (Android, iOS, mobile web, etc) shortly. It's pretty cool to see how a company the size of Facebook deals with releasing how often they do, the scope of their frontend and backend systems, and the tools and processes they have in place. Once I start working on mobile, I am absolutely giddy I get to work with Mike Shaver again.
So what does this mean for Mozilla? A lot! I've been missing-in-action, waiting for legal approval to work on Mozilla stuff. Now that I have that approval, I should be around more and more. Here's a list off the top of my head of what I intend to work on in my "spare" time:
I won't be working on Mozilla stuff in any official Facebook capacity, but I'll be around as much as I can in my personal time. I'm excited!
My team is “a riddle, wrapped in a mystery, inside an enigma”. Ok, maybe not *that* mysterious, but we’re definitely involved in a variety of projects. Here’s a roll-up of a week in browser-land.
Performance
New Tab Page
New Download Manager
Add-on SDK Integration
Web Apps Integration
Identity Integration
Share Integration
Evangelism/Engagement
Of course, we all worked on various other things as well, from code review to bug triage to random maintenance fixes. Activity logs and whatnot are listed below.
In my post Leak hunting in browser-chrome mochitests I wrote about the measures we were considering to prevent regressing efforts to get rid of leaks in Firefox. Now that bug 683953 has landed we finally have a way to detect the leakage of whole DocShells and DOMWindows for the lifetime of the browser when running the browser-chrome mochitest suite.
How does it work?
While our browser-chrome mochitest suite runs we parse stdout to track starting and ending tests as well as the creation and removal of DocShells and DOMWindows. Just before the test suite shuts down we schedule a precise GC and wait until it’s completed. Any DOMWindows and DocShells still active are now counted as leaks and assigned to the tests that created them. Additionally we collect the URLs of DOMWindows to help debugging a bit.
How does this prevent new leaks?
We implemented a threshold of (currently) 130 leaks that must not be exceeded. If a test run leaks more than the limit we configured it goes orange and the patch should be backed out from the tree. These are the current numbers:
Linux (64): 116 (116)
OS X (64): 79 (89)
Windows (XP): 120 (118)
Additionally, I filed bug 730797 to integrate these leaks statistics into our Talos infrastructure. So the leak count for each push will be recorded and compared to previous runs to make sure the numbers don’t regress. As the leak numbers differ quite heavily between OSes it makes sense to apply a custom threshold per OS, this will be implemented in bug 730800.
Why is there even a threshold?
First, there are DocShells and DOMWindows that are intentionally kept alive until the browser closes. Second, it’s nearly impossible to bring all these leaks down to “zero” at once. It’s a list of bugs that have to be addressed and we will slowly decrease the threshold to approach “zaroo”.
Thanks to Dão who has been doing great work in bug 658738 discovering all those leaks manually, which in the first place gave me the idea of automating it.
If you don't manage an add-on that is using Places bookmarks GUIDs, you can stop reading here.
As part of the performances improvements efforts, in Firefox 4 we replaced the old UUID-style GUIDs annotations on bookmarks with new 12-chars GUIDs that are directly stored in a guid column of the bookmarks table.
This has been done for a lot of reasons: memory consumption, disk space, performances
The following APIs in nsINavBookmarksService have also been marked as deprecated:
Unfortunately we found that some add-ons, even quite famous ones, are still using some of these APIs and the old GUIDs. We didn't get any answer to notifications we sent them, as of today. This is blocking possible improvements for all of our users, so we finally have to proceed with the removal.
Starting from Firefox 14 these APIs will be removed and all the existing GUIDs will be deleted from the database (any new instance of them will also be removed at regular intervals).
Since we understand some of these APIs don't yet have a replacement (though nsINavBookmarkObserver provides the new GUIDs and we are working on a new asynchronous bookmarking API), we are asking for your feedback to make new asynchronous APIs that can satisfy the GUID needs of your add-on. You can leave your feedback in the removal bug.
The remaining time before Firefox 14 is released should be enough to plan an eventual users migration or a refactoring of your add-on, so we hope this solution may be satisfying for everyone.
Currently defining a new XPCOM component in javascript has no implications regarding createInstance. This means any code or add-on may instance your component multiple times, even if you intended to make it service-like.
Why is this such a big deal?
Let's suppose that your component lazily creates and caches a Storage connection, and some other code createInstance() your component everytime it needs to make an API call to it. This actually means the add-on will create a new connection each time, and this connection will survive till the component intended to kill it, that is usually on some profile shutdown notification, like profile-before-change. While this example is about Storage connections, any kind of resource may be easily leaked this way.
While cpp services have various macros to make singletons, until XPCOMUtils there was no standardization of javascript components, and you had to make your own singleton factory every time. From version 12, XPCOMUtils includes a new method to generate singleton factories.
How to use it? XPCOMUtils supports some "magic" properties in the component, one of these is _xpcom_factory. From version 12, to make a singleton component, you can just:
function myservice() {
}
myservice.prototype = {
...
_xpcom_factory: XPCOMUtils.generateSingletonFactory(myservice),
...
}
Last week, I added a small module to make it easier to track time deltas measurements that are meant for telemetry. The module is called TelemetryStopwatch and it has two functions, start and finish, which do what their name imply. When you call start it takes a timestamp, and when you call finish it calculates the delta and adds the data to the chosen histogram. It’s useful to avoid sticking start timestamps as enclosed variables or private members in objects, and in cases where the start and stop measurements are disjoint and there’s not a good place to store the stamp or add code to calculate the diff.
Cu.import("resource:///modules/TelemetryStopwatch.jsm");
TelemetryStopwatch.start("MY_TELEMETRY_HISTOGRAM");
// and later
TelemetryStopwatch.finish("MY_TELEMETRY_HISTOGRAM");
// or, with the optional object parameter:
TelemetryStopwatch.start("MY_TELEMETRY_HISTOGRAM", refObj);
TelemetryStopwatch.finish("MY_TELEMETRY_HISTOGRAM", refObj);
You can have multiple counters at the same time. Each counter is associated with a telemetry histogram, or with a histogram + a reference object, for cases where you might need more than 1 timer running at the same time for the same histogram (e.g. some measurements related to a specific tab, where more than 1 tab might have it running at the same time). The objects are tracked on a WeakMap so you don’t have to worry about leaks. The module is in toolkit to make it widely available.
Happy metering!
Over the last weeks we worked hard on getting the New Tab Page into Firefox. It’s not quite ready yet but we need your help testing it. We enabled it by default on Nightly and decided to give it a week on Aurora to get feedback from those users as well.
Nightly: http://nightly.mozilla.org/
Aurora: https://www.mozilla.org/en-US/firefox/aurora/
We’ll disable it for Aurora again on February 16th (next Thursday). If you liked the feature and want it back then just set the preference ‘browser.newtab.url’ to ‘about:newtab’, ‘browser.newtabpage.enabled’ to ‘true’ and restart the browser. You can easily file bugs using the following link:
https://bugzilla.mozilla.org/enter_bug.cgi?product=Firefox&component=General
Please make sure you don’t report a duplicate bug and check the dependencies of the original New Tab Page bug before filing – bug 455553.
For Panagiotis’ outstanding contributions on the newly-landed Debugger front-end, we’re making him a peer.
Congratulations, past! May all your reviews be delicious.
Some time ago, way back in the heady days of Firefox 7, Mihai Șucan began work to incorporate the Orion text editor into our codebase and landed it in Firefox 8. At the time, we had some concerns around accessibility and localization: would Orion be up to the task of being an in-browser editor for the Scratchpad?
We discussed some possible ways to mitigate this and settled on including a TextArea-based fallback. Mihai’s done a tremendous job of providing a SourceEditor API in the browser that abstracts a lot of Orion’s own interface into a more general-purpose editor widget. In Firefox 10, we’ve enabled Orion by default in the Scratchpad for the first time. Cedric Vivier used the SourceEditor API for the Style Editor and it’s worth noting that it does not support the TextArea fallback at all in Firefox 11.
Now we’re trying to add some important new features to the SourceEditor component. Things like “Find in File”, “Incremental Search”, “Context Menus”… Y’know, things you’d expect from any normal text editor. The TextArea fallback has made that increasingly difficult to do and in some cases, impossible. The cost of maintaining this API has become untenable for future work.
So we’ve removed the TextArea fallback for Firefox 13.
This may have some unforeseen implications for us. We discovered earlier this week that at least one popular addon was using the SourceEditor and I wanted to broadcast this here just in case there are other developers or users who rely on the TextArea fallback. If you are one of these people and this is going to cause pain, please post here, to dev.apps.firefox or file a bug.
Snappy is a project that aims to improve is improving Firefox responsiveness. As part of this project I've been working on Firefox startup optimizations.
You can spend days, months, or even years trying to optimize code, but if you don't understand where to optimize, you won't be making a difference. Likewise, searching for an optimizations in a competitor's product is usually not the best way to get results.
It's nearly impossible to optimize code by guessing what is slow, you need to profile the code to understand the problems. Once you understand the problems you can then fix them, and then finally test to make sure they are fixed.
Here are some initial Firefox startup optimizations I've done with some lite profiling on Windows over the period of a few days:
I plan to keep doing more startup optimizations for a while in between silent update work.
So how are optimizations found? There are many ways, the first I will talk about is Xperf.
Xperf
One way to identify optimization bottlenecks on Windows is to use Xperf. Xperf is a great way to find both IO bottlenecks and CPU usage bottlenecks.
It can tell you which files use the most IO, what the IO patterns are, which functions take the most time, and allow you to group based on different criteria to view the data in different ways. It is the tool that made Windows 7 so much faster than Windows Vista. It actually does a ton more than that but I won't focus on it in the context of this blog post.
Built in Mozilla profiler
Another way to find optimizations is to use Benoit's profiler (SPS). Currently it works well on Mac, and Windows is nearly completed.
I'm very excited to start using it on Windows.
It far surpasses the tools I've been using to find the bugs and fixes above.
Custom profiler
I haven't seen how the Mozilla built-in profiler is implemented, but I suspect that this custom profiler is a simplified version of the Mozilla profiler's Pseudostack mode.
I was able to find all of the above optimizations (with the exception of the prefetch task) with a tiny class with a couple of wrapper macros.
Basically the class is an RAII class built around the Win32 API QueryPerformanceCounter and QueryPerformanceFrequency.
These functions allow you to get very detailed timing results.
For any function you want to profile you simply add the PROFILE_FUNCTION() macro to the start of the function. I usually start by adding this to each non-trivial function in a file.
Once you've found a function that takes a non trivial amount of time you can start to dig deeper into other functions inside of the function until you find the root cause.
But sometimes a function has a lot of code and you aren't sure what the slow part of the function is. For this I use a second macro PROFILE_STR("FunctionName:N") where N is a number I increment evenly spaced out. The string can be anything, I just use that normally.
These macros just create an object. The constructor of the object stores the start time, the destructor of the object gets the end time.
The destructor also uses the function name or string as a lookup in a global map that keeps track of the number of hits, the maximum length of time, the minimum length of time, and the average length of time for each function/string.
There is a third macro I was using to dump the results to a file at particular events I wanted to focus on, like first paint, or when the session is restored.
One thing you have to look out for with this method is if you happen to put the calls in a recursive function.
In that case it will appear to be a bigger bottleneck because the first call will include the full length of time of all calls that contain it.
All of the inner calls will add onto that.
The output of this function is made when the third macro to dump the results is called. It dumps the results to a simple formatted .txt file:
Verifying startup results
If you're working on Firefox, a good way to verify that your speed optimization made a difference is to use the about:startup extension.
This extension times the startup of important events like firstPaint
and sessionRestored and gives you the average up top.
To verify my results I just did 20 startups in sequence with a release build that contained my patches vs a release build that did not contain my patches.
Here is an example after one of the patches above:
New patches:
* bug 720838 – [Page Thumbnails] Use canvas.mozFetchAsStream()
* bug 720697 – Provide internal API to get canvas image data as nsIInputStream
* bug 669603 – large sessionStorage data causes session restore to block the UI
* bug 666538 – Use Telemetry to collect Panorama usage/perf data
* bug 721019 – [Page Thumbnails] Add telemetry probes
* bug 722479 – browser/components/thumbnails/test/ tests leak chrome://global/content/mozilla.xhtml
* bug 716532 – [New Tab Page] Remove “site strip” at the top and re-style buttons
* bug 722663 – open a new tab from Panorama view should reference gWindow.BROWSER_NEW_TAB_URL
* bug 723852 – Use a runnable for canvas.mozFetchAsStream()
* bug 723102 – [New Tab Page] Can’t Hide/Show New Tab Page when closing left tab
* bug 721417 – Can’t drag and drop URL into about:newtab
* bug 695705 – Intermittent TEST-UNEXPECTED-FAIL | browser/base/content/test/tabview/browser_tabview_bug628061.js
Filed bugs:
* bug 722650 – [New Tab Page] Long hang when first enabled in a profile
* bug 723852 – Use a runnable for canvas.mozFetchAsStream()
* bug 724225 – Lots of reflows and flickering when using IRCCloud
Feedback and review:
* bug 722100 – Use ondblclick instead of hard-coded time interval to detect double clicks on ui.js
* bug 722460 – gBrowserThumbnails uninit sets a property that has only a getter
* bug 388079 – Deleting multiple cookies deletes wrong ones and/or not all selected
* bug 722663 – open a new tab from Panorama view should reference gWindow.BROWSER_NEW_TAB_URL
* bug 723515 – Add telemetry probe for the opening time of the Firefox app menu
Landed
* bug 721087 – [New Tab Page] Cells should have an outline to indicate their positions
* bug 716538 – [New Tab Page] Set to enabled by default on Nightly
* bug 720697 – Provide internal API to get canvas image data as nsIInputStream
* bug 707862 – Reset childCount on SHEntry when all children have been removed
* bug 721019 – [Page Thumbnails] Add telemetry probes
* bug 722479 – browser/components/thumbnails/test/ tests leak chrome://global/content/mozilla.xhtml
* bug 722663 – open a new tab from Panorama view should reference gWindow.BROWSER_NEW_TAB_URL
* bug 723852 – Use a runnable for canvas.mozFetchAsStream()
* bug 723102 – [New Tab Page] Can’t Hide/Show New Tab Page when closing left tab
* Merge Fx-Team and UX branches
Next:
* bug 720838 – [Page Thumbnails] Use canvas.mozFetchAsStream()
* bug 669603 – large sessionStorage data causes session restore to block the UI
* bug 721019 – [New Tab Page] Add telemetry probes
* bug 716532 – [New Tab Page] Remove “site strip” at the top and re-style buttons
* bug 721417 – Can’t drag and drop URL into about:newtab
* and other various New Tab Page bugs
Coordination:
* Returned from Performance work week and FOSDEM
We’re at the end of our Performance work-week here in Brussels, and gearing up for a two-day orgy of European open-source culture at FOSDEM. I’ve successfully acquired a cold (and hopefully not worse) due to the temperature being consistently below freezing.
However, the people here in Brussels have made up for their weather shortcomings by welcoming us wherever we go. Between the hackerspaces and co-working spaces, and the restaurants that happily take large groups with little or no notice, I’m very impressed!
HSBXL
The hackerspace in Brussels is located in Schaerbeek, a neighborhood to the north of the city center. The space used to be a vehicle repair garage for the city, but was given up for use by the geeks. They’ve installed serious hardware, and have fully-equipped the place with everything needed for survival. Thanks to Rafael and Patrick, for answering all our questions and helping us make mate and to find food nearby. Lunch on the second day was described by Patrick as a “little French place”, but turned out to be a hall of worship dedicated to Tintin!
Faubourg St Antoine is filled with Tintin toys, art and knick-knacks, including some alternate interpretations and even a clarification for something I’d always wondered about. Sadly, they’ve been issued a legal notice from the current copyright (or EU equivalent) holders requiring them to remove all the Tintin materials from public display 
BetaGroup Coworking
Once the temperatures dropped far below freezing, we relocated to BetaGroup Coworking Brussels in Etterbeek, to the southeast of the center. Ramon Suarez, the manager of the space was very accommodating, taking us on short notice. The wi-fi was blazing fast, the coffee was hot, and the ping-pong was a welcome break from heads-down hackery. The space itself was fantastic, with a great combination of quiet co-working areas, public spaces and private meeting offices. With tons of natural light, steel bridges and a meeting space on what looked like a submarine conning tower, it was truly impressive.
We had a wonderful lunch at a very tidy restaurant nearby.
Overall, it’s been a fun and productive week, if a bit chilly. Like, really chilly. Ridiculously so. Why do people even inhabit places that get this cold? Honestly, wtf.
Which reaction do you get by looking at the following code?
#elem {
-moz-box-shadow: 0 0 10px gray;
-webkit-box-shadow: 0 0 10px gray;
-o-box-shadow: 0 0 10px gray;
-ms-box-shadow: 0 0 10px gray;
box-shadow: 0 0 10px gray;
}Much has been said about how CSS prefixes do more harm than good, and a lot of people have wanted to get rid of them, but there hasn’t been any proposal that didn’t cause (worse) shortcomings, allowed vendor experimentation to continue without disrupting the web, or offered an easy transition path. I’ll present here a proposal that I believe fixes all the existing problems with prefixes, makes it really easy to transition from experimental to recommended, and actually improves various aspects of web development and browser support for features that are on an standardization path.
The feature is simple, and there’s a TL;DR at the end, but let’s design it step by step to make sure we’ve covered everything.
(Let me here preemptively say, in true Graydon style: disregard the syntax of the proposal, focus only on the idea. The ideal syntax can be discussed later)
The basic idea is that, in order to use non-standard CSS features, instead of using prefixes on every declaration of that property, you only use it once at the top of the file to indicate that you’re willing to unlock that feature as implemented by that engine. For instance, the example at the top would become:
@-vendor-unlock {
box-shadow: gecko, webkit, trident, opera;
}
...
#elem {
box-shadow: 0 0 10px gray;
}Here’s a list of the properties that this approach bring:
One problem that already exists with vendor prefixes, but that is not solved with the above suggestion, is syntax or feature changes. The whole purpose of the prefixes is so that vendors can experiment with feature support without making the promise that it won’t ever change. In practice, though, once a feature has been widespread enough, most vendors are tied to that and the decision to change the syntax or not is heavily influenced by that. While we are designing the new approach, we can also fix that! With feature versioning, web developers can explicitly target a version of the implementation, like so:
@-vendor-unlock {
box-shadow: gecko/v1, webkit/v2, trident/v2, opera/v1;
}The last problem is when two matching versions does not exist between browsers. That is, it’s not possible to write a single declaration that will work on different engines. In that case, there’s no way around having multiple property declarations, and an override must be provided. To do that, the vendor prefix plus the version is used, and the feature still has to be unlocked, which guarantees that there’s no reason to just use the “good old prefix” except for mismatching reasons. Also, the prefix should be used to the engine that is probably leaning in the wrong direction than what will be made the standard.
As an example, let’s imagine a property called foobar that webkit and gecko implements, with two size arguments (<left> and <right>), but each takes on a different order.
@-vendor-unlock {
foobar: gecko/v1, webkit/v1;
}
#elem {
foobar: 10px 5px;
-webkit-foobar-v1: 5px 10px;
}@-vendor-unlock {
foobar: gecko/v1, webkit/v1, webkit/v2, opera/v1, trident/v1;
}
#elem {
foobar: 10px 5px;
-webkit-foobar-v1: 5px 10px;
}Browser vendor prefixes are polluting the web so much while making web development harder, which is the exact opposite of the two main reasons it exists. The main idea to fix that is that the property declarations should be written unprefixed, while an explicit unlock and versioning is instead used to activate these features on browser engines. An example would be:
@-vendor-unlock {
border-radius: gecko/v2, webkit/v1, opera/v1, trident/v1;
}
...
#elem {
border-top-left-radius: 5px;
border-top-right-radius: 10px;
}P.S.: I’ll be at FOSDEM this weekend if anyone is interested in discussing this idea during the conference.
The Performance team and some of the Firefox team are spending the week in Brussels, laying waste to some of the performance issues in the browser.
Much thanks to our excellent hosts HSBXL, a hackerspace in central Brussels. We’re equipped with fast internet, lemon soda, mate, techno music, and of course beer.
Following the work week is FOSDEM, Europe’s biggest open source conference. If you’re in town for FOSDEM and want to come hack with us, ping me on twitter or join us in #perf on IRC.
I’ll be uploading pics to flickr with the tag ‘perfworkweek2012′.
New patches:
* bug 455553 – New Tab Page feature
* bug 497543 – Provide a thumbnail service
* bug 720697 – Provide internal API to get canvas image data as nsIInputStream
* bug 720838 – [Page Thumbnails] Use canvas.mozFetchAsStream()
* bug 715710 – [New Tab Page] Black bars behind titles should be lowered in opacity from 80% to 50%
* bug 721087 – [New Tab Page] Cells should have an outline to indicate their positions
* bug 721413 – [New Tab Page] Don’t fetch links on startup when disabled
* bug 721398 – moz-page-thumb protocol should not be accessible from a web page
* bug 721422 – [Page Thumbnails] Re-enable tests and make them work with URI_DANGEROUS_TO_LOAD
* bug 721413 – [New Tab Page] Load links lazily when opening a new tab
Filed bugs:
* bug 720575 – Make drawWindow() faster and/or asynchronous
* bug 720697 – Provide internal API to get canvas image data as nsIInputStream
* bug 720838 – [Page Thumbnails] Use canvas.mozFetchAsStream()
* bug 721014 – Intermittent REFTEST TEST-UNEXPECTED-FAIL | ogg-video/poster-10.html | image comparison (==)
* bug 721087 – [New Tab Page] Cells should have an outline to indicate their positions
* bug 721329 – [Page Thumbnails] Write more sophisticated thumbnailing tests once we figured out the desired algorithm
* bug 721019 – [Page Thumbnails] Add telemetry probes
* bug 721020 – [New Tab Page] Add telemetry probes
* bug 721422 – [Page Thumbnails] Re-enable tests and make them work with URI_DANGEROUS_TO_LOAD
* bug 721413 – [New Tab Page] Load links lazily when opening a new tab
Feedback and review:
* bug 720981 – Remove element.iQEventData when it’s empty
Landed
* bug 455553 – New Tab Page feature
* bug 497543 – Provide a thumbnail service
* bug 721398 – moz-page-thumb protocol should not be accessible from a web page
* bug 716855 – [Page Thumbnails] Screenshots should contain the the top-left corner
* bug 721422 – [Page Thumbnails] Re-enable tests and make them work with URIDANGEROUSTO_LOAD
* bug 721413 – [New Tab Page] Load links lazily when opening a new tab
* bug 717110 – [New Tab Page] Tooltips should be added to page thumbnails
* bug 717492 – [New Tab Page] URL bar history pops up when pressing toolbar buttons
* bug 715710 – [New Tab Page] Black bars behind titles should be lowered in opacity from 80% to 50%
* Merge Fx-Team and UX branches
* Investigate Talos performance hits by Thumbnail Service / New Tab Page
Next:
* Performance work week and FOSDEM
New patches:
* bug 455553 – New Tab Page feature
* bug 497543 – Provide a thumbnail service
* bug 705958 – [Page Thumbnails] Use only the top 25% of a web page
Filed bugs:
* bug 719292 – Error: hud.jsterm is null in resource:///modules/HUDService.jsm:2074
* bug 719300 – Web Console opens minimized, behaves strange, doesn’t close
Feedback and review:
* bug 718228 – tab close transition to transparent is too fast
* Merge Fx-Team and UX branches
* Estimate web apps integration work
* Land and (unfortunately) back out the Thumbnail Service and the New Tab Page and investigate Talos performance hits
Next:
* bug 455553 – New Tab Page feature
* bug 497543 – Provide a thumbnail service
* bug 701377 – setTabState() always unhides the tab