googlechromium.com

RSS icon Email icon Home icon

  • Chromium and Google Summer of Code

    Posted on April 7th, 2009 admin No comments
    Time is quickly running out for the students to apply for this year’s Google Summer of Code.
    The Chromium project has been accepted as a mentoring organization for this awesome program. This means that over the summer, you have the opportunity to work on new and exciting features for Chromium (and supporting projects) and experience browser development first-hand with a mentor from the project and real deadlines.
    Full guidelines and details on how to apply can be found on the official gsoc website. To participate, pick an idea off our handy list or suggest one of your own (it’s best to discuss it with a mentor first), then write up a proposal on how you’d go about accomplishing the task in the allotted time frame (3 months).
    You can find a list of suggested topics here. These are only recommendations though, feel free to stop by our mailing list or irc channel and suggest something new. If you do decide to write your own proposal, we’re looking for familiarity with the codebase, and lots of intelligent detail. The more details you can provide, the better!
    Student registration runs from the 23rd of March until the 3rd of April. We’re looking forward to seeing the project submissions and expanding our community involvement.

    Posted by Jeremy Moskovich, Software Engineer

    Blogs

  • The Times They Are A-Changin’

    Posted on April 7th, 2009 admin No comments
    Since we launched Google Chrome in September of 2008, we’ve tried to provide insight into the product and its development here on the Chromium blog. In that time, we’ve made a lot of changes to Google Chrome to provide a better experience, and now that change is coming to the Chromium Blog. This morning, we launched a new blog, called the Google Chrome Blog. 
    The Google Chrome Blog is intended to highlight points of interest to general users, in a way that is accessible to as wide an audience as possible. It’s where you will read about new features that have been released, find interesting tips on how to get the most out of Google Chrome, and stay plugged into the product in general. Many of the types of posts that previously would have surfaced here, such as announcements of our spell-checking improvements, will now appear on this new blog instead of the Chromium blog.
    Have no fear, the Chromium blog will still exist, but now with a renewed focus on the original purpose of the Chromium blog. The blog will be dedicated to announcements of things that are happening within the Chromium project itself. We’ve always felt it important that, as an open source product, we do our work in the open (from general and technical discussion groups to code reviews to design docs) and stay in touch with the open source community. We’re going to take this opportunity to try to be more communicative about project status, and news of note particularly to the developer community. We hope these changes make for a better experience for you, so please let us know what you think!

    Posted by Ian Fette, Product Manager

    Blogs

  • Distributed Reliability Testing

    Posted on April 7th, 2009 admin No comments
    We want Google Chrome to be as stable as possible. No matter what site you browse to or what you do, Chrome should never crash. A system we call “distributed reliability testing” is one of the main tools we use to help turn that goal into reality.
    One of the advantages to being associated with Google is that we have access to a lot of information about the Web, and a lot of computers to test on. About once an hour, our distributed test infrastructure takes the very latest version of Google Chrome in development and uses it to automatically load a large number of the pages that Google has seen are most popular around the world. When it’s done, it produces a report like this on the Buildbot waterfall that all our developers (and anyone else) can see:
    Results for top 500 web sites:
    success: 499; crashes: 0; crash dumps: 0; timeout: 1

    Results for top 500 web sites without sandbox:
    success: 463; crashes: 0; crash dumps: 0; timeout: 2

    Results for extended list of web sites:
    success: 99768; crashes: 3; crash dumps: 3; timeout: 463
    Here the final test got through a bit over 100,000 pages before stopping to make way for the next build to be tested. And before each Dev, Beta, or Stable channel release, we run with a much larger number of URLs.
    In addition, we “fuzz-test” the user interface, automatically performing arbitrary sequences of actions (opening a new tab, pressing the spacebar, opening various dialogs, etc. — a total of more than 30 possible actions). These are also run in our distributed testing architecture, so we can exercise thousands of combinations for each new version of Google Chrome in progress. The same report that shows the page-load results above collects these UI test results too:
    Results for automated UI test:
    success: 64643; crashes: 0; crash dumps: 0; timeout: 0
    This sort of large-scale testing is great for finding crashes that happen only rarely, or that only affect pages that developers wouldn’t have visited as part of their haphazard manual testing. By catching a problem right away even if it’s very rare, it’s easier for developers to figure out what change caused the error and fix it before it ever gets close to showing up in Google Chrome itself.

    Posted by Pamela Greene and Patrick Johnson, Software Engineers

    Blogs

  • Spell Check Dictionary Improvements

    Posted on April 7th, 2009 admin No comments
    If you’re anything like us, you’re spending more and more of your time working online. The spellchecker built into Chromium can be a big help in keeping your blog, email, documents, and forum postings spelled correctly and easy to read. Chromium integrates the popular open source library Hunspell with WebKit’s built-in spellchecking infrastructure to check words and to provide suggestions in 27 different languages.
    The Hunspell dictionary maintainers have done a great job creating high-quality dictionaries that anybody can use, but one of the problems with any dictionary is that there are inevitably omissions, especially as new words appear or proper nouns come into common use. We at Google are in a good position to use our knowledge of the internet to identify and fix some of these omissions. The Google translation team used their language models to generate a sorted list of the most popular words in each language. This was cross-checked with the Hunspell dictionaries to generate a list of the top 1000 words not present in each dictionary. This list includes many popular words, but also common misspellings. To remove these words, each list was reviewed by specialist in that language. Generally, we tried to keep proper nouns and even foreign words as long as they were in common usage.
    We hope that by using the the existing GPL/LGPL/MPL tri-license for our addition, our work can be picked up by other users of Hunspell. We also hope to make more improvements in the future, both for additional languages like Turkish, and to refine the word lists we already have. If you’re passionate about your language, you can help out by writing affix rules for the added words or reviewing more word lists.
    The recent dev-channel release of Google Chrome (2.0.160.0) has the additional words we generated for 19 of the languages. Hopefully, you’ll see fewer common words marked as misspelled. For example, the English dictionary now includes “antivirus,” “anime,” “screensaver,” and “webcam,” and commonly used names such as “BibTeX,” “Mozilla,” “Obama,” and “Wikipedia.” For our scientific users, we even have “gastroenterology,” “oligonucleotide,” and “Saccharomyces“! We’d like to give special thanks to the great help we got from the translation team who generated the words and the language search specialists who reviewed the lists.

    Posted by Brett Wilson and Siddhartha Chattopadhyay, Software Engineers

    Blogs

  • Irregexp, Google Chrome’s New Regexp Implementation

    Posted on April 7th, 2009 admin No comments
    One of the new features in the most recent dev-channel release of Google Chrome (2.0.160.0) is Irregexp, a completely new implementation of regular expressions (regexps) in the V8 JavaScript engine. Irregexp builds on V8’s existing infrastructure for memory management and native code generation and is tailored to work well for the kinds of regexps used by JavaScript programs on the web. The result is a considerable improvement in V8’s regexp performance.
    While the V8 team has been working hard to improve JavaScript performance, one part of the language that we have so far not given much attention is regexps. Our previous implementation was based on the widely used PCRE library developed by Philip Hazel at the University of Cambridge. The version we used, known as JSCRE, was adapted and improved by the WebKit project for use with JavaScript. Using JSCRE gave us a regular expression implementation that was compatible with industry standards and has served us well. However, as we’ve improved other parts of the language, regexps started to stand out as being slower than the rest. We felt it should be possible to improve performance by integrating with our existing infrastructure rather than using an external library. The SquirrelFish team is following a similar approach with their JavaScript engine.
    A fundamental decision we made early in the design of Irregexp was that we would be willing to spend extra time compiling a regular expression if that would make running it faster. During compilation Irregexp first converts a regexp into an intermediate automaton representation. This is in many ways the “natural” and most accessible representation and makes it much easier to analyze and optimize the regexp. For instance, when compiling /Sun|Mon/ the automaton representation lets us recognize that both alternatives have an ‘n’ as their third character. We can quickly scan the input until we find an ‘n’ and then start to match the regexp two characters earlier. Irregexp looks up to four characters ahead and matches up to four characters at a time.
    After optimization we generate native machine code which uses backtracking to try different alternatives. Backtracking can be time-consuming so we use optimizations to avoid as much of it as we can. There are techniques to avoid backtracking altogether but the nature of regexps in JavaScript makes it difficult to apply them in our case, though it is something we may implement in the future.
    During development we have tested Irregexp against one million of the most popular webpages to ensure that the new implementation stays compatible with our previous implementation and the web. We have also used this data to create a new benchmark which is included in version 3 of the V8 Benchmark Suite. We feel this is a good reflection of what is found on the web.
    If you want to try this out, and help us test it in the process, you can subscribe to the dev-channel and if you see problems that might be related to Irregexp consider filing a bug.
    And BTW, we’ll have sessions on V8 and other Chrome-related topics in May at Google I/O, Google’s largest developer conference.

    Posted by Erik Corry, Christian Plesner Hansen and Lasse Reichstein Holst Nielsen, Software Engineers

    Blogs

  • ClickJacking

    Posted on April 7th, 2009 admin No comments
    Although the term “ClickJacking” is new, the underlying issue has been known for years. ClickJacking attacks affect all Web browsers because the attacks rely on standard browser features to trick the user into clicking on a dangerous spot on another Web page. A few months ago, Jeremiah Grossman and Robert Hansen sparked renewed interest in ClickJacking by demonstrating a clever application of the technique against Flash Player. Unfortunately, there is no “silver bullet” solution to all ClickJacking attacks. To find the best long-term solution, we’re collaborating with other browser vendors and the standards community. If you’re interested in ClickJacking solutions, I’d recommend reading Mark Pilgrim’s summary of recent ClickJacking discussion in the HTML 5 working group and joining in the discussion.

    Posted by Adam Barth, Software Engineer

    Blogs

  • Google Chrome User Experience Research

    Posted on April 7th, 2009 admin No comments
    Why are the buttons where they are instead of where I want them to be? What’s up with bookmarks? Why does the Google Chrome UI look and operate the way it does? These are probably questions that some, many or even all you have about Google Chrome. We explained how we came to some of those decisions in a previous post:
    “To achieve the streamlined feel we were after … we had our own intuitions about what was and wasn’t useful in current browsers, we had no idea how those ideas matched to reality. So in typical Google fashion, we turned to data; we ran long studies of the browsing habits of thousands of volunteers, compiled giant charts of what features people did and didn’t use, argued over and incorporated that data into our designs and prototypes, ran experiments, watched how our test users reacted, listened to their feedback, and then repeated the cycle over and over and over again.”

    To provide some more insight into this process, I should explain what we mean by “data.” The data we turn to is both quantitative and qualitative. Usage logs provide statistics such how many users have tried a feature and how frequently a feature gets used. These logs are collected only from people who have chosen to share usage statistics with us. This quantitative data tells us the “how” and the “when” but not the “why.” For that, we use qualitative data gathered through research methods like surveys, interviews and contextual inquiry which involves observing people in their home or work environments. Often we bring people to one of our usability labs where we can observe their interactions and collect feedback on a new feature we are working on. Many times we employ an eye tracker where we can find out what exactly people are looking at on our user interface. By incorporating data from all these sources into our design process, we hope to provide a user experience that satisfies the needs of the many Google Chrome users out there.
    In the future, we are planning on releasing some of our research on this blog and the on the UX Site to show how the data we are collecting is impacting the Chrome experience.
    All of our research data comes from studying and observing people. But what kind of “people” do I mean? Probably someone just like you. So if you are interested in becoming a potential participant in a research study on Chrome or one of the many other Google products, I encourage you to sign up at google.com/usability.

    Posted by David Choi, User Experience Researcher

    Blogs

  • Google Chrome Installation and Updates

    Posted on April 7th, 2009 admin No comments

    Since our public launch in September, a few Google Chrome users have had some questions about our installation and update process. We tried to answer most of them in our help center, but since many of you may not have visited the help center, this post attempts to give some background and insight into our current installation and update process.

    When we started exploring various options for our installer, we came up with some explicit goals:

    • With new browser exploits showing up on regular basis, keep users free from the burden of checking for security updates.
    • Allow users who are not administrators to install Google Chrome.
    • Allow updates to happen automatically in the background even when Google Chrome is in use. The next time you open Google Chrome, it can simply start using the latest version.
    • Just like the minimal user interface (UI) of Google Chrome, limit or eliminate installer UI as much as possible.
    • Updates should be as small as possible. A security fix should be a small, fast download and should not need a full installer.
    • Uninstall should be clean and remove changes done by Google Chrome as much as possible.

    After looking at existing options we found that none of them would give us all the things we wanted so we decided to write our own installer.

    Installation
    We believe Google Chrome installation has been made really simple. Once you run the installer, there are no screens to jump through or confusing choices to make. Installation happens and you get a first run UI window letting you import your data from your existing default browser. Some people (especially those using Windows XP as opposed to Windows Vista) were confused by our choice to install in the user profile directory instead of Program Files. There are several reasons we chose the user profile directory:

    • Anyone can install Google Chrome, not just administrators.
    • On Windows Vista there are no ’security prompts’ during install. If you are running as a non-elevated Administrator, you can still install Google Chrome without having to enter an administrator’s password. However we still need to ask for a password to make Google Chrome the default browser due to how Windows Vista requires browser applications to be registered with it.
    • You can choose to install or uninstall Google Chrome without affecting other people who use the same computer.

    Updates
    Google Chrome automatically updates itself with the help of Google Update, which is also used by other Google products including Google Talk, Gears, and the Google Earth Plugin. Using Google Update meant we could use an existing service that already takes care of lot of issues around automatic updates:

    • Maintaining different update channels, each with its own update schedules and Chrome versions.
    • Updating software in the background without any annoying dialogs.
    • Good proxy support that can handle various proxy configuration to download the installer payload.
    • Having only one instance of Google Update manage multiple Google programs installed on the machine.

    Using Google Update has allowed us to push incremental changes out relatively quickly — we have released fourteen updates in three months between our release and our taking off the beta label.

    Un-installation
    During uninstall, Google Chrome deletes all the changes it made to the system, but a few people were surprised when they found all their profile data intact after reinstalling Google Chrome. This is intentional as many people try a sequence of uninstalling and then reinstalling to fix any installation issues, and we didn’t want them to lose all of their profile data. If you really want to delete your Google Chrome profile we have instructions on how to do so.

    Finally, if you made Google Chrome your default browser before uninstalling, we don’t know how to undo that. All browsers face this problem: there’s no way for one browser to know exactly how another browser registers itself as the default browser. To fix that, you should open your preferred browser, and use its option to set it as the the default browser.

    Posted by Rahul Kuchhal, Software Engineer

    Blogs

  • Google Chrome Release Channels

    Posted on April 7th, 2009 admin No comments
    Release early, release often. We think that’s the best way to develop software that delights people. With Google Chrome, we want to release fewer features more often instead of making you wait 12 months for the next Major Dot-Oh Release Jam-Packed With Features. We can get your feedback faster, fix things faster, and release new improvements as soon as they’re ready. We want Google Chrome to stay nimble so it can keep pace with changes in the sites and web apps you use. 
    Because we don’t have those big Dot-Oh release milestones on the calendar, we don’t have long periods of Beta testing new features. Instead we use automatic update channels to release Google Chrome to a community of early adopters. The channels are essentially a never-ending Beta test and a continuous feedback loop that lets us rapidly develop new ideas into solid product features. 
    You can subscribe to one of our update channels:
    • Stable channel. Everyone is on the Stable channel when they first install Google Chrome. The Stable channel is updated with features and fixes once they have been throughly tested in the Beta channel. If you want a rock solid browser but don’t need the latest features, the Stable channel is for you.
    • Beta channel. People who like to use and help refine the latest features subscribe to the Beta channel. Every month or so, we promote stable and complete features from the Dev channel to the Beta channel. The Beta channel is more stable than Dev, but may lack the polish one expects from a finished product.
    • Developer preview channel. The Dev channel is where ideas get tested (and sometimes fail). The Dev channel can be very unstable at times, and new features usually require some manual configuration to be enabled. Still, simply using Dev channel releases is an easy (practically zero-effort) way for anyone to help improve Google Chrome.
    To get more actively involved with Google Chrome, subscribe to the Dev or Beta channel. Just run a little program (found here) and that’s it. After that, you’ll automatically get early access updates.
    If you’re ready to try some new stuff, we’ve just released a Dev channel update that has a new version of WebKit, a new network stack, and some features like form autocomplete (read about it here). It’s less polished than what Dev channel users have been getting during Google Chrome’s Beta, so we’ve moved all of our existing Dev channel users to the Beta channel. If you were on the Dev channel, you can decide whether to switch to the new Dev channel or stay on the new Beta channel.

    Posted by Mark Larson, Technical Program Manager

    Blogs

  • Tabbed Browsing in Google Chrome

    Posted on April 7th, 2009 admin No comments
    Tabbed Browsing is a prominent feature of modern browsers. We think it’s one of the key elements that makes the browser a window manager for the web. Since we thought of the tab as the “container” element within which all other aspects of the browser lived, we designed the Chrome UI with the tab strip at the very top. But we didn’t stop at aesthetic upheaval. As we were designing Google Chrome, we designed our tab strip behavior with an eye to making heavy use efficient. Observing how we were using our existing browsers, we were able to identify some pain points and come up with solutions targeted at fixing them. In this post I’ll talk a bit about some of the things we’ve done.
    Ordering
    One of the most persistently annoying issues with tabbed browsing was the following situation:
    You have a full tab strip and a “hub” page open towards the left of the strip. Perhaps its your RSS reader, or a news site like Google News. You open interesting links in new tabs so you can keep reading through the headlines. The problem is, the new tabs open at the end of the tab strip, beyond many other unrelated tabs that also happen to be open. Sometimes, because of the “many-tab overflow” UIs in existing browsers, the tabs that you are queuing up to read in just a moment may disappear off the end of the strip. In short: finding tabs can sometimes be a challenge.
    In addition, when you’re done reading one of the articles you opened and close its tab, selection jumps back to the opener. This was one of the improvements I made to the tab strip in Firefox a couple of years ago, but with some extended use it turns out to not be the best action when there are multiple tabs opened from the same opener. Worse still, when combined with the “overflow” UI I mentioned above, the result was disorienting “bouncing” between the left and right ends of the tabstrip.
    What did we do? In Google Chrome, we open tabs opened from links in the background adjacent to their opener tab. This keeps the spatial proximity of related tasks close. So you don’t end up with the “bouncing” scenario I just described. We also maintain loose grouping relationships between such related tabs, so that when you are done reading one of several articles opened from a hub page, we shift selection to the next in the group, rather than going back to the hub. We think this makes the news reading use case a lot simpler. We don’t persist this group relationship when you switch to an unrelated tab, though, to avoid situations that might lead to unpredictable switching behavior if you move on to a different task.
    Cleaning Up
    Another common annoyance was related to closing several tabs quickly. In most tab strips, when you close a tab the other tabs expand to fit the space that has just been made available. The upshot of this is that the close boxes of the remaining tabs all move around slightly, which makes it harder to quickly close tabs by clicking in the same spot. Older versions of Firefox solved this by putting the close box in a static position at the end of the tab strip, but lab research showed this approach had usability and discoverability problems for novices not used to tabbed browsing, so the close box was moved into the tab (which now seems to be the standard location for tabbed browsers).
    For Chrome, we came up with something a little different. Realizing that maintaining a fixed width for tabs when closing them would keep close buttons aligned under the mouse pointer, we designed a system whereby the tab strip will re-layout when you close a tab to fill the gap left, but not resize the remaining tabs, until you move your mouse away from the tab strip (thus signaling you’re done closing tabs).
    Open Issues
    Based on feedback we’ve received so far, here are a few areas where our tab strip design needs further improvement:
    Many Tab Overflow

    We don’t have a complete system for handling many open tabs right now. We let tabs grow infinitely smaller. This ends up looking bad when there are a very large number of tabs open. We chose not to go with an overflow menu or scrolling tab strip like in some other browsers because we think there are other usability problems with those approaches. Specifically, when you implement an overflow solution you generally pick a minimum “readable” width for the tab and overflow tabs when there are too many at that width to fit. The problem is usually that that width seems to be too wide, so there can be unnecessary overflow in conditions where a smaller tab width would have meant all of the tabs would have fit. We also don’t really like the drop-down menu approach as it has a spatial disconnect (vertical scanning vs. horizontal tabs) that makes it clumsy to use quickly. In the end, we would like a system that doesn’t over-zealously clip tabs out of the tab strip so that people with many tabs can still access their tabs with one click.
    Disoriented Anchor Tabs

    Opening tabs next to the tab that opened them can mean for some use cases that the behavior of having a few “anchor” tabs positioned at the left edge of the strip is more difficult since tabs opened from them are opened in between. We like the idea of “tab pinning” or “locking” as a solution for this, but haven’t invested a lot of time in designing how this might work just yet. There may be some overlap with “startup tabs” in Options.
    Restoring Mistakenly Closed Windows

    We also don’t prompt when you close a window with several tabs. The reason we don’t do this is that one of our core design philosophies has been to avoid modal question prompts that interrupt the user when they’re trying to get things done (in this case, use a standard window control to close the window). We’re aware that the prompt has saved people (including ourselves!) using other browsers from losing tabs, but we have been trying to come up with a more creative system for helping this scenario that doesn’t interfere with the window’s close button. In recent trunk builds, you’ll find that you can re-open a recently closed window from the New Tab Page, and that the “Recently Closed” section of the New Tab Page now spans multiple sessions. This is a good way to “undo” an accidentally closed window, in the same way you can “undo” an accidentally closed tab. To try this out you can get on the Google Chrome Dev Channel.
    In all of these areas we’ve resisted adding options to control behavior. Keeping our set of options minimal is a good forcing function for us as user interface designers to come up with the right approach, since we never rely on the crutch of making the user decide what we were unable to. Instead, our approach has been to experiment with different behaviors and end up taking the approach that works the best. We are heavy users, and we’ve designed this user interface for heavy web users, so we hope it scales as well for you as it does for us!

    Posted by Ben Goodger, Software Engineer

    Blogs
  • « Older Entries

Categories

Powered by WordPress
Designed by My Mobiles