WorryFree Computers   »   [go: up one dir, main page]

Adobe Flash Player is the most widely used web browser plug-in. It enables a wide range of applications and content on the Internet, from games, to video, to enterprise apps.

The traditional browser plug-in model has enabled tremendous innovation on the web, but it also presents challenges for both plug-ins and browsers. The browser plug-in interface is loosely specified, limited in capability and varies across browsers and operating systems. This can lead to incompatibilities, reduction in performance and some security headaches.

That’s why we are working with Adobe, Mozilla and the broader community to help define the next generation browser plug-in API. This new API aims to address the shortcomings of the current browser plug-in model. There is much to do and we’re eager to get started.

As a first step, we’ve begun collaborating with Adobe to improve the Flash Player experience in Google Chrome. Today, we’re making available an initial integration of Flash Player with Chrome in the developer channel. We plan to bring this functionality to all Chrome users as quickly as we can.

We believe this initiative will help our users in the following ways:

  • When users download Chrome, they will also receive the latest version of Adobe Flash Player. There will be no need to install Flash Player separately.

  • Users will automatically receive updates related to Flash Player using Google Chrome’s auto-update mechanism. This eliminates the need to manually download separate updates and reduces the security risk of using outdated versions.

  • With Adobe's help, we plan to further protect users by extending Chrome's “sandbox” to web pages with Flash content.

Improving the traditional browser plug-in model will make it possible for plug-ins to be just as fast, stable, and secure as the browser’s HTML and JavaScript engines. Over time this will enable HTML, Flash, and other plug-ins to be used together more seamlessly in rendering and scripting.

These improvements will encourage innovation in both the HTML and plug-in landscapes, improving the web experience for users and developers alike. To read more about this effort, you can read this post on the Flash Player blog.

Developers can download the Chrome developer channel version with Flash built in here. To enable the built-in version of Flash, run Chrome with the --enable-internal-flash command line flag.

Posted by Linus Upson, VP, Engineering

What's New in Google Chrome?

The Google Chrome Dev channel has been updated to 5.0.356.2 for all platforms since our last developer post. It includes a few new goodies for developers:
Please keep in mind that these features are still under development and are not 100% stable yet. In addition to the above, there are a few new experimental features baking in /trunk. You can try them out with the --enable-experimental-extension-apis flag:
Samples and Tutorials

We’ve added a few new sample extensions tutorials to get you started:
  • Sample and tutorial to demonstrate using Google Analytics in your extensions
  • Extension to display, create, and update your Google Documents
  • Tutorial to demonstrate using OAuth in your extensions
Remember to follow us on Twitter: @ChromiumDev!

Posted by Eric Bidelman, Developer Advocate
Labels: ,

We're happy to announce a new open source project called Almost Native Graphics Layer Engine, or ANGLE for short. The goal of ANGLE is to layer WebGL's subset of the OpenGL ES 2.0 API over DirectX 9.0c API calls. We're open-sourcing ANGLE under the BSD license as an early work-in-progress, but when complete, it will enable browsers like Google Chrome to run WebGL content on Windows computers without having to rely on OpenGL drivers.

Current browser implementations of WebGL need to be able to issue graphics commands to desktop OpenGL to render content. This requirement isn't a problem on computers running OS X or Linux, where OpenGL is the primary 3D API and therefore enjoys solid support. On Windows, however, most graphics-intensive apps use Microsoft Direct3D APIs instead of OpenGL, so OpenGL drivers are not always available. Unfortunately, this situation means that even if they have powerful graphics hardware, many Windows machines can't render WebGL content because they don't have the necessary OpenGL drivers installed. ANGLE will allow Windows users to run WebGL content without having to find and install new drivers for their system.

Because ANGLE aims to implement most of the OpenGL ES 2.0 API, the project may also be useful for developers who are working on applications for mobile and embedded devices. ANGLE should make it simpler to prototype these applications on Windows, and also gives developers new options for deploying production versions of their code to the desktop.

We hope that other WebGL implementors and others in the graphics community will join us to make ANGLE successful! For more info on ANGLE and to access the code repository, visit the new project on Google Code or join our discussion group.

Posted by Henry Bridge, Product Manager
Labels:

One of the most important principles of the web is portability: a web page renders and behaves the same way, regardless of the browser’s operating system or the type of hardware it’s running on. When we first released Native Client a year ago, we supported all popular operating systems (Windows, Mac OS X, and Linux) but only on machines with x86 processors. Today, we’re happy to say that you can build and run Native Client binaries for all of the most popular processor architectures: x86-32, x86-64, and ARM. Even better, our initial benchmarks indicate that Native Client executables perform at 97% of the speed of an unmodified executable on both ARM and x86-64 processors. These results indicate that a browser running on virtually any modern computer or cell phone could run a fast, performance-sensitive Native Client application.

However, we recognize that just running on today’s most popular architectures isn’t enough; if a new processor architecture emerges, it should be able to run all Native Client modules already released without requiring developers to recompile their code. That’s why we’re also developing technology that will enable developers to distribute a portable representation of Native Client programs using LLVM bitcode. Using this technology, a browser running on any type of processor could translate the portable representation into a native binary without access to the source code of the program.

If you’d like to review our instruction-set support or give us feedback about the technology, please visit our project on Google Code and join our Google Group.

Posted by Brad Chen, Native Client Team
Labels:

Last June, we launched the Sputnik JavaScript conformance test suite, a comprehensive set of more than 5000 tests. Today we're releasing a test runner for Sputnik, that allows you to easily run the complete test suite from within your browser.

Sputnik touches all aspects of the JavaScript language defined in the 3rd edition of the ECMA-262 spec. In many ways it can be seen as a continuation of and a complement to existing browser conformance testing tools, such as the Acid3 test. While we are always focused on improving speed, Sputnik is not about testing how fast your browser executes JavaScript, but rather whether it does so correctly.

Since we released the Sputnik tests as an open source project, the most requested feature has been the ability to run the tests in a browser, and we are excited to launch that functionality today. The new test runner lets you run the tests from a single URL and quickly see the results in your browser. This makes it easier both for users to see how well their browser conforms to the JavaScript spec, as well as for browser makers to find bugs and incompatibilities.

You can also use Sputnik to compare browser conformance. For example, below is an experimental plot that compares five popular browsers and which we hope to update as new stable versions of the browsers are released. We created this chart by running Sputnik in each of the five browsers and then plotting each browser such that the fewer tests a browser fails the closer it is to the center and the more failing tests two browsers have in common the closer they are placed to each other. In this example, when running Sputnik on a Windows machine, we saw the following results: Opera 10.50: 78 failures, Safari 4: 159 failures, Chrome 4: 218 failures, Firefox 3.6: 259 failures and Internet Explorer 8: 463 failures.


When we first released the Sputnik test suite we noted that to be compatible with the web you sometimes had to be incompatible with the JavaScript spec. Since then a new version of the spec, ECMAScript 5, has been released. Besides introducing a number of new language features, ECMAScript 5 changes how many existing features are defined to bring them in line with how they are used on the web. We are updating the Sputnik tests to reflect those changes so that 0 failures would mean not only compatibility with the spec but also compatibility with the web.

We are excited to see the efforts on conformance testing by other browser makers. For example, where Sputnik tests the language features in ECMAScript 5 which were also present in ECMAScript 3, Microsoft's es5conform project tests the new language features that were added in ECMAScript 5.

Incompatibilities between browsers remain one of the biggest challenges for web developers. We hope that giving users and browser vendors an easy way to test their browser will help promote browser robustness and compatibility across the industry.

Posted by Christian Plesner Hansen, Software Engineer
Labels:

This is the first issue of Google Chrome Update for Web Developers. In these regular updates, we'll inform you about new features enabled in Google Chrome and announce updates of Google Chrome related developer events. We will also be sharing samples and highlighting cool extensions and HTML5 apps written by the developer community.

What's New in Google Chrome?

The Google Chrome Beta channel for Mac and Linux has been updated to 5.0.307.7 and the extensions gallery now offers more than 3000 extensions for users to choose from.

For Google Chrome extensions, we've just released a couple of new experimental APIs, including a history API. Since these are experimental APIs, the extensions gallery won't allow you to upload extensions that use them. However, we'd like to encourage you to read the documentation, give it a try, and send us your feedback.

Last but not least, the new Google Chrome stable release has many new HTML and JavaScript APIs including WebSockets, Notifications, and Web SQL Database. We are interested to hear how you've been using these APIs. Please share with us the cool applications you are building.

Samples and Tutorials

We've been working on creating samples to help you implement certain functionality in your extensions. You may be interested in viewing the source code for extensions that:
  • Merge all of the open tabs into a single window.
  • Use OAuth to connect to web services.
  • Make cross-domain XMLHttpRequests from a content script.
  • Display page actions based on the current URL or the current page's content.
Upcoming Events

We are pleased to announce that we will host a series of Google Chrome developer events over the next month in the following cities (dates in local time):

  • Sydney, AU - Mar 5th
  • Tokyo, Japan - Mar 11th
  • Austin, TX - Mar 14th - Mar 15th
  • London, UK - Mar 16th
    • Meetup, HTML5 and Google Chrome extensions (sign up here)
  • Madrid, ES - Mar 18th
    • Google Chrome hackathon @Universidad Complutense de Madrid (sign up here)
We also plan to hold events in Germany and will be announcing more information about those soon, so stay tuned!

Let Us Know What You Think

This is just the first post of the many Google Chrome developer updates, let us know what you would like to see in future updates and follow us on Twitter at @ChromiumDev.

Posted by Vivian Li, Developer Advocate

You might have already noticed this, but we now have some APIs that we’re referring to as experimental. The idea is that we can add new APIs to the platform that may not be ready for prime time. This allows you to play with these APIs and give us feedback before they’re final, which in turn helps us get them out to everybody more quickly.

Our first two experimental APIs — chrome.experimental.history and chrome.experimental.processes — are available on the dev channel. The history API lets you query and modify the user’s browsing history. When it’s finalized, we’ll also allow you to replace the history page with your own, just like you can replace the new tab page today. The processes API allows access to information about Google Chrome’s process model, including process IDs and the CPU usage of individual tabs. The processes API is incomplete, but you can see upcoming features in its design doc.

These APIs have a few major limitations. First, to use an experimental API you must add a command-line flag when you start Google Chrome (--enable-experimental-extension-apis). Second, you can’t upload extensions that use experimental APIs to the Google Chrome Extensions Gallery. Finally, these APIs will change in incompatible ways, so the code that you write today isn’t guaranteed to work tomorrow.

What this really means is that these APIs are only useful for you to play with. You won’t be able to share extensions that use these APIs with a lot of people. However, we’d really like you to try them out and give us feedback. Doing so will help us release the APIs more quickly and make sure they do everything you need. Playing with the experimental APIs is also a way for you to get experience with them before most other developers.

We expect to add more experimental APIs over time, so keep an eye out for future announcements.

Posted by Erik Kay, Software Engineer
Labels: