Planet Firefox

It has been a good couple of weeks. There are several bugs I am relieved that are now fixed for Firefox 3.6… especially that we now check if Firefox is in use prior to updating and prevent launching Firefox during an update. Also, checking for updates for users that aren’t able to apply updates. Beltzner did his usual beltzner thing by catching what I see as a major usability flaw in that the original patch notified users repeatedly for the same release until Firefox was upgraded which I was able to fix. I’m still kicking myself for not catching that myself.

Progress:

---

• WOOT! Landed on trunk and 1.9.2 branch – Bug 407875 [Toolkit] – “Unprivileged users are not notified of security updates [All]“. The next bugs to fix that are similar are the dependent bugs of Bug 318855 [Toolkit] – “App update should provide method to update when the user doesn’t have privileges [All]“.
• Landed on trunk and 1.9.2 branch – Bug 510501 [Toolkit] – “not granting UAC permission to updater.exe causes full update to be downloaded [Windows]“. The next bug to fix that is similar is Bug 336267 [Toolkit] – “If software update is disabled or “ask” after an update has been downloaded, the update should be disabled or asked [All]“.
• Created a wiki page for the work on Bug 410639 [Toolkit] – “Provide ability to change update channel within the application [All]” and emailed dev-apps-firefox / dev-platform (followups to dev-apps-firefox) for this proposal.

Future targets (short work week so no way this will all get done):

---

• Bug 336267 [Toolkit] – “If software update is disabled or “ask” after an update has been downloaded, the update should be disabled or asked [All]“
• Investigate Bug 526441 [Toolkit] – “Unable to use FileUtils.jsm in nsExtensionManager.js.in on 1.9.2 due to reftest failures”.
• Yes, I still need to blog about the lessons I’ve learned while trying to improve startup time for app update but the Firefox 3.6 took precedence.
• Investigate Bug 529948 [Toolkit] – “Cannot check for updates on trunk when the download server is down” along with its friends

I’m taking Wednesday off so next week is a two day work week for me since Thursday and Friday are holidays.

November 20, 2009 09:30 PM

November 20, 2009 05:19 AM

November 18, 2009 10:06 PM

To increase the participation in and awareness of application’s beta programs and specifically Firefox’s beta program we will be providing the ability to change the application update channel within the application. This will be an opt-in for each application.

The details in the wiki are by no means complete but they should provide a place to start from

wiki Application Update:Channel Change
Bug 410639 – Provide ability to change update channel within the application

Feedback / comments welcome preferably either in the dev-apps-firefox newsgroup / mail list or the wiki page’s discussion page though you can just respond in this blog if you prefer.

November 17, 2009 09:18 PM

(You are encouraged to read this article with its formatting and typography intact, instead of in this RSS reader)

Introduction & Rationale

What if there was a backwards compatible way to transfer all of the resources that are used on every single page in your site — CSS, JS, images, anything else — in a single HTTP request at the start of the first visit to the page? This is what Resource Package support in browsers will let you do.

---

When it comes to browser performance, it’s widely known that a lot of the time is spent waiting for HTTP requests. You are probably familiar with the issue; a well-known optimization technique is to reduce the number of HTTP requests that are done for a given web site, since browsers only do 2–6 requests in parallel. This is why techniques like image spriting exist.

There are problems with image spriting, though. In addition to potentially severe memory penalties, they obfuscate the code — “What is this icon at 704px, exactly?” — and every time you add a new icon, you have to update the sprite file, which adds to the maintenance burden.

Some images can’t be sprited (think about YouTube, which easily serves up 40 JPEG thumbnails on a given page), and there’s also other resources like JavaScript & CSS, which — while possible to combine — at the very least need one file each. You can see how this quickly saturates the available parallel HTTP pipelines.

Even if bandwidth is getting better, and the internet is getting faster, ping times are actually getting worse in a lot of cases. With mobile internet browsing, and to some extent US domestic cable internet and DSL, the round-trip time for a single request can be slow, even if it downloads relatively fast once the transfer starts.

While there are lots of workarounds to solve this class of problems, we suggest a standard approach that all browsers makers can easily implement, and that is backwards compatible with browsers that do not support it. We also want a solution that works for all types of resources, not only image bitmaps, and one that doesn’t require any new tools, file types or protocols.

Goals

This proposal has the following goals:

• Make it possible to serve all the resources (images, stylesheets, javascript) required by a page in a single HTTP request, freeing up the other parallel requests to fetch resources that are page-specific.
• Be as simple to implement as possible, so anyone with a passing familiarity with HTML should be able to perform the optimization.
• Be entirely transparent to browsers that do not support it.
• Avoid retransmission of existing resources.
• Use existing tools that are widely used on all platforms.
• Support the “80% use case” over adding a lot of complexity to the spec.

Non-goals

Some explicit non-goals of this proposal:

• Invent new file formats
• Invent new compression formats

Implementation

While Zip files do not have not the most elegant or efficient packing format out there, they have the following very desirable traits:

• Easily available reference implementations.
• Can be unpacked even in partial state — which means that we can stream the file, and put CSS and JavaScript first in the archive, and they will unpacked and made available before the entire file has been downloaded.
• Excellent toolchain support, zip/unzip is available on all major platforms, so it’s easy for web developers to use.

We propose this markup to signal a zipped resource package:

<link rel="resource-package" 
      type="application/zip" 
      href="site-resources.zip" />

The default MIME type for a resource package is application/zip, and you can omit it in documents where it is valid, like in HTML5, where an equivalent would be:

<link rel="resource-package" 
      href="site-resources.zip" />

This will tell the browser to download this file first, and use the resources contained in the file instead of the referenced images, style sheets and javascript files — or for that matter, any other file. Browsers should prefer the files in the resource package, and do individual requests for images that are not contained in the package.

A given browser will probably block downloading any resources until the lists of files that are available in resource packages have been accounted for — or there may be a way to do opportunistic requests or similar, we leave this up to the browser vendor unless there’s a compelling reason to specify how this should work.

Older browsers that do not support resource packages will simply ignore this tag, and fetch the files normally, with one HTTP request for each.

Path handling

Paths will be rendered relative to where the resource package is located, so you can supply additional directories inside the Zip to mimic existing site structure.

The resource package is referenced as follows in a page somewhere on the site www.example.com:

<link rel="resource-package" 
      type="application/zip" 
      href="/static/site-resources.zip" />

The Zip file has this internal structure:

manifest.txt
javascript/jquery.js
css/reset.css
css/grid.css
css/main.css
images/save.png
images/info.png

In this example, the resolved path to the main.css file would be http://www.example.com/static/css/main.css. Notice how the path inside the zip file is added to the path where the actual zip file is located.

The manifest file

To give the browser the ability to know up front what files are in the zip file without reading the entire file first, we add a mandatory manifest file that can contain this information. This file can be supplied as a separate file (useful if combining with Offline Resources), or as the first file in the zip file itself.

Example manifest.txt file:

javascript/jquery.js
styles/reset.css
styles/grid.css
styles/main.css
images/save.png
images/info.png

• This file must be the first file in the archive.
• This file must be named manifest.txt when supplied as part of the archive.

If this simple format looks familiar, that’s not a coincidence. Initially, we were looking at using either an XML or JSON format to specify this, but we believe it’s easier to add a couple of new abilities to the offline resource specification instead. When using resource packages with Offline Resources (which are also part of the HTML5 spec), we’d like it to be easy to extend the rules, so the offline manifest with resource package support could look like this:

CACHE: resources=/static/siteresources.zip
javascript/jquery.js
styles/reset.css
styles/grid.css
styles/main.css
images/save.png
images/info.png

# The above section lists the files in resource.zip. To start a new section, do:
CACHE:
images/outside-package.png

The only thing we’d need to add to the HTML5 offline spec is that it should ignore anything on the same line after CACHE: if it doesn’t know how to handle it. This means that you could potentially put the resource package definitions in your Offline Resources manifest — we would also support doing it the other way around, and put the Offline Resources manifest inside the resource package.

This isn’t a requirement for implementing the initial version of resource packages, however — but could be an easy way to add support for it to the offline resource specification. If there’s a better way to do it, let me know.

Fallback

There should be no compatibility issues with old browsers, as they will just load the individual files instead of the zip file.

Browsers that don’t implement this will seem slow in comparison to other browsers. Luckily, it should be a simple addition to any of the modern browsers.

Two simple examples

It’s not hard to see where Resource Package could be useful in existing sites, but two main categories would be:

Supply the core layout & functionality of a site

Typically, you would ship over all the CSS, JS and images that are used on every page in the site. These could be cached quite aggressively, and even use ETags to invalidate the zip file when needed.

The thumbnail search result case

Consider a typical YouTube search results page. It contains 20-40 thumbnails of videos, and there’s no easy way to add all these images into an image sprite, since the long tail of search results would vary a lot. Resource Packages would let you build a zip of search result thumbnails on the fly, and ship them all over in one HTTP request. It would require some CPU power, but would be much faster for the end-user. This wouldn’t have to be cached, or could be cached on a per-search basis.

Other approaches

There are several other approaches that could solve parts of this problem, but

HTTP pipelining

This is a more aggressive way of utilizing the HTTP keep-alive mode, but is not implemented correctly by all web servers. Proxies have a hard time with it, some browsers also do, so it’s not really working unless you want to be aggressive and/or whitelist/blacklist certain servers.

Multipart MIME

Hard for integrators, requires special packing that isn’t trivial to do, and has poor browser support.

JAR files

No reasonable fallback mode, as the file name is embedded in the href/src link, and browser that doesn’t support it just won’t render it.

SPDY

While this effort from Google aims to make everything faster, it is largely orthogonal to what we’re trying to do with Resource Package. It also requires you to retrofit both web browsers and web servers to make it work, which means it will take quite a while before this will be in common use. Resource Packages work without any changes to the web server software, and will work as soon as any browser supports it — with no adverse effects to the browsers that don’t.

Additional notes

• The Zip format doesn’t have MIME type support, so this will have to be solved by the browser based on filename extensions or other heuristics. We don’t believe this to be a problem, since browsers already have to do this.
• All the resources in the package will have the same headers (expiry, ETags, etc.) as the zip file itself. If you need different expiry dates or other caching settings, you should specify multiple resource files with different cache headers.
• You can specify a charset in the resource package definition. If unspecified, it is assumed that any non-binary files inside are UTF-8.

Next steps

We have sent this out to the major browser vendors for feedback, and we will be implementing this in the next upcoming release of Firefox (tentatively has the version number 3.7, but this may change).

FAQ

Does zipping up multiple optimized PNGs or other files work with zip? Can it potentially increase file size or lead to a high unpacking CPU overhead?

Zip automatically chooses the best of deflation or no compression. Images will usually not be compressed, since they already are, text files like CSS/JS will be. In general, CPU impact from unzipping is negligible, even on slow devices.

How does this affect mobile devices, which have limited CPUs?

More realistic concerns are cache ability and bandwidth — as well as the ping time on mobile networks — and memory. A lot of mobile browsers only keeps things in the browser cache at all if the individual file is something like 20kB or less. For returning visitors, you suddenly need to download one large file again, instead of having multiple small files locally.

In general, mobile browsers clear their caches quite aggressively — although with the resource package spec, one would hope that they would implement more optimal handling and prioritize caching these, since they more likely to be valuable for browsing performance than another random image/CSS/JS file in a site.

How would Resource Packages work with CDNs?

There would be no special handling, these mirrors would just carry the resource package file like any other file they are supplying.

Acknowledgments

• Mike Solomon from YouTube for encouraging me to propose a solution to this issue.
• David Baron & Elika Etemad from Mozilla for comments on the implementation feasibility, and for helping identify prior art.
• Vladimir Vukićević & Jonas Sicking from Mozilla for help with adapting the Offline Resources standard to handle Resource Packages.
• Dion Almaer & Ben Galbraith from Palm, Steve Souders & Alex Russell from Google & the Chrome team for feedback on the proposal from an implementer’s perspective.

Improvements & feedback

If you have any suggestions on how to improve this proposal, send me an email at limi@mozilla.com or even better, comment in the open thread over at Mozilla’s dev.platform forum. It has been filed as bug #529208 in Bugzilla for those of you that want to monitor its progress.

---

Proposal State: Draft

Revision 4: Nov 16th, 2009 — first published & widely circulated version, added Offline Resources support

Revision 3: Nov 10th, 2009

Revision 2: Sep 1st, 2009

Revision 1: Jun 15th, 2009

November 17, 2009 03:05 AM

Tab matches in Awesomebar

Status

• Took an alternative (more complete, less hacky) approach to autocomplete integration, which took a lot longer. This way should allow easy ranking for tab-only matches.

Loose ends

• None

Next steps

• Finish autocomplete work
• Unit tests
• Preferences UI

Target for next week

• Finish autocomplete
• Unit tests

Binding for untrusted text in security dialogs

Status

• Initial planning
• Identified potential issues with implementing in only JS

Loose ends

• None

Next steps

• More research – especially into unmatched surrogates in UTF-16

Target for next week

• A better understanding of surrogates

Miscellaneous

• 519486 resurrected itself in some (new) popular lightweight themes – looking at ways to further improve the solution.

Reflections

• A hack can save time now, cost time later, and still be worth it.
• Beautiful code is not always useful code.

Related posts:

1. Status update
2. Status update
3. Status update

November 15, 2009 12:51 AM

Progress:

---

• Landed on trunk and 1.9.2 branch – Bug 525390 [Toolkit] – 3.5.4 Upgrade failure: entry point js_SaveRegExpStatics could not be located [Windows / WinCE / WinMo]. This also fixes Bug 312010 [Toolkit] – possible to start firefox when the “Software Update” dialog is running [Windows / WinCE / WinMo]. Also filed the spinoff Bug 528603 [Toolkit] – Upgrade failure with Zone Labs / Zone Alarm ForceField: “entry point js_SaveRegExpStatics could not be located” [Windows] to track the fix Zone Labs is coming out with.
• Landed on trunk and 1.9.2 branch – Bug 523915 [Toolkit] – updater crashes when trying to update with crash reporter open [Windows].
• Landed on trunk and 1.9.2 branch – Bug 528445 [Toolkit] – change app.update.log.* in updates.js to app.update.log for UI logging [All].

Future targets:

---

• Still going to try to get Bug 407875 [Toolkit] – Unprivileged users are not notified of security updates fixed for Firefox 3.6.
• Investigate Bug 526441 [Toolkit] – Unable to use FileUtils.jsm in nsExtensionManager.js.in on 1.9.2 due to reftest failures.
• Finish up a couple of more reviews in my queue I haven’t had time to do.
• Still need to blog about the lessons I’ve learned while trying to improve startup time for app update but Firefox 3.6 is taking precedence.

Updated: Forgot to include in the progress section. Landed on trunk and 1.9.2 branch – Bug 527845 (WinCE only) [Toolkit] – App update can’t deal with read-only files [Windows CE]

November 14, 2009 07:01 AM

My patch for bug 506814 landed. Thanks, Josh and Dao.

Created a new project, async Places containers, which is the topic of the remainder of this post.

Spent time thinking about a Storage “live view” interface, mocked it up, talked to sdwilsh about it. The idea was a live view, where modifications to the view’s underlying data would automatically trigger a view refresh. The motivation was the fact that Places query results now (well, will—bug 499985) use the same collations in two locations: in the database on initialization (which makes possible APIs that return data in async batches), and in code when changes occur to the results. That means duplicate collation code in Storage and Places, and the collations used by each must be equivalent. But if there were such a thing as a generalized live view, it could all be handled by Storage.

However, I realized it’s not possible to in general and in constant time determine whether an arbitrary change to the database occurred within a given view. In the current code it’s O(1) to do this check against a list of query results exactly because a list of query results is not generalized. So I dropped this idea.

The problem of duplicate collations remains, and now I’m thinking of creating temp tables in Places code to store query results instead of the arrays of nodes it currently uses. That way Storage and its collations do the heavy lifting, handling both initialization of and updates to results. We’d turn the data into nodes only when it’s leaving the API. There are big roadblocks to doing that, though. There’s lots of post-Storage processing and filtering of data that would need to be moved to Storage. I think the reasons we don’t do this processing in Storage have more to do with an inadequate schema and layers of modifications to the code over a long period of time than any substantive problems with using SQL or Storage. In general I really wish we took better advantage of SQLite.

Rather than trying to solve big problems right off the bat, it might be better to start small: forget about the duplicate collations for now (making sure they’re equivalent) and just update the initialization path of the bookmarks query results, the simplest kind, to use the Storage collations. Even that isn’t so straightforward. We have a single, immutable mozIStorageStatement—among many others—that gets a container’s children. It’s created from a long string of raw SQL. If I merely want to change the sort order of that query, or any other for that matter, it’s not so clean or easy.

November 14, 2009 05:09 AM

Progress

• Posted some findings to bug 496217. Turns out we will only load the spell check dictionaries during startup if the user’s homepage or restored session contain spell check enabled inputs. I’ve posted some possible next steps in the bug, but the best solutions will likely lead to us partially forking and maintaining our own copy of Hunspell.
• Spent some quality time with gdb and a bunch of test cases trying to catalog all the cases in which we touch NSS on the startup path for bug 441355. I’ll probably be posting those findings this weekend.

Next Steps

• Post new patches and get review for bug 520284, 522842 and 520334.

November 14, 2009 03:17 AM

November 14, 2009 12:53 AM

Back in the mists of time I wrote some code to make nightly testers’ lives easier by giving them a simple preference to flip if they wanted to be able to install and use incompatible extensions. It’s been more than three years since then and the use of this preference has grown beyond its original use. It is now something recommended to regular users everywhere from forums to comments in news articles as a way to use their extensions in the new major Firefox releases.

Don’t get me wrong, letting users upgrade sooner than they otherwise might is a good thing, but the preference is a dangerous beast. It is pretty simple for a user to set the preference and then forget about it leaving them able to install incompatible extensions that break their Firefox without realising it. This costs Mozilla time as well since we get quite a number of bug and crash reports to look at that turn out to be caused by extensions that are dutifully marked incompatible with the user’s Firefox.

We’ve been mulling over ways to change this for a while but now we’ve actually gone and done something about it. We still want nightly testers and early adopters to be able to use incompatible extensions if they need to but we also want to make the preference not be a one shot deal that lasts till the end of time. The plan we’ve come up with is to change the preference’s name with the Firefox version, so for Firefox 3.6 (and all security releases) the preference will be extensions.checkCompatibility.3.6. When switching to a future 3.7 testers and users will have to set a new pref extensions.checkCompatibility.3.7 to say they still accept the risks of running with incompatible stuff.

Nightly users will have to make the changes slightly more often since the preference will also track whether the version is one of the development alphas or betas, so for the 3.6 betas the preference would be extensions.checkCompatibility.3.6b, for the current trunk extensions.checkCompatibility.3.7a. These are just normal preferences of course, if you frequently switch between different Firefox versions you can just set both necessary preferences. The change should land on the trunk in the next day or so and then the 3.6 builds a day or so after that.

There is just one oddity, if you’re testing nightlies and you update to a build with the change then you likely won’t notice any of your extensions disabling themselves, that won’t happen till either you toggle the pref or you switch to a build with a different Firefox version number in it.

Update: For more in-depth information this change was made in bug 521905.

November 12, 2009 12:34 AM

SATTAP

If I told you you could have one-click mac screenshots with automatic scp to a host of your choice and it could have a reasonably bad user experience and no keyboard bindings, well you’d just be all over that, wouldn’t you?

Yes, I know about grabup (and their recent departure), and tinygrab, and all the rest. I’ve used several of them, in fact. What can I say, I wrote this way back when, and still find it gets the job done. If you don’t want to hitch your cart to someone else’s image hosting horse (and associated ad spam/image expiry blah), you’re welcome to it.

It’s a shell script. It takes the screencap, does the scp, and then puts the URL on your clipboard. You’ll need to edit some bits. I find it irksome to run from the command line, so I wrapped it in a 1-liner applescript (do shell script "~/bin/sattap") that I can just click from the dock.

Rob wrote one of these, too. [UPDATE: And now catlee has "ported" sattap to linux.]

Migrate.app

My macbook has the irksome habit, when I disconnect it from the external display and then reconnect it, of leaving all my windows on the tiny little 13″ display and not the hulking 24″ display I just connected, presumably for displaying things.

I borrowed a script from Dudehey on macosxhints to do the heavy lifting and then tweaked it to my particular preferences about which windows stay where. You will disagree with me, and hate this script; in fact, it won’t even work for you. But maybe you can make it work for you, if you care to?

Here it is. Open this in Script Editor – change it however you like, and then Save it somewhere as an Application, throw it on the dock, and hooray.

Rotate Page Bookmarklet

Okay, I don’t actually find this one useful, but it amuses. And you need some amusement.

javascript:document.body.style.MozTransform="rotate(90deg)";void(0);

Go on, try it. (Yes, in Firefox.)

November 11, 2009 11:29 PM

Jetpack 0.6 is out, sporting a new menu API and Twitter library.

Jetpack is a platform for writing Firefox add-ons the same way you write for the Web: HTML, CSS, JavaScript, Webby libraries like jQuery, no browser restarts to see your changes. But that’s shortchanging it. It’s also add-ons with a security model; an interactive shell for tinkering with the browser, since it bundles Bespin; a playground for budding coders, potentially; portable to other XULRunner apps like Thunderbird; and a mechanism for extending not only the browser but the Web itself. If it’s easy now to dismiss Jetpack as add-ons lite, it’s only because it’s still teething.

The new menu API lets you manipulate the browser’s menus—not only menu bar and context menus, but menus you can create and attach most anywhere, chrome or content, popup or context.

These lines of JavaScript add a “Tweet This Link” item to the page’s hyperlink context menu:

jetpack.menu.context.page.on("a").add(function (context) ({
  label: "Tweet This Link",
  command: function () jetpack.lib.twitter.statuses.update({
    status: context.node.href
  })
}));

Try it out.

This one adds a “Recent Tweets” submenu to the Tools menu. When it’s opened, it displays a “Loading…” item, and if it remains open when the data comes down from Twitter, it’s filled in with solipsism, one item per tweet. Note that the word “Tools” doesn’t appear, nor does any position specifying where in the menu to insert the item. You tell Jetpack, “This is my add-on’s menu, stick it in the best place.” You can get specific if you want.

jetpack.menu.add({
  label: "Recent Tweets",
  menu: new jetpack.Menu({
    beforeShow: function (menu) {
      menu.set("Loading...");
      jetpack.lib.twitter.statuses.public_timeline({
        success: function (array) {
          let tweetArray = array.map(function (obj) obj.text);
          menu.set(tweetArray);
        }
      });
    }
  })
});

Try it out. (Mac users, a caveat.)

You can add popup menus to content in pages. This adds a popup to all images on the Web. Left-click any image in a page and you’ll get a menu that notifies you of its URL:

jetpack.tabs.onReady(function () {
  $("img", this.contentDocument).each(function () {
    var imgNode = this;
    var myMenu = new jetpack.Menu([{
      label: "Show Image URL",
      command: function () jetpack.notifications.show(imgNode.src)
    }]);
    myMenu.popupOn(imgNode);
  });
});

Tile and grout.

The first two snippets also illustrate Jetpack’s new Twitter API, which hews close to Twitter’s own. If you’re already familiar with that API, there’s nothing new to learn, and if you aren’t, it’s easy, and you can add the phrase “Twitter API” to your resume. (You’re welcome.)

If you have thoughts on these new APIs—or bugs or patches—let us know. More info and examples at the links below.

• Menu API and examples
• Twitter API and examples
• Jetpack home
• Find a bug?
• Discussion list

November 10, 2009 06:41 PM

With the landing of Bug 311965 time spent during startup in app update on mobile devices should have improved by around 72%. On Firefox WinCE this equates to reducing the time spent during startup in app update from over 180ms to around 50ms. This is on top of a previous reduction of around 25% from over 200ms to around 150ms as measured on Maemo Fennec and with this latest change I estimate the time spent in startup on Maemo Fennec to be around 40ms.

Progress:

• Landed on trunk and 1.9.2 branch – Bug 311965 [Toolkit] – Refactor nsUpdateService.js to load less code at startup.
• Landed on 1.9.2 branch – Bug 522583 [Toolkit] – nsUpdateService.js.in cleanup (remove previous update migration code, defineLazyServiceGetter for nsIObserverService, and other cleanup).
• Landed on 1.9.2 branch – Bug 521452 [Toolkit] – nsUpdateService and nsBlocklistService both have getFile(key, pathArray). Had to backout the changes to nsExtensionManager.js.in due to Bug 526441 [Toolkit] – Unable to use FileUtils.jsm in nsExtensionManager.js.in on 1.9.2 due to reftest failures.
• Landed on 1.9.2 branch – Bug 521956 [Toolkit] – nsUpdateService, nsExtensionManager.js.in and, nsBlocklistService include badCertHandler.js

Future targets:

• Finish up several decent sized reviews in my queue I haven’t had time to do.
• Blog about the lessons I’ve learned while trying to improve startup time for app update.
• Investigate Bug 525390 [Toolkit] – 3.5.4 Upgrade failure: entry point js_SaveRegExpStatics could not be located
• Investigate Bug 526441 [Toolkit] – Unable to use FileUtils.jsm in nsExtensionManager.js.in on 1.9.2 due to reftest failures.
• I’m going to try to get Bug 407875 [Toolkit] – Unprivileged users are not notified of security updates fixed for Firefox 3.6.

November 08, 2009 01:43 AM

←

• Started looking again at making Places query APIs async, bug 490714. First need to tackle bug 499985, sorting of query results should be done entirely in SQL.
• “Helped” bz with test failures in blocker bug 526178, binding loading order changed in 3.6b1 compared to previous version of firefox.
• Awaiting Josh’s review on bug 506814, get rid of / Change GetPersistentDescriptor / SetPersistentDescriptor. Spoke to him last week, think he’s pretty busy with more important things.

→

• Work on bug 499985.
• Been thinking about the gap between the Places database and its query code and the janky structure that bridges it. Think more about it, with intensity.

November 07, 2009 08:55 AM

Bit of a weird week – very busy, but not a lot of coding.

Tab matches in Awesomebar

Status

• UI works better now
• Initial work on proper integration into nsPlacesAutocomplete

Loose ends

• None

Next steps

• Finish autocomplete work
• Preferences UI
• More unit tests
• More unit tests
• More unit tests

Target for next week

• Finish autocomplete work + preferences UI

Binding for untrusted text in security dialogs

Status

• No change

Miscellaneous

• Had my first day as a Sheriff on Tuesday – worked out pretty well
• Also had my first security review on Tuesday, for the Plugin Update Awareness project  – that went pretty well too
• New Windows box arrived on Wednesday – now running Windows 7 as my main OS
• Working on moving all my development over to Windows

Reflections

• Having the right tools can make a difficult job into a trivial job
• Pizza and coffee are always the right tools

Related posts:

1. Status update
2. Status update
3. Status update

November 07, 2009 04:11 AM

With the Firefox UI/UX team starting to crank out design ideas for "Places" ( a Mozilla internal name for bookmarks and history) in Firefox 3.7 and 4.0, it's high time the Places team revamped the query API.

Alex Faaborg has posted some initial UI concepts here: http://blog.mozilla.com/faaborg/2009/10/13/browsing-your-personal-web/

I have started to think about how to make an elegant API to do the heavy lifting of querying the Places database for bookmarks, history and related hierarchies. The current Places query API is not simple to use, and we want this to be simple and easily extensible by extension authors, as well as a drop in api for Jetpack.

The bug for this work is here: https://bugzilla.mozilla.org/show_bug.cgi?id=522572

One of our non-goals is to make a snap in replacement for the current API. We get to focus on the new features, like "browsing" your bookmarks and history in content-space, as well as accessing bookmarks and history via the "awesomebar".

I have posted the beginning stages of this work to the wiki, here, the Firefox "project page" is here. We are in a stage of thinking about and sketching what this simple, elegant API might look like, and we would love to get feedback and ideas from our colleagues and the Mozilla community. The Places 3.7 meta bug is here: https://bugzilla.mozilla.org/show_bug.cgi?id=523519

November 07, 2009 02:33 AM

November 07, 2009 02:26 AM

WebGL introduces two interesting concepts that I think have application outside of WebGL, the CanvasArrayBuffer and CanvasArray.  This is all subject to change, of course, though this is what the current Gecko (and others') implementation looks like.  In particular, the Canvas prefix in the names might change soon.

It became clear that pure JS arrays are not a useful way of shoveling around lots of 3D data; their very flexibility makes them impractical for performance-critical uses.  In particular, WebGL often wants to deal with arrays of a specific type -- an array of integers, an array of floats, etc.  Even more complicated is the need to manage multiple types within a single memory region; for performance, it's often preferable to allocate one chunk of video memory, and place coordinates, colors, and other types in there, replacing them as necessary.

There are two portions to the solution: the CanvasArrayBuffer and a set of typed CanvasArray views.  A CanvasArrayBuffer represents chunk of data.  It can be allocated with a size in bytes, but it can't be accessed in any way.  To actually manipulate the data inside a CanvasArrayBuffer, a CanvasArray has to be created that references it.  An example:

var buf = new CanvasArrayBuffer(3*4);
var floats = new CanvasFloatArray(buf);
floats[0] = 12.3;
floats[1] = 23.4;
floats[2] = 34.5;

The above chunk of code allocates a 12-byte CanvasArrayBuffer, and then creates a float-typed view onto the buffer which can then be manipulated (almost) like a normal array.  Of course, the above is cumbersome to write, so there are shorthands that will allocate a CanvasArrayBuffer, and optionally fill it with data from a JS array:

var f1 = new CanvasFloatArray(3);
var f2 = new CanvasFloatArray([12.3, 23.4, 34.5]);

The size of each CanvasArrayBuffer is fixed; there is currently no way to change its size once allocated.

Multiple CanvasArrays can reference the same CanvasArrayBuffer.  For example:

var buf = new CanvasArrayBuffer(12*3*4+12*4);
var points = new CanvasFloatArray(buf, 0, 12*3);
var colors = new CanvasUnsignedByteArray(buf, 12*3*4, 12*4);

This creates a buffer of 192 bytes, which is enough room for 12 3-coordinate float points followed by 12 RGBA colors, with each component represented as an unsigned byte.  The arguments to the CanvasArray constructors are the offset from the start of the buffer (in bytes), and the length (in elements).  The offset must always be a multiple of the element size (to preserve alignment), and the buffer must obviously be large enough for the given offset and length.  If length is not given, the length is assumed to be "from offset until the end of the array buffer"; that value must be a multiple of the element size.  If offset is not given, it's assumed to be zero.

For extra complex use cases, CanvasArrays can reference overlapping regions of a CanvasArrayBuffer:

var buf = new CanvasArrayBuffer(192); // same value from above
var points = new CanvasFloatArray(buf);
var colors = new CanvasUnsignedByteArray(buf);
points[0] = 12.3;
points[1] = 23.4;
points[2] = 34.5;
colors[12] = 0xff;
colors[13] = 0xaa;
colors[14] = 0x00;
colors[15] = 0x00;

In the buffer, this writes 3 float values followed by 4 byte values.  You'll note that this use is significantly more complex, and requires the user to keep track of the current position in terms of whatever element they're modifying (thus setting array elements 12, 13, 14, and 15 for the color).

If an attempt is made to store data in a CanvasArray that doesn't fit within the right type, a C-style cast is performed.  If the data is an entirely wrong type (e.g. trying to store a string or an object), Gecko currently throws an exception, but this might become a silent 0 or similar in the future.

Where does this fit in WebGL?  Any API function that needs an array of data takes a CanvasArrayBuffer.  This avoids placing costly JS array type conversion in a potential critical performance path, and simplifies a number of aspects of the API.  So, VBOs, texture data (if not loaded from a DOM image element or from a CanvasImageData object), index array, etc. all use CanvasArrayBuffers/CanvasArrays for pulling data in and out.  CanvasArrays also help manage memory usage -- an array of byte color data now takes up exactly as much memory as needed, instead of getting expanded out to 4 bytes.  Also, critically, floating point data can be stored as 32-bit single-precision floats instead of 64-bit doubles, taking up half as much space when the underlying graphics system can't support 64-bit values.

This API is overall lacking in developer niceties, since the focus was on providing the necessary functionality.  Higher level wrappers can be written in JS to simplify usage.  In addition, by keeping it as bare-bones as it is, it allows for fast implementation on native hardware via the JITs in all the current-generation JS engines.  The web currently fudges around the problem of binary data by passing it around either in strings (because JS strings are UCS2, therefore all 8-bit elements are valid, but with a performance and memeory cost), or often encoding as base64 (again going back to strings).  I can see this type of dense/native type access being useful for both the File and WebSockets APIs as a way to exchange and deal with binary data.

November 07, 2009 12:30 AM

Progress

• Put up a patch on bug 507073 for review – it combines the two binary browser components we ship into a single library.
• Started work on bug 520334.

Next Steps

• Get review for bug 520284 and 522842.
• Wrap up investigation into bug 496217 and 441355.

November 07, 2009 12:28 AM

This last week I’ve been focusing on Fennec / Firefox WinCE TS for app update and it looks like we can save around 130ms on startup on Firefox WinCE when using Taras’ patch from Bug 470116 to log the time spent during startup… I expect a similar savings for Mobile Fennec.

Note: we really need to come up with a better way to update each app’s installer manifests and remove-files so when we make changes to toolkit code that adds / removes files we don’t have to get reviews from each app to land the changes. I know bsmedberg would like to remove the requirement for the manifest by only having the files that will be included in each installer under dist/bin but I wonder if it is realistic to do so since each app would need to do this.

Progress:

• Finished up the patch Bug 311965 [Toolkit] – Refactor nsUpdateService.js to load less code at startup.

so it is now ready to land as soon as I get patches for all app’s approved for landing. As time permits I will be blogging about the lessons I’ve learned while trying to improve startup time for app update.

Future targets:

• Land Bug 311965 [Toolkit] – Refactor nsUpdateService.js to load less code at startup.
• Finish up several decent sized reviews in my queue I haven’t had time to do.
• Bug 525390 [Toolkit] – 3.5.4 Upgrade failure: “entry point js_SaveRegExpStatics could not be located” [Windows]
• I’m going to try to get Bug 407875 [Toolkit] – Unprivileged users are not notified of security updates fixed for Firefox 3.6.

November 02, 2009 02:58 AM

Tab matches in Awesomebar

Status

• Refactored
• Experimented with strategies for implementing different UIs in the URL bar

Loose ends

• Should tab matches be weighted differently? Need to experiment & discuss

Next steps

• Solidify UI work
• Flesh out autocomplete matching behaviour
• Experiment with weighting tab matches

Target for next week

• Implement keyword & mode to match only tabs

Binding for untrusted text in security dialogs

Status

• No change

Reflections

• When life gives you lemons… give life to Lemonstein!

Related posts:

1. Status update
2. Status update
3. Status update

November 02, 2009 01:51 AM

A little over a year ago, some of my fellow mozillians and I decided we wanted to have a place to host websites and e-mail, stick off-site backups, and perform other disk or CPU intensive things not typically permitted in a shared hosting environment. After  exploring a few options, we decided to split a dedicated server and eventually settled on Voxel as our host.

Of course, with just a few low-traffic websites, backups, and an SSL cert survey or two, we typically found ourselves far under our monthly included bandwidth.  Not wanting to leave our investment underutilized, we took advantage of our server package’s included access to the VoxCAST CDN and put it to work as a Mozilla mirror.

Mozilla’s Bouncer mirror management system distributes traffic proportionally, based on assigned weights. Since we only had a small amount of bandwidth to offer compared to most of the other mirrors in the system, we usually kept our mirror’s weight low to avoid eating up our entire bandwidth allotment. Firefox 3.0.11’s release happened to line up with the end of a billing period where we had some extra bandwidth leftover, so we decided to burn through it by increasing our weight dramatically. Our traffic quickly climbed from a few Mbps to over 3Gbps, which managed to grab the attention of the folks in the Voxel NOC. They pinged us to make sure we were aware of the situation, and after learning what the traffic was being used for and a few discussions with Reed², they generously offered to donate a substantial amount of bandwidth to be used by the Mozilla mirror network.

Everything got setup just in time for the Firefox 3.5 release, and in the four months since, we’ve served more than 1.3 petabytes of updates, installers, and add-ons. And all of that coming from a single origin server that, thanks to VoxCAST, is so lightly loaded it’s able to run a BOINC client most of the time!

As impressive as that is, it’s worth noting that this mirror only accounts for (as of this writing) just over 25% of the total available capacity. Mozilla wouldn’t be able execute releases and updates for all its products with the same level of quality and reliability we all currently enjoy thanks to the behind-the-scenes and often unsung heroes of our mirror network.

So to those who volunteer your time, machines, and bandwidth to make every release and the day-to-day a success, thank you. Mozilla simply wouldn’t be able to do it without you.

¹ Megabytes
² Reed’s back at school and doing some work for Voxel as well – if you were curious as to why he’s not around Mozilla stuff as much anymore

October 31, 2009 05:00 PM

October 31, 2009 12:18 AM

Preamble (with Discussion Question)

I don’t know if there are people out there who like the way they sound in audio recordings, or look on video. I certainly don’t. I don’t think it’s a self-image issue, either; and I know I’m not alone. My recorded voice lacks the resonance I experience internally, and my recorded image just looks… mouthier (?!) than I imagine myself to be. I don’t even know what that means.

Proposed:

Nightingale’s Corollary to the Uncanny Valley Hypothesis: The depth of one’s psychological attachment to, and familiarity with, one’s own image, amplifies feelings of canny/uncanniness. This can result in greater than average affinity for moderately dissimilar representations (c.f. the popularity of “realistic cartoon avatar” generators, or caricature artists), but also particularly heightened sensitivity to minor dissimilarities.

[Discuss. Cite examples.]

The Point (i.e. Where You Should Have Started Reading)

I bring this up because the inimitable duo of Alix and Rainer recently took some of my scattered ramblings and knit them together into an educational piece on some of the security features in Firefox. I think they did a lovely job:

<video controls="controls" src="http://videos.mozilla.org/firefox/3.5/security/security.ogv" width="400"><object height="295" width="480"><param name="movie" value="http://www.youtube.com/v/TBOuQhKEs2w&amp;hl=en&amp;fs=1&amp;rel=0"><param name="allowFullScreen" value="true"><param name="allowscriptaccess" value="always"><embed allowfullscreen="true" allowscriptaccess="always" height="295" src="http://www.youtube.com/v/TBOuQhKEs2w&amp;hl=en&amp;fs=1&amp;rel=0" type="application/x-shockwave-flash" width="480"></embed></object>
</video>
YouTube

In very much related news, Drew worked with Alix and Rainer to put together a video that talks about some of Firefox’s privacy features. I find it much easier to listen to Drew’s calm, matter of fact, “we did awesome stuff, and want you to know about it” delivery. I suspect you will, as well.

<video controls="controls" src="http://videos.mozilla.org/firefox/3.5/privacy/privacy.ogv" width="400">
<object height="295" width="480"><param name="movie" value="http://www.youtube.com/v/kz2_Yo5p2LA&amp;hl=en&amp;fs=1&amp;rel=0"><param name="allowFullScreen" value="true"><param name="allowscriptaccess" value="always"><embed allowfullscreen="true" allowscriptaccess="always" height="295" src="http://www.youtube.com/v/kz2_Yo5p2LA&amp;hl=en&amp;fs=1&amp;rel=0" type="application/x-shockwave-flash" width="480"></embed></object></video>
YouTube

October 27, 2009 08:46 PM

In many ways working on concepts for the Linux theme has probably been more challenging than for the Mac and Windows themes. Probably the most difficult part is the absence of a unified look and feel.

There are many flavors of Linux with various themes. As well as two major desktop environments along with several other minor ones. All with their own unique style. Even though it’s challenging one really great thing about working on a Linux theme is how amazing these environments are looking now.

As I stated in my post about the Mac theme refresh one of the goals has been a greater cross platform visual consistency. This shouldn’t necessarily come at the expensive of a native look however. For 3.0 a lot of fantastic work was done on making Firefox on Linux use native controls and icons. It would be really nice to balance that with picking up some of the same ideas from the Windows and Mac theme.

 

Refresh for Firefox 3.7

In addition to theme and UI changes already discussed for Firefox 3.7 and 4.0, there are some proposed Linux specific visual changes:

• Consistent Back/Forward Buttons: Use the same back/forward shape as on the other platforms. The back button would use the same texture as the other buttons however it would be round and larger.
• Buttons vs Icons: Switching to a button+glyph style for the toolbar items. This would be instead of the more representational style that is widely used. It also is a deviation from the common system standard of having icons and then a button shape on hover.
• Curvier Tab Shape: Match the tabs to the proposed tabs on Windows and Mac while keeping the native texture and color.
• Removing Toolbar Separators: Goes a ways towards reducing visual complexity as well as external consistency.

 

Alternative Icon Treatment

Another idea would be to include the back/forward shape but use traditional icons instead of glyphs everywhere else. However this looks a little strange and doesn’t meet the goal of cross platform consistency.

 

How Would This Look with Various System Themes

As I talked about above there are a wide variety of distinct themes available for Linux. The most ideal approach to this would be to use the native button style, theme specific icons and replace the glyphs based on color scheme.

Some examples of how this could work out:

 

Refresh for Firefox 4.0

As discussed perviously a goal for 4.0 is to reduce the UI footprint of Firefox. Adding tabs to the top of the UI accomplishes this (along with other things).

Please keep in mind this is all customizable.

For this configuration the menubar would be hidden and Page and Tools menu buttons would be aded to the toolbar. The titlebar would extend down behind the tabs.

 

Ongoing Discussion and Feedback

If you would like to leave feedback on these designs or just follow along there are few places to do that. You can comment on this blog or visit the Linux Theme Refresh wiki page.

October 26, 2009 04:58 PM

This last week I’ve been focusing on Fennec / Firefox WinCE TS for app update. According to Taras’ logs for Maemo Fennec this lessens the time spent in nsUpdateService.js during startup by around 50ms and there should be a similar win on Firefox WinCE.

Progress:

• Landed on the mozilla-1.9.2 branch – Bug 512651 [Toolkit] – lessen the write access checks during startup and remove final-ui-startup observer. According to Taras’ logs for Maemo Fennec this lessens the time spent in nsUpdateService.js during startup by around 50ms and there should be a similar win on Firefox WinCE. It appears that there was around a .5 % win on trunk Windows desktop TS as well though this may be a combo of this and Bug 521262 which landed at the same time on trunk.
• Landed on the mozilla-1.9.2 branch – Bug 521371 [Toolkit] – Extraneous ‘2′ written to the update log file.
• Landed on the mozilla-1.9.2 branch – Bug 521262 [Toolkit] – XREDirProvider provides app chrome dir twice, making us parse manifests twice. This caused non-xulrunner apps to parse the manifests in the app dir twice on startup so there might be a win on Firefox WinCE.
• Landed on trunk – Bug 521452 [Toolkit] – nsUpdateService and nsBlocklistService both have getFile(key, pathArray). This gets us closer to fixing Bug 311965 [Toolkit] – Refactor nsUpdateService.js to load less code at startup.
• Landed on trunk – Bug 522583 [Toolkit] – nsUpdateService.js.in cleanup (remove previous update migration code, defineLazyServiceGetter for nsIObserverService, and other cleanup). This gets us closer to fixing Bug 311965 [Toolkit] – Refactor nsUpdateService.js to load less code at startup.
• Patch in progress for Bug 311965 [Toolkit] – Refactor nsUpdateService.js to load less code at startup. This should translate into TS wins especially for Fennec and Firefox WinCE.

Future targets:

• Finish up Bug 311965 [Toolkit] – Refactor nsUpdateService.js to load less code at startup.
• I’m going to try to get Bug 407875 [Toolkit] – Unprivileged users are not notified of security updates fixed for Firefox 3.6.

October 23, 2009 09:08 PM

Starting with Firefox 3.6, only well-known components shipped with Firefox will be loaded from the application components directory.  Any other components (both binary and script) will be ignored.  This work might also be backported to the 3.5 branch, but that decision has not been made yet.  There are a number of reasons why this decision was made.

Firefox, through Gecko, has always had a flexible component-based architecture.  In particular, creating binary components to interface with the OS or with other applications is fairly straightforward, though ultimately dangerous.  Binary components have full access to the application and OS, and so can impact stability, security, and performance.  What's worse, in a binary component, the line between supported/frozen and completely unfrozen internal Gecko interfaces is blurred, making it easy to create a binary component that works well against one very specific version of Firefox (potentially as specific as a minor security release), but causes serious problems with any other version.

As we've seen the popularity of Firefox increase, more and more binary components have been written to interface between Firefox and other applications.  However, we haven't provided great guidance about the appropriate way to do so.

The only supported way of adding functionality to Firefox (whether a binary component is required or not) is through an add-on. This has many advantages for users: they can see that additional functionality is installed in the Add-ons Manager, and from there they can easily enable or disable it, as well as check for and receive updates.  We're working on improving the user experience when third-party addons are installed in system-wide locations.  Also, critically, add-ons include information indicating their compatibility with specific versions of Firefox.  Having this version information allows for safe upgrades, especially when binary components are present.

Currently, third-party applications can drop binary components into the Firefox application's components directory and expect them to be loaded as part of our normal startup.  This causes a number of problems, not the least of which is the removal of the user control that add-ons provide.  Unfortunately, a number of third-party applications are using this approach to integration, and are currently causing Firefox 3.5 users stability problems.  Many of these components were written for Firefox 3.0, and have not been updated for Firefox 3.5; a situation that we have no way of detecting because of the lack of versioning information on these "bare" components.  Because a number of internal interfaces changed between the two versions, this leads to crashes or other problems when these components are used.

In order to simplify future integration with native code, Firefox 3.6 will include support for JSCtypes for add-on developers.  This approach is greatly preferred over writing binary components.  For example, a third-party component that would like to perform some action implemented in native code when an event is received can write the integration pieces in Javascript (capturing the event and so on), and use JSCtypes to make function calls to regular non-XPCOM component native code.  Keeping as much of add-on code in Javascript reduces the impact of internal changes to Firefox, and allows for much easier maintainability.

(If you are a third-party application developer and have questions about integration in Firefox, please contact me -- I'd be happy to put you in touch with the right people who can answer questions and provide guidance.)

October 23, 2009 07:08 PM

My cat ate my homework last week. So this week you get double update goodness.

Tab matches in Awesomebar

Status

• Started working on project
• Read through a lot of previous work and feedback
• Proof-of-concept code done, matching Limi’s design

Loose ends

• None

Next steps

• Turn proof-of-concept into a real patch

Target for next week

• Refactored
• Start proper integration into places autocomplete and related prefs

Binding for untrusted text in security dialogs

Status

• Started working on project (low priority)
• Read background information

Loose ends

• None

Next steps

• Gather more information

Target for next week

• Discussions with Jesse and Johnath

Miscellaneous

• More miscellaneous wanted bugs for 3.6 (and some not).
• Worked on patches for bugs 435726 and 397937, which have been a personal annoyance for a long time

Reflections

• Technology, like biology, has a word for stable: dead

(Quote from Mike Shaver)

Related posts:

1. Status update
2. Status update
3. Status update

October 23, 2009 11:30 AM

(You are encouraged to read this article with its formatting and typography intact, instead of in this RSS reader)

From the dept. of status update slacking, the two previous weeks:

Plone

• The new theme for Plone 4 was merged, along with all the other improvement branches that were proposed for this release. Impressive work by everyone involved in Plone 4! It’s looking to be a great release.
• Completed my keynote presentation. More than a week before I’m actually presenting. I know, crazy.
• Worked with Eric Steele and Israel Saeta Pérez to improve the roadmap on plone.org, which is now fully converted to Trac. Still needs better descriptions, but the hard part is done. Thanks, guys!
• Worked with Jon Stahl to identify some opportunities around improving plone.org and our evaluator experience. Looking forward to taking a crack at this with Joel Burton after the conference is over.

Goals for the coming week

• Finish my Plone Conference talk on advanced CSS layouts at Plone Conference 2009.
• Get Deco in shape to demo it at the conference keynote.
• Finish article on how to improve the social aspects of the conference for people that are new to the community.

Firefox

• Prioritized the UX work we want to land in Firefox 3.7. There’s now a list at the top of the UX index.
• Did some investigations on how Chrome handles its installer experience on Windows as part of making the experience better, similar to the proposed Mac installer improvements. Findings:
  • Chrome Frame requires admin privileges to install, Chrome itself does not. Counter-intuitively.
  • Tested the new Firefox installers on a couple of locked-down corporate computers, and it turns out you can install it in much the same way as Chrome does their install.
  • We should probably still try to make the install experience better on Windows, but doing the same as Chrome is probably not a good idea — their installer failed on several test computers.
• Worked with Alex Faaborg to get the first draft of site-centric preferences improvements out, he has posted them internally for now, but look out for them soon. Props to Alex for doing the legwork on the mock-ups.
• Was going to produce a screencast to demonstrate the effect of the prioritized tab loading in Firefox 3.6 with Paul O’Shannessy, but there were some loose ends to tie up first, so we agreed to do it early next week instead.
• Worked with Jinghua to get things ready for Taskfox user testing. We now have a consent form, and a rough outline of the upcoming user studies.
• Got closure on the remaining Taskfox issues — props to Blair for fixing the last remaining bugs that were in the way of user testing. There’s a new build you can (and should!) test.
• Did some investigation around the status of inline PDF display for 3.7. It’s 2009, we should really have this by now. There were patent issues in the past, but need to figure out the current situation.
• Had a great conversation with John Lilly about Firefox strategy, where UX should focus — as well as demoing some of the things we want to do in Firefox 3.7 & 4.0. Will talk about this in the UX team meeting this week.
• Finally got back to the Resource Package work again. Hoping to wrap up a version with the local storage manifest variant with Vlad this week.

Goals for the coming week

• Finish the third draft of the Resource Package spec, hopefully with input from Vlad, jst, bz.
• Continue refining the preferences redesign with Faaborg.
• Write up scripts for the user studies of Taskfox, hopefully with Jinghua’s valuable input.
• Work with the rest of the UX team on splitting our list of UX focus areas for Firefox 3.7 into more detailed requirements, and file bugs so it can be tracked.
• (Aspirational, 4.0) Work on the tab sidebar mock-ups.
• Wrap up the things that can be completed before I head to the Plone Conference in Budapest.

Other

• Falling down stairs on your back/shoulders/elbows should be avoided — or at least be drunk if you do so, it’s more embarrassing when you’re not. Ask me how I know. Ow.
• Educate world on glorious feeling of using en-dashes and hair spaces in headlines. Dashing!
• Hopefully getting together with Mike & Nicholas this week to save Mac window management from itself. Stay tuned.
• Around 400 people registered for this year’s Plone Conference. It’ll be awesome, can’t wait.

October 19, 2009 06:48 AM

October 17, 2009 06:14 AM

The Mozilla Plugin Check page was released today, so I loaded it up to see the latest changes. “Looks good,” I thought, and skimmed the list of plugins it displayed for me. Quicktime, Silverlight, Flash, and… Woah, wait.

Silverlight?

On my OS X box? How the fuck did that get there? I sure don’t remember installing it. Grrrr!

A little web searching later, and I found my answer. It’s silently installed with Flip4Mac (a set of Quicktime components to allow playing Microsoft proprietary media formats on OS X), which I had installed a week or two ago to try something, and then promptly forgot about. The installer doesn’t have a word to say about it, unless you click a little “Customize” button on the 5th screen on the install:

That really annoys me. Silent, sneaky software installs are evil, evil, evil.

At least Flip4Mac includes an uninstaller, so I ran that. It’s actually a package, so you’re confusingly prompted to “Select the disk where you want to install the uninstaller software.”, but it was otherwise painless. Now to just restart my browser, check about:plugins, and…

GAHHHH! It’s still there. Their uninstaller uninstalls the Flip4Mac bits, but not the Silverlight plug. Solution:

rm -rf /Library/Internet\ Plug-Ins/Silverlight.plugin/

It’s finally dead, Jim.

October 14, 2009 01:24 AM

Progress:

• Landed on trunk – Bug 513958 [Toolkit] – Firefox silently fails to start if %APPDATA% variable is missing. This is a crash on startup caused when the call to SHGetFolderPath, SHGetSpecialFolderLocation, SHGetPathFromIDListW, SHGetSpecialFolderPathW, and friends fail.
• Landed on trunk – Bug 521371 [Toolkit] – Extraneous ‘2′ written to the update log file.
• Landed on trunk – Bug 512651 [Toolkit] – lessen the write access checks during startup and remove final-ui-startup observer. This reduces time spent in nsUpdateService.js by around 50ms on Maemo and I suspect a similar win on WinCE.
• Landed on trunk – Bug 521262 [Toolkit] – XREDirProvider provides app chrome dir twice, making us parse manifests twice. This caused non-xulrunner apps to parse the manifests in the app dir twice on startup so there might be a win on Firefox WinCE.

Future targets:

• I’m going to continue invesitaging TS wins on Maemo / WinCE / WinMo in Bug 311965 [Toolkit] – Refactor nsUpdateService.js to load less code at startup. This may translate into TS wins in other components.

October 12, 2009 10:44 PM

Oops, forgot about last week’s status update. Usually when that happens, I catch it on Monday; so the rest of the world sees it appear on Sunday. Anyway, here’s last week. In retrospect, it was a much calmer week.

Plugin Update Awareness

Status

• Everything has smoothly landed on branch and will be in Beta 1
• Blogged about it – read it here if you haven’t already
• Closed project

Miscellaneous

• Working on various blockers/wanted for 3.6

Reflections

• To learn is to live

Related posts:

1. Status update
2. Status update
3. Status update

October 12, 2009 10:26 PM

October 12, 2009 06:07 AM

Progress

• Landed bug 499123 on the 1.9.2 branch.
• Bug 475289 landed on trunk for a ~20ms improvement with the currently shipped plugin set.
• Reduced the number of getService calls in the microsummary service.
• Wrote a patch to get the search service using the new update-timer category, removing one of the last few pieces of non-critical work the search service does on startup.

Next Steps

• Need bug 520334 to avoid losing the benefits of 475289 once we ship a plugin with an update URL.
• Work on delaying spell check dictionary initialization in bug 496217.

October 09, 2009 08:33 PM

Last weekend I was at MozCamp EU 2009 where I spoke with people there about the future of Firefox, and why I believe we need to accelerate our pace of delivery. This isn’t news to anyone who’s been on development or delivery calls for the past few months, or working on blocker bugs for the upcoming Firefox 3.6 release, but I wanted to add some context and structure around why I feel this to be increasingly important.

There’s the obvious challenge of competing with not one but three industry giants. This is the competition we wanted, the competition we created, and the competition that has benefited the Internet and all of its users. It’s what we set out to do as a community. The new challenge I see is ensuring that we don’t let the open web technology stack become turned into a commodity. The competition in the next 2 years will be about how the technology used to create exciting, rich, interactive experiences online is developed.

At the same time, Jay Sullivan, Chris Beard, Mike Shaver, myself, and many other people have been working on expressing a structure for understanding how to build a strong direction that can be used to draw a roadmap for the future of Mozilla products. The two topics are obviously related: in order to move as quickly and efficiently, we need to know where we’re going.

I’ve embedded (and linked to) my presentation below; I put it on SlideShare.net* yesterday and the editors there bumped it to the front page, which is exciting to me as it means that the messages we’re putting forward are resonating with people.

I expect that the roadmap will evolve over time, and will be working with many people in the Mozilla project to add more detail in the coming weeks and months.

(* yes, I realize that there’s an irony to these slides being shared through a Flash-based viewer; I put the slides together using Apple Keynote, and the export to HTML version really doesn’t work so well.)

(edited: Saturday, October 10th for clarity)

October 09, 2009 06:15 PM

If you’re running nightly builds of trunk or Firefox 3.6, you may notice a smoother progress bar while installing the nightly updates…

The old progress bar behavior had always seemed a bit odd to me — it would do nothing for a bit, move to about 15% point, and then suddenly finish. I didn’t get around to looking at why it did that until I used the updater on a Windows CE netbook. The device is a lot slower than a normal system, so the unusual progress bar movement could appear frozen for over a minute! That’s really poor UI feedback, so I set about fixing it.

You can read the gory details in bug 517102, but the end result is that the progress bar now tracks progress more accurately, and the updater runs 3 times faster too!

October 09, 2009 07:09 AM

While sheriffing yesterday, I was a bit confused when dbaron asked if I was looking into all the orange. The tree (http://tinderbox.mozilla.org/Firefox/) looked mostly green, except for a handful of earlier Talos oranges. So, yadda yadda, it turns out that most of the test boxes report to a separate tinderbox tree now — http://tinderbox.mozilla.org/Firefox-Unittest/. There are similar splits for the 3.6 and 3.5 trees.

This was probably announced somewhere, but 3 other developers also didn’t know this was the case. So, I figured a blog post was in order.

Tinderboxpushlog already includes both sets of data, and I’ve just updated isTheTreeGreen.com to use both sets as well.

October 08, 2009 10:13 PM

You may have noticed that both Firefox 3.5.3 and 3.0.14 will warn if an outdated version of the Abobe Flash Player plugin is installed.

This is because old versions of plugins can cause crashes and other stability problems, and can also be a significant security risk. But this was just one of the first important steps in providing a safer and more stable experience when using plugins.

Additionally, the awesome WebDev team have been developing a Plugin Check web page that will look at all your plugins, and warn you which ones are out of date and therefore potentially have security or stability issues. And since finding and installing an updated plugin can also be tedious, that page will also provides a link to the latest version of each outdated plugin. They’re still testing to make sure the majority of plugins are detected correctly, so are asking for your help in testing it. You can help out and try it yourself, by visiting https://www.mozilla.com/plugincheck/

Firefox 3.6 will have this integrated to make sure users know when they have an outdated plugin installed, without having to manually visit the Plugin Check page. Whenever you load a page that uses a plugin that is out of date, you’ll get this warning:

Clicking on “Update Plugins…” will bring you to the Plugin Check page. Additionally, the Plugins tab of the Extension Manager (Tools -> Add-ons) will indicate which of your plugins are out of date. You can also get to the Plugin Check page from there.

This is in the latest nightly builds of Firefox (trunk and branch), and will be in Beta 1. Since the Plugin Check page is still being tested, and not yet available via the main mozilla.com site, the URL that the nightly builds of Firefox have is to a non-existent page. This will of course be fixed once the Plugin Check page has had more testing.

Updated 30/10/09: Changed the URL for the Plugin Check page to point to the production-version.

Related posts:

1. Status update
2. A good and safe Internet
3. Status update

October 05, 2009 11:23 PM

Recently the Firefox UX team settled on a firm UI direction for Firefox 3.7 and 4.0. The feedback was really amazing and I wanted to thank everyone who took the time to comment.

Subsequently I have turned my attention to how these changes would look on a Mac. The overall design changes for Firefox 3.7 on Mac are mostly the same as what is being proposed for Windows. Structurally they are the same with the notable exception of the menubar not being hidden. Since the menubar is not being removed that means the Page and Tools buttons will be off by default.

One goal of this visual refresh is an increased amount of cross platform consistency where it makes sense. This means we have tried to incorporate similar(or even identical) shapes for items such as buttons, glyphs and tabs. The changes to make these things fit in are how they are styled and textured.

Feedback that would be most helpful is constructive criticism specific to visual treatment. For example that button is too glossy, or that bit isn’t native enough, or maybe this color would work better, etc. Or any other kind of appearance feedback and ideas. Since this a very visual topic if you feel like a mockup would be better at conveying your ideas that would be great!

Refresh for Firefox 3.7

These are the changes from the current Mac theme:

• Button Shape: Using rounded rectangles instead of the curved-end buttons found in 3.0–3.6. This will match the native button shape as well as the shape planned for Windows.
• Button Texture: Deviation from the current bright and flat gradient to a slightly darker gradient. Also added a slight gloss and edge highlight for some added dimension/depth.
• Removal of Bookmark Bar Texture: Removal of the glossy bookmarks bar texture for less visual complexity and more streamlined look.
• Tab Shape: Slightly more defined tabs. Also rounded edges connecting to the toolbar.
• LocationBar Shape: Use a rounded rectangle LocationBar instead of a curved-edge. This creates a visual distinction between the LocationBar and the SearchBar even though the LocationBar is still technically a search field.
• Hiding the Tab Overflow Icon: Hide the tab overflow icon unless there is actually overflow.

Differences from the Windows theme:

• Back/Foward Arrows: Use system standard back/forward glyph shapes instead of the Windows arrow with a tail.
• Hanging Tabs: Instead of the tab attached webpage style seen in Windows we retain the hanging tabs approach from 3.0. This is the de facto system standard (e.g. Safari, Terminal, most 3rd part apps with tabs).
• No Icons on the Bookmarks Bar: This reduces icon overload and matches Safari.

An example of how it would look with “Small Icons” enabled.

Other Tab Ideas and Experiments

Some other ideas were also explored in regards to how to handle tabs visually. These aren’t necessarily things that are being proposed. However they might be a good springboard for discussion.

• Page Attached Tabs: In addition to the hanging tabs idea there was also some exploration with having page-attached tabs. This approach would match other platforms more closely as well giving a direct visual link between the webpage and the tab containing it. However it is less clean visually as well as feeling foreign on the system.
• Page Integrated Tabs: A more experimental idea are tabs that actually acquire attributes from the webpage. Such as approximating background color. This gives a direction visual link between the page and the tab and could help to quickly identify tabs.
• Rectangular Button Tabs: An experiment with tabs that are not attached to the toolbar or the page but are more like tab buttons.

Refresh for Firefox 4.0

Style changes from 3.7 to 4.0 are fairly minimal except for new elements that must be styled. In particular how to handle tabs-on-top as well as:

• Extensions Area: Proposed idea is to be stylistically different from the rest of the toolbar. Lighter and slightly raised.
• Identity Button: The Identity button can be seen in the upper right of the mockup. The idea is to be attached to the window, much like a label or a tag.
• Search Selector Style: The Identity button can be seen in the upper right of the mockup. The idea is to be attached to the window, much like a label or a tag.

An example of how it would look with “Small Icons” enabled.

An alternate style with a darker background. This would make active tabs stand out more.

Identity Buttons Variations

Did some experimentation with how to handle the profile identity button. Something that I think is very strong is the attached/label version.

• Light Rounded Background Version: Slight background to imply that it is a button. Might be odd because that kind of background usually implies “selected”.
• Attached/Label Version: Attached to the window. Visually much like an identity label or a tag. This is branded as your browser.
• No Background Version: No background. Could have a background on hover/active. Fits in with other applications with elements in titlebar (e.g. iCal’s timezone switcher).

Ongoing Discussion and Feedback

If you would like to leave feedback on these designs or just follow along there are few places to do that. You can comment on this blog, head over to the dev.apps.firefox thread on this topic or visit the Mac Theme Refresh wiki page.

October 05, 2009 03:09 PM

Plugin Update Awareness

Status

• Landed on trunk
• Small fix needed in bug 520295 (awaiting review)

Loose ends

• Once the URL of the plugin update page is finalised, the pref may need updating (bug 520444)

Next steps

• Land bug 520295
• Fix/close bug 520444
• Land on branch
• ???
• Profit!!!

Target for next week

• Blog about this (hopefully today)
• Get everything landed on branch

Miscellaneous

Blockers/wanted fixed on trunk:

• 519486 – Some themes are illegible with the text shadow implementation
• 467601 – long bookmark names (page titles) will hide tagging icon and tags’ text in location bar dropdown list (overlaps, covers up)
• 432213 – Bookmark dialog position incorrectly when bookmarking frame
• 468881 – Save Frame As… option appears when not necessary in File Menu

Reflections

• Mistakes are only bad if you fail to learn from them

Related posts:

1. Status update
2. Status update
3. Status Update

October 05, 2009 01:48 AM

October 02, 2009 10:08 PM

This is a central feature that HTML5 videos in Firefox lacked compared to flash videos. What we’ve implemented now is a start and still rough around the edges: the only UI to get into full-screen mode is a context menu item, switching to full-screen playback isn’t as seamless as it should be, the controls haven’t been optimized for that mode, and upscaling isn’t accelerated. Nevertheless, it works.

To test this, just get the latest branch or trunk nightly and visit an open video source of your choice. I believe the biggest ones are still TinyVid, Wikimedia Commons and The Video Bay. openvideo.dailymotion.com won’t work because it prevents the user from opening a video’s context menu.

October 02, 2009 01:09 PM

The throbber as you know it from Firefox 3.5 and before does a decent job of indicating activity, but it doesn’t tell you how much progress has been made. A background tab may already have 90 per cent of its resources and be usable, or it may have stagnated at 20 per cent. The new pie-chart throbber addresses this by

1. filling itself up as progress is made and
2. starting to pulse when progress is slow or has stalled, indicating that the browser hasn’t hung up and is waiting for more data.

As a pleasant side effect, the new throbber also eats fewer CPU cycles than the old one.

Grab a nightly, give it a try, report bugs!

September 30, 2009 03:38 PM

A few months back I got this wild idea that you could insert trace-logging code (not jit-tracing, that's something else) into more or less arbitrary C++ by redefining certain C++ keywords as macros. It turns out that you can, in fact, make this work, at least for certain non-trivial cases. Notably, I've been able to compile an instrumented version of Firefox on OS X using this technique.

I'm not sure whether the technique is generally useful, but given our new focus on crashes and hangs, I thought I'd at least mention it. It's probably not particularly useful for crashes but it may have some utility for debugging hangs. I used an earlier version of this code to debug a Firebug hang (Bug 497028), although in that case I already had a good idea where the problem was and I probably could have used the debugger just as effectively.

Here's the latest tracing code, which I have in a file called "quicktrace.h":

  #ifdef __cplusplus
    #include <stdio.h>
    #include <string.h>
    static void QuickTrace(const char *fileName, int lineNumber)
    {
      if (lineNumber % 100 != 0) return;
//    if (strstr(fileName, "/js/") != NULL) return;
      fprintf(stderr, ";;; %s %d\n", fileName, lineNumber);
    }
    #define if     if (QuickTrace(__FILE__, __LINE__), 0) {throw 0;} else if
    #define for    if (0) {throw 0;} else for
    #define switch if (0) {throw 0;} else switch
    #define do     if (0) {throw 0;} else do
    #endif

I inserted this code globally by adding the following two lines to my .mozconfig:

  export CXXFLAGS="-include /Users/cbartley/dev/mozilla-e/src/quicktrace.h"
  ac_add_options --enable-cpp-exceptions

Note that the use of exceptions is non-functional -- the only purpose is to suppress warnings about code paths that don't return a value. If you don't care about the warnings you can dispense with the "throw 0" statements in the header file and the --enable-cpp-exceptions in your .mozconfig file.

Notes:

• This is unquestionably an abuse of the preprocessor. Don't go down this route unless you really think you know what you're doing.
• If you really want to create an instrumented build, there are better ways to do it, for example Taras Glek's "Pork" tool. Even using shell scripts and sed to create an instrumented source tree might be a better choice.
• I think the code in this post will probably work on any GCC-based build, but I don't know for sure. As far as I can tell, Visual C++ doesn't have an equivalent of GCC's "-include" flag and I haven't tried this on Windows.
• To do useful trace logging you really want a global implementation of the "QuickTrace" function. This is somewhat challenging for Firefox because of the way it's linked. I'm leaving this part as an exercise to the reader.
• The Firefox build actually compiles some tools from source and then uses those tools later on in the build. This means that if you're going to generate logging from the trace function you do not want to send it to stdout.
• It might make more sense to include the quicktrace.h header file from another very commonly used header file. This might be the only option on Windows anyway.
• I think it should be pretty easy to build an instrumented Firefox using this approach and the Try server. I haven't actually attempted this yet, though.
• If you generate output every time the trace function is called, it will be unbearably slow.
• You can't generate a proper call graph using this approach, although with some post-processing you could probably get a useful approximation of a call graph.
• There's probably some caveat that I forgot to mention.

 

Permalink | Leave a comment  »

September 29, 2009 11:24 PM

(You are encouraged to read this article with its formatting and typography intact, instead of in this RSS reader)

One of the minor tweaks that we want in Firefox is the ability to switch tabs using the location bar. Yours truly has signed up to help shepherd this into the 3.7 release on the UI side.

This proposal is based on existing work from Alex Faaborg and thoughts from Madhava and Aza Raskin around putting tabs in the location bar, and doesn’t stray very far from their proposals, so read those first.

There are some smaller changes we want to try, as they simplify the interface:

Apologies for butchering Faaborg’s original image for demonstration purposes. We might also want to tweak the wording to say something like “Switch to open tab” or similar to emphasize that aspect.

List the two choices adjacent to each other instead of using keyboard qualifiers like Shift or Alt

We don’t want to introduce modes here if we can avoid it.

Don’t show the URL as part of the entry for the already open tab

Loading a URL means loading the page — so we use this as an implicit indicator that the page will actually be loaded in the current tab if you select that entry.

The prioritized case is to switch to the active tab if one exists

We have to test different weightings vs. frecency and how it works in real-life scenarios, but we should be able to find a setting that makes it accurate and predictable.

Only the non-standard case needs a label

We don’t want to use a tab icon or similar here, since there’s already way too much visual noise in the AwesomeBar layout.^{1 1}I’m hoping we can convince Messieurs Stephen Horlander or Sean Martell to give the location bar results some visual design love for Firefox 3.7. In particular, we should get rid of the underline in the current style, since underline generally signifies a link in the browser context, and is a poor choice for a highlighting mechanism. This will require some user testing — but if it’s too confusing, we could add in another label.

An upside of the combined approach is that the entries in the location bar results will keep the same size as the existing ones.

Tab Matching Preferences

We will give people control of whether they want already opened tabs to show up in their location bar results. We add this setting to the location bar settings we already have in the preference pane:

When using the location bar, suggest:

• History
• Bookmarks
• Tabs

Tabs will be off by default, as this is more of a “power user” setting. You have to explicitly choose to turn it on if you want it. This is done to minimize impact for existing users, and to keep the location bar behavior simpler.

We’ll do some user testing with it on by default and see how people react, but we suspect it will be confusing for a non-trivial number of our users. If it turns out it isn’t, we'll make it enabled by default.

Related interface tweaks

We also need more data on how it should behave when you have multiple windows. The current thinking is that it will match any tab in any window. We’ll have to do some testing to see if this is too confusing for people, switching to a different window is definitely a different experience. We might end up restricting it to only match within the current window instead.

Another behavior we should fix as part of this improvement is how the Firefox UI behaves if you have the location bar hidden — currently you get the following dialog if you hit ⌘L to enter a URL when that part of the UI is hidden:

This is a remnant of the old “Open” dialog from earlier versions of Firefox. Instead of showing this, the location bar should slide down from the top and give you the interface you’re already familiar with, and disappear again once you have entered a URL. This way, you can hide both the location bar and the tabs, and just use the location bar to manage both. This also works well with full-screen mode.

Together, these changes fulfill the role of the “Power User” interface we detailed earlier.

We can always tweak this behavior once we have the initial implementation in place, but if there’s anything we didn’t think of — or improvements to the proposed approach — we’re always open to suggestions. In this case, please leave your comments on the Mozilla Wiki page for Tab Matching — thanks!

September 29, 2009 08:24 AM

(You are encouraged to read this article with its formatting and typography intact, instead of in this RSS reader)

Firefox

• Published an updated article on the decisions for Mac installer improvements, and we already have two volunteers looking at the implementation. Gotta love our community.
• Published an article describing how we’ll do tab matching in the Location Bar for 3.7.
• Gave feedback on the first and second iterations of the Mac theme improvements for Firefox 3.7, expect Stephen Horlander to have a blog post about it soon.
• Updated the Projects list to be up to date with everything I’m currently working on.
• Did some process planning to improve longer-term UX vision, details to follow.
• Sketched out some ideas on the Prefs improvements.
• Gathered ideas around session restore improvements.

Goals for the coming week

(some carry-overs & and ongoing tasks from last week)

• Finish the third draft of the Resource Package spec, hopefully with input from Vlad, jst, bz.
• Get closure on next steps for Taskfox.
• Work with Stephen Horlander on refining the new Mac theme for 3.7 & 4.0.
• (Aspirational, 3.7) Start working on a first UI mock-up for how the prefs reorg could look like. Coordinate with the add-on manager redesign.
• (Aspirational, 4.0) Work on the tab sidebar mock-ups.
• (Research) Get data from the tab experiments from Test Pilot, analyze what they mean.

Plone

• Fixed up the remaining issues with the new theme for Plone 4, and submitted it to the framework team for review.
• Fixed most of the issues raised by Martin Aspeli.

Goals for the coming week

• Work with Eric Steele to improve the roadmap on plone.org.
• Prepare keynote & layout talk for Plone Conference 2009.
• Publish an article on how to improve the social aspects of the conference for people that are new to the community.
• Get back into Deco development with Rob Gietema.

September 29, 2009 08:23 AM

If you’re using a recent Firefox nightly, your browser is now capable of installing lightweight themes from Web pages — except that you probably don’t know a single site that offers lightweight themes.

I’ve spent some time creating such themes based on my various website styles. Basically I just had to make the header images wider and specify some colors. You can see the result here.

Note that any site can offer lightweight themes. Each theme installation needs to be confirmed by the user, unless the site has been whitelisted to install extensions and themes (via Page Info > Permissions). Whitelisted sites are also allowed to preview themes to the user without selecting them persistently.

If you’d like to create and distribute your own themes, take a look at the source of the simplified example page that I prepared.

Update: getpersonas.com started working with trunk and 1.9.2 branch builds without the Personas add-on.

September 28, 2009 06:46 PM

I haven’t updated on the blog recently, so here’s the past 3 weeks all at once.

The week of September 7, I was working on a couple blockers.

The week of September 14, I was in Pittsburgh recruiting at the Carnegie Mellon TOC (job fair). I also did some work on Per Tab Network Prioritization (bug 514490) and a password manager performance bug (bug 492197).

This past week I worked on a few different things. I finished the password manager bug (which I hadn’t finished because of a non-syntax-error-syntax-error). While helping Henrik as he was using the storage API, Shawn mentioned that one of the methods I used was deprecated (though never explicitly). So I filed the bugs and fixed the places that used the deprecated code (hint: use executeStep() instead of step() and don’t use mozIStorageStatementWrapper). Filing the bugs took longer than fixing them.

But all of that was unrelated to …

Per Tab Network Prioritization Status

Progress

• Made it a JS module. This was advice from Dietrich to cut down on overhead. Since it was only being used from JS code, there was no need to use XPCOM.
• Made it pref enabled. Right now it’s browser.networkprioritizer.enabled but that’s easy to change.
• Got a first pass look from Shawn, fixed a few things up.

Next Steps

• Reviews. It seems like Boris is the guy for the job. Still need a browser person. Gavin said sometime after Fennec stuff, Connor said 2 weeks. Dolske said “soon”, so he’ll probably be the lucky guy, even if he isn’t a peer.

September 28, 2009 06:11 AM