As Web users anticipate data from NetApplications and other services that could show Mozilla Firefox having eclipsed the 25% mark in global usage share for the month of November, the beta process for Firefox 3.6 has found an extra gear. Demonstrating that more user input can result in a faster turnover process for developers' builds, rather than the slower process some commercial software producers claim, the latest Beta 4 release addresses some 133 significant bugs, many uncovered by regular testers.

But this won't be all, as 33 more bugs remain on the docket. Contrary to reports, finding more bugs during the beta process is actually a good thing; it beats uncovering them afterward. A regular planning meeting set for tomorrow could set forth a roadmap for how many more public beta releases we could see before RTM, which is still anticipated for the first quarter of next year.

Two very significant additions to the Firefox engine were tried for the first time in the public beta process during the Beta 3 release just a few weeks ago, and they could kick that public release number higher still: First, the browser kicks in support for the async attribute in HTML 5 -- an attribute that enables an element of JavaScript to introduce itself to the browser's interpreter as capable of being executed asynchronously. Without browser support for this attribute, developers have been reluctant to enable support for it, as it will not be presumed by default. But with this attribute explicitly declared, a script can not only be set to run while other scripts are running, but more importantly, it can start before the page has been completely loaded, provided the necessary AJAX resources are free.
This could change everything for page load times, but it won't change things instantaneously. Firefox 3.6 will probably have to be finalized and released before developers give this a shot.

Another very important addition to 3.6 is support for the first time for the W3C's File API -- actually a creation of Mozilla contributor Arun Ranganathan. Assuming the browser is capable of providing security, the API provides asynchronous access to local files, enabling Web apps that work on local documents stored on users' systems -- as opposed to stuff uploaded to "the cloud."

Conceivably, Web apps using this API could be much smarter about how they upload files to remote servers. The user of a Web app such as a word processor or photo editor might never have to upload entire documents or pictures to a server, to make the service useful. That will change the ballgame for Web apps architects in terms of design, as well as solve the most pressing security issue they presently face.

Testers noticing that their anti-virus or anti-malware apps are having trouble with the 3.6 beta, have in recent days learned why: Binary add-ons that anti-malware apps simply drop into Firefox's components directory without formal installation, are no longer allowed to run by Mozilla's engine, which is now checking to make sure only Mozilla's code runs from there. Third-party add-ons will continue to be installed separately, but only through direct Firefox user intervention and approval.

The change was actually announced last month on the blog of Mozilla contributor Vladimir Vukicevic: "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."