http://www.google.com/chrome/?hl=en

Since we first released Google Chrome, the development team has been hard at work improving the stability and overall performance of the browser. In just 100 days, we have reached more than 10 million active users around the world (on all seven continents, no less) and released 14 updates to the product. We’re excited to announce that with today’s fifteenth release we are taking off the “beta” label!

continue reading

Sorry if it sounds like I’m drinking the Google Kool-Aid here, but I switched from Mozilla Firefox to Google Chrome as my default browser for the very reason Google’s executives said we should: speed. (Get Google Chrome from Download.com.)

Years ago, Firefox won me over chiefly with plug-ins, tabbed browsing, and some security advantages. But using Chrome removed a bit of friction from the Web I hadn’t realized was there. It felt like discovering I’d been driving with the parking brake on just a bit.

continue reading

Google is considering pre-installing its Chrome browser on personal computers in the search giant’s latest challenge to the dominance of Microsoft’s Internet Explorer.

The move would significantly ramp up the browser war that Google launched against Microsoft when it launched Chrome in September, in the battle to dominate how users access and interact with the web.

Latest industry figures show that Internet Explorer currently enjoys a 71.3 per cent market share worldwide, with Mozilla Firefox at nearly 20 per cent. Chrome is used by less than 1 per cent of all web users, but is still under public testing before a final version is ready to launch.

continue reading

Joe Wilcox writes:

I love Firefox. It’s a remarkably fast and reliable browser. But Mozilla’s dirty little public secret has been its dependence on Google search revenue. This open-source success story is as much about commercial financial support as community participation. Firefox will fail, I predict for the future, unless Mozilla gets more donors or turns the browser back over to the open-source community. Wikipedia is evidence that tiny groups or individuals en masse can do great works. That 1 or 2 percent is a big number when multiplied by 6.5 billion people.

continue reading

After the beta launch in early September, from the first wave of feedback, we realized that a large number of users were facing plugin compatibility issues in Google Chrome. These included Adobe Flash videos not playing, as well as various browser performance issues with Adobe Flash and Adobe PDF document loading. There was even an issue where the browser consumed 100% CPU when users interacted with plugins.

This is exactly the kind of feedback we are expecting from a beta launch. We have invested a lot of effort into automating compatibility testing for large number of web pages but there is nothing like actual user feedback. We are impressed by the user response to the beta and the quality of bug reports filed. Nothing more motivating than a lot of users waiting for your work.

One of the big issues was support for PDF Fast WebView, which is the ability for a webserver to byte serve a PDF document. This allows a client to request specific byte ranges in the file while skipping pages that are not needed. This is supported generically by seekable streams specification in NPAPI, which Google Chrome now implements. This should improve performance with large PDF files or any other content served using Fast WebView.

We had a lot of fun fixing other issues too, and here are the stories behind a couple of them.

YouTube videos stop after six seek attempts:

We received several reports of YouTube videos failing to play. Many reports indicated that this symptom had something to do with using the slider while playing the video. However, we didn’t have a reliable scenario to reproduce in this in-house.

Darin Fisher observed that if you move the slider many times, the video stopped playing. Furthermore, he found out that if the slider was moved exactly six times the video would stop playing. This was interesting, because Google Chrome uses a maximum of 6 HTTP connections per host.

A quick check of the ‘I/O Status’ in about:network revealed that all connections were active. The question then became one of why the existing connections weren’t canceled when the slider was moved.

Darin found that the Flash plugin would return an error when we supplied it data while the slider was moved. In this case a browser is supposed to cancel the connection and that’s what fixed it.

Google Finance chart dragging:

This report was very interesting, due to the fact that it only occurred on single core machines. Of course, in the end we found out that there wasn’t any direct connection between the root cause and single core machines. In Google Chrome plugin windows live in a separate plugin process so a plugin has little or no influence on the browser thread, or so we thought.

After some inspection we found out that when a plugin is receiving mouse input, the browser main thread spins with 100% CPU for sometime. Now, the twist to the story is that since a plugin window is a child of the browser window, thread inputs of the browser and the plugin are attached.

We started looking at the browser message loop more closely. Soon we discovered that MsgWaitForMultipleObjects/PeekMessage APIs behaved strangely when thread inputs are attached. The MsgWaitForMultipleObjects API is typically used to block until an event or a windows message such as an input is available for processing. In this case, we found that it was returning an indication that an input event was available for processing, while PeekMessage indicated no event was available.

This behavior is probably due to the fact that thread inputs are attached and GetQueueStatus, called internally by MsgWaitForMultipleObjects, returned an indication that input is available in the browser thread, while in reality it was intended for the plugin. This caused the MsgWaitForMultipleObjects not do its intended function of waiting, and caused the browser thread to spin.

These are just a few examples of bugfixes we’ve made to Google Chrome to address performance issues related to plugins. We continue to look closely at the performance of Google Chrome, both as a whole and in relation to interaction with plugins, to make sure that users are getting the best browsing experience that we can deliver.

Paul Glazowsi @ Mashable writes:

Remember that thing Google put together a comic book about? Chrome is its name, and Web browsing and AJAX crunching is its game. Well, just recently the latest beta builds are said to have basic Greasemonkey support. With emphasis on basic.

According to Martin at gHacks, the fact that Google doesn’t yet support an extension system within Chrome means that there are some pretty significant ifs and buts about what’s possible and what’s not with the addition of Greasemonkey. Script loading and a metadata issues are purported to be conflict prone.

Continue reading

Researcher Liu Die Yu of the TopsecTianRongXin research lab in Beijing says the spoofing vulnerability is the result of faulty code inserted by programmers from the Mountain View, California search behemoth.

“I don’t see Apple Safari vulnerable in the same way,” he writes in an email to The Register. “They share the same engine(webkit).”

continue reading

Chrome’s share of the browser market is fading as users who abandoned Internet Explorer and Firefox start to return, an Internet measurement company said today.

At the end of its third week of availability, Google Inc.’s Chrome accounted for 0.77% of the browsers that visited the 40,000 sites tracked by Net Applications, down from a 0.85% share the week before.

“The trend line on Chrome still has a slight downward angle, and these weekly numbers reflect that,” said Vince Vizzaccaro, Net Applications’ executive vice president of marketing. Although Chrome popped above 1% within hours of its release, the new browser now reaches that mark only in the middle of the night, U.S. time, Vizzaccaro added.

continue reading at computer world

Since its release a few weeks ago, curious developers have been sniffing through the source code for Google’s new Chrome web browser. Chrome’s source is interesting for a variety of reasons: there’s the new V8 JavaScript virtual machine with its boasts of near-native code performance, the WebKit rendering engine that does all the hard work of understanding and displaying web pages, and (last but not least), Chrome’s secure sandbox designed to minimize the impact of any security flaws that might exist in both the browser and plugins alike. It is this secure sandbox that has piqued the curiosity of some observers, and for a reason that many may find surprising. From reading the source, it looks as though Google has reverse-engineered Windows, and that’s explicitly prohibited by the Windows EULA.

But before looking at the question of disassembly, it’s worth taking a look at how Chrome is put together and at why its security architecture is interesting.

Continue reading at ars technica