Many popular applications today help users consume, share, manage, and edit media content, as evidenced by the rise of web apps like Google Play Music and YouTube. For Chrome packaged app developers, the new Media Galleries API introduces a simple way for apps to access media stored on a user’s device (with the user’s permission, of course).

To use the API, you first have to determine what kind of permission your app needs to access user’s media:

• read-only: allows media content to be read, but not modified 
• read-write: allows media content to be read and modified 
• add-files: allows media to be added to the galleries but prevents modifying existing media files. 

Currently, only read-only access is supported. Support for read-write and add-files will be introduced in a future release.

To retrieve media content, use getMediaFilesystems(). If this is the first time your app is accessing the user’s media libraries, the system will prompt the user to grant access:



You can also make your app explicitly ask the user to designate specific galleries. This is useful if, for example, your app is only interested in pictures. Once access is granted, your app can then retrieve a list of LocalFileSystem structures. At that point, you can use the W3C FileSystem API to access the media gallery content.



NOTE: The file system APIs will only return files that the Chrome platform natively supports, and only the asynchronous version of the FileSystem API is currently supported.

We’re eager to see what great applications you will build with the Media Galleries API and the Chrome Packaged Apps platform. To get started, clone our samples repository and look at the Media Galleries sample application. Have questions or comments? Subscribe to chromium-apps and follow us on our Google+ page!

Posted by Joe Marini, Developer Advocate

Sandboxing is a layer of security that Chrome places between attackers and their computer, aiming to isolate an attacker who has successfully exploited a vulnerability. When contained in a sandbox jail, an attacker will typically look for porous or fragile bits in the walls to throw rocks at. That is, he’ll try to gain additional privileges by taking advantage of other vulnerabilities. Our job is to make the virtual walls of the sandbox as strong and impenetrable as possible.

One juicy target for attackers is the operating system’s kernel: a large and complex code base. The latest stable version of Chrome introduces a new layer of sandboxing of Chrome renderers for the 64-bit versions of Chrome OS and Linux, based on a new kernel feature called seccomp-bpf. With seccomp-bpf we’ll install a small filter in the kernel that will quickly reject many of the rocks thrown by an attacker. A simple example: if we know that Chrome renderers don’t need a system call such as vmsplice, or a facility such as “inotify”, we can just deny them completely. We use a broker process model to keep the list of allowed system calls small.

Installing this filter in the kernel improves the security of our users. But it is just the beginning: using this new facility, we’ll continue to make the sandbox safer.

This new sandbox layer is automatically baked into the latest version of Chrome OS. On Linux, you can check by going to chrome://sandbox and look for “Seccomp-BPF sandbox Yes”. If this is not available, ask your Linux distribution to include and enable seccomp-bpf in its kernel, as Ubuntu has done since version 12.04.


As always, you can report bugs and issues here, by clicking on “New issue”.

Posted by Julien Tinnes, Software Engineer

Whether your web app involves scrolling down a long list of news headlines or a game with flying birds and crumbling structures, you want your web app to look as smooth as native apps. It used to be tricky to chase down the cause of animation jitter and lag in user actions with Chrome Developer Tools. This is why we’ve added the Frame Mode to our Timeline panel to help you pinpoint offending long frames and understand what’s causing them to run slowly.

So, what’s a frame? A frame includes all the tasks that the browser needs to perform in order to update the screen upon a user action or a tick of the animation timer. A complex, but not uncommon, sequence might be:

1. run JavaScript animations and other event handlers 
2. update CSS animations 
3. recalculate styles and lay out the elements in the DOM 
4. re-paint the updated layers of the page 
5. compose them and present to the user 

Delivering a butter-smooth animation means completing all of the above in less than 16.6ms (common 60Hz refresh rate). If you are not done by then, you’ll miss the frame and the animation will appear janky.

To see how using Timeline can help you, run your favorite browser-based game, then open Developer Tools and record the Timeline while the game is running some animation. The Timeline Frame mode will now show you colored bars, each representing a frame. The colors correspond to different types of timeline events:

• network activity and HTML parsing (blue) 
• running JavaScript (yellow) 
• performing style recalculation and layout (violet) 
• painting and compositing (green) 

You can zoom in by selecting several frames or by clicking on a particular frame of interest. Looking at a specific frame in detailed view will show you the frame duration, and you can find more detailed statistics by hovering on it.



Even if your web app doesn’t have animation in it, the notion of a frame is still useful because the browser performs a repeated sequence of actions while processing input events such as keypress, mouse actions, scrolling etc. Leaving enough time to process such events inside a frame makes your app more responsive and interactive, resulting in a better overall experience for users.

In large web applications with huge DOM trees, layout typically takes time and resources. Doing it in a loop makes things much worse. So we’ve added a warning mark on layouts that were forced, by requesting positional properties (e.g. offsetWidth and offsetHeight) of DOM elements from JavaScript. If you hover over the layout event, you can see two stacks -- one that invalidated the DOM and another that caused layout synchronously. You can also see the area that had to be re-laid highlighted on the screen.



Finally, don’t forget that the best practice for dealing with animations is to use the requestAnimationFrame API, which guarantees that Chromium will call back your animation code in sync with the display refresh.

You can learn more about optimizing rendering performance of a page in Tom Wiltzius’ article on html5rocks.com. Follow Google Chrome Developers on Google+ or @ChromiumDev on Twitter for more news on Chrome Developer Tools.

Posted by Andrey Kosyakov, Software Engineer

Even though Chrome extensions and legacy packaged apps are similar at a technical level, users have very different expectations for how extensions and apps should look and behave. Users expect extensions to interact with the whole browser, whereas they expect apps to act solely in their containing tab or window.

Until now, all Chrome legacy packaged apps could request the same permissions and use the same APIs as extensions to interact with Chrome. In order to make the capabilities of legacy packaged apps more closely align with user expectations, we’ve decided to limit the extensions permissions that legacy packaged apps can request.

Beginning this week, you won’t be able to publish legacy packaged apps in the Chrome Web Store that request any of the following permissions:
(a) any host permissions, including "< all urls >" 
(b) the top-level "content_scripts" key 
(c) the "debugger", "devtools", "pageCapture", "plugin", "proxy", "tabs'", "history", "webNavigation" permissions 
(d) the top-level "npapi" key 

Existing legacy packaged apps in the Chrome Web Store will not be affected, and those existing apps can continue to be updated without being subject to these new restrictions. 

If you have questions, please get in touch with us on the Chromium extensions or Chromium apps groups.

Posted by Peter Ludwig, Product Manager

Earlier today we launched JAM with Chrome. JAM with Chrome is an interactive web application that enables friends in different locations to play music together in the Chrome browser on their computers.



JAM with Chrome was built with the latest browser technologies:

• Web Audio for high fidelity playback without resorting to lots of pre-recorded audio samples. 
• WebSockets is used to deliver immediate real-time playback across all the members of the band ensuring they stay in sync and playing from the same tab sheet. 
• Finally, CSS3, SVG and Canvas provide rich visuals and an immersive experience.

To learn more about how we built this experience, check out “How we made the Audio rock”. This is the first of three HTML5 Rocks articles that describes how the team used Web Audio to deliver an absorbing auditory experience. Stay tuned for more developer stories by following +Google Chrome Developers.

Enjoy playing music with friends at www.jamwithchrome.com and be sure to open Chrome’s developer tools to see what’s going on backstage!

Posted by Paul Kinlan, Developer Advocate

Today’s Chrome Beta channel release includes a slew of awesome new developer features.

Datalist support in date and time

datalist allows you to specify a list of suggested dates and times for input elements. Of course, users still have the freedom to enter arbitrary dates and times. One use case is helping users choose when their food should be ready for pickup:









MathML

Now you can write mathematical content in MathML and expect it to be consistently beautiful across the web. Special kudos to WebKit volunteer Dave Barton for implementing this on his own accord.




Other new features in this release

• CSS custom filters have landed behind a flag. They enable sweet cinematic effects like page flipping with just CSS and HTML. You can turn them on with chrome://flags. 
• Chromium now parses the autocomplete attribute according to spec. Use it to specify which type of saved user data the browser should use to prefill input elements. Examples are name and street-address. 
• A few brand new features landed with a prefix: -webkit-hyphens gives you more control over hyphenation at line breaks, and -webkit-clip-path enables you to clip DOM content to an SVG shape. 

Un-prefixed APIs 

APIs un-prefixed in today’s Beta release include:

• IndexedDB, a client-side storage API offering fast access to large amounts of structured data 
• Intl, which adds support for JavaScript internationalization of date format, number format, collation and non-standard segmentation, and more time zones 
• postMessage, a feature enabling cross-origin communication (including support for fast transferable objects) 
• requestAnimationFrame for silky smooth JavaScript animations 
• performance.now() for reliable, high-resolution timing 

Today’s Beta release supports these APIs in both their prefixed and un-prefixed forms. If you’re currently using the prefixed versions, you should switch to the un-prefixed versions after today’s Beta release reaches the Stable channel. At that point the prefixed versions will be deprecated, and future releases may not support them.

Experiments removed in this release 

As the web platform evolves, support for some experiments has been removed. The Blob constructor should now be used instead of the WebKitBlobBuilder API, and the Blob.webkitSlice() method is deprecated in favor of Blob.slice(). We also gathered a lot of valuable data and feedback from our experimental support for Web Intents and decided to disable the feature in today's Beta release.

Stay in the loop 

Visit chromestatus.com for a complete overview of Chrome’s developer features, and circle +Google Chrome Developers for more frequent updates.

We hope you enjoy this Beta release as much as we’ve enjoyed working on it!

Posted by Peter Beverloo, Software Engineer and Web Platform Enthusiast

Chrome packaged apps aim to deliver an app experience with the appearance and capabilities of native apps, but built using the growing capabilities of HTML5. These apps can access APIs for better filesystem handling, direct access to hardware devices, raw network communication and many others. One of the new APIs that just landed in an experimental state is TCP Listen, which allows an app to accept incoming TCP connections.

Since the developer preview launch earlier this year, Chrome packaged apps have been able to connect to remote servers using TCP or UDP, and bind to a UDP port. For example, this Media Center application searches for and connects to media servers in the local network. Now, through the new TCP Listen API, a Chrome packaged app can also act as a TCP server itself and accept incoming connections on specified ports.

You can use this API, for example, to create a HTTP server on a development environment application, to automate a browser window for page load testing (see image below) or even to augment the Media Center application with a DLNA®/UPnP media server and show your PicasaWeb pictures on your DLNA® enabled television.



To get started, clone this GitHub repository and look at the webserver and the TCP server samples. You may also want to watch the Chrome Apps Office Hours where we specifically talk about the TCP Listen API.

We are curious to see what clever ideas you will come up with. Have questions or comments? Subscribe to chromium-apps and let us know!

Posted by Renato Mangini, Developer Advocate