Apple and Mozilla last week took a page from Google to beef up the stability of their respective browsers, Safari and Firefox.
Apple’s move may also result in a faster future Safari that’s able to use the multiple cores in most modern machines’ processors, an analyst said.
Last Thursday, Apple developer Anders Carlsson announced
WebKit2, an API (application programming interface) layer for Apple’s version of the open-source WebKit browser engine. Carlsson, who works on Safari at Apple, also contributes to WebKit, the engine that powers Safari and
WebKit mailing list. “This model is similar to what Google Chrome offers, with the major difference being that we have built the process split model directly into the framework, allowing other clients to use it.”
Google pioneered process separation when it debuted Chrome in September 2008. Chrome, for example, uses a separate process for each tab, a practice that helps the browser survive crashes by a plug-in running in one tab or the failure of a Web application in another. Such compartmentalization adds overhead, primarily in memory use — each tab is essentially another iteration of the browser — but can dramatically enhance stability.
Although Chrome jump-started the concept in browsers, its implementation relied on proprietary technology it added atop the core WebKit engine. WebKit2, which until its unveiling last week was an Apple-only project, will be different, Carlsson and other company developers said.
“Chromium by design does not put any of the multiprocess logic in WebKit itself — it just adapts WebKit so that it can be used as a component of a multiprocess application,” said Maciej Stachowiak, who leads Apple’s WebKit efforts, in
another message on the mailing list. “The WebKit2 API provides that logic underneath the API boundary, so it’s not necessary for every client application to implement it for themselves.”
Chromium is the open-source project Google maintains that, in turn, feeds the Chrome browser.
“Simply put, Chromium WebKit did not provide what we needed to build an API that handles multiprocess and can sanely be used by many applications,” Stachowiak added.
“This is a very good idea,” said Valdes of the WebKit2 API framework. “It’s definitely meant to improve both stability and
security of Safari.”
WebKit2 could also portend a much faster Safari, said John Pescatore, another Gartner analyst. “When you’re looking at multicore machines, when each tab is a separate process, then each process—each tab—can be run on a separate core,” Pescatore said.
Key to WebKit is its “non-blocking API,” which ensures that an active process in the browser doesn’t prevent another from executing as it waits for the first to release a necessary resource. The API would be crucial to executing separate processes on separate cores.
“The intent is to create a completely non-blocking API. That is one of our biggest motivations in pursuing this project,” said
Sam Weinig, another Apple Safari engineer.
Carlsson, Stachowiak and other Apple developers writing on the mailing list did not specify a timetable for when WebKit2 would be rolled into the Safari browser. But Stachowiak seemed to point to a far-in-the-future date. “This project is in no way locked in or imminently shipping—it is an early technology preview,” he said
Apple last released a major Safari upgrade in June 2009, when it unveiled
Mozilla also reached a process separation milestone last week when it released the first public beta of what it’s been calling “Lorentz,” a Firefox enhancement that splits some plug-in processes from the core browser.
Although Mozilla is also working on full-scale process separation—dubbed
“Electrolysis”—that’s not slated to ship in a production version of Firefox until late this year or early next, when the company delivers the successor to Firefox 3.6.
Lorentz, which will be folded into Firefox 3.6.4, a minor update now scheduled for release on May 4, prevents crashes by Adobe’s Flash, Apple’s QuickTime or
Microsoft’s Silverlight plug-ins from bringing down the browser. The “out of process plug-ins,” or OOPP as Mozilla calls the feature, is available only for Windows and
Linux ; Mozilla has yet to wrap up work on the Mac version.
Mozilla especially had its eye on Flash for OOPP treatment because Adobe’s software has been responsible for more Firefox crashes than any other plug-in, according to Mozilla. And it has worked other features into Firefox to deal with that plug-in’s problems. Last year, for example, Mozilla kicked off plug-in checking, a feature that determines whether a user is running an outdated, and possibly vulnerable, plug-in, by
focusing on Flash.
Firefox beta with OOPP enabled, tagged “Firefox 3.6.3plugin1” can be downloaded from Mozilla’s site.
The OOPP concept debuted last month when Mozilla released the
second developer preview of the next major Firefox upgrade, which as yet does not have an official version number.
Gregg Keizer covers Microsoft, security issues, Apple, Web browsers and general technology breaking news for Computerworld.]