When building Chrome for iOS from source, Safari Web Inspector can be used to debug a web page rendered in Chrome. However, this takes a non-trivial amount of effort which includes setting up a Chromium checkout, installing a current version of Xcode, and waiting for the build to complete. Additionally, a Mac with enough disk space to hold the code and tools is required. This barrier to debugging has led to bugs being filed for specific website failures on Chrome for iOS.
These bugs can be difficult to diagnose as they are generally based on a single failure case. Chrome developers most likely don’t know the website application well enough to fully understand what is causing the bug. Often, the reporter has even spent time to build a dedicated test page to more precisely understand the issue. The lack of debugging tools require developers to come up with alternative methods in order to debug their websites. Of course, nothing is wrong with filing bugs, and we certainly don’t want to discourage it, but we do want to improve the web developer experience.
In-app JavaScript Console
Enable JavaScript log collection by navigating to chrome://inspect in Chrome for iOS and leaving that tab open to collect logs. In another tab, reproduce the case for which you are interested. Then switch back to the chrome://inspect tab to view the collected logs. (Log collection will stop if the chrome://inspect page closes or navigates and logs will be lost as they are not persisted.)
Today we have released version 6 of the V8 benchmark suite. The main changes are in the RegExp and Splay components of the benchmark suite. For reference, we describe each of the existing benchmarks in the suite below, along with any changes made in version 6.
RegExp: Regular expression benchmark generated by extracting regular expression operations from 50 of the most popular web pages. The regular expressions are exercised a number of times to reflect their popularity on those top 50 web pages. Changed in version 6: each regular expression is now exercised on a number of different input strings instead of just one.
Splay: Data manipulation benchmark that modifies a large splay tree to exercise the automatic memory management subsystem. The benchmark builds a large splay tree in a setup phase and then measures how fast nodes can be added and removed. Changed in version 6: no longer converts the same numeric key to string repeatedly and updates the splay tree in a way that increases the pressure on the memory management subsystem.
Richards: Operating system kernel simulation benchmark originally written in BCPL by Martin Richards. The Richards benchmark effectively measures how fast the JavaScript engine is at accessing object properties, calling functions, and dealing with polymorphism. It is a standard benchmark that has been successfully used to measure the performance of many modern programming language implementations.
DeltaBlue: One-way constraint solver, originally written in Smalltalk by John Maloney and Mario Wolczko. The DeltaBlue benchmark is written in an object-oriented style with a multi-level class hierarchy. As such it measures how fast the JavaScript engine is at running well-structured applications with many objects and small functions. Changed in version 6: fixed a couple of typos that do not have any impact on the behavior of the benchmark.
Crypto: Encryption and decryption benchmark based on code by Tom Wu. The benchmark encrypts an input string, decrypts the result and verifies that encryption followed by decryption yields the original input. The encryption/decryption algorithm is RSA and the benchmark measures the performance of arithmetic operations on integers and array access.
RayTrace: Ray tracer benchmark based on code by Adam Burmister. The benchmark measures floating-point computations where the object structure is constructed using the Prototype JavaScript library. Changed in version 6: removed dead code that has no impact on the behavior of the benchmark.
EarleyBoyer: Classic Scheme benchmarks, translated to JavaScript by Florian Loitsch's Scheme2Js compiler. The benchmarks exercise important areas of the JavaScript engine such as object allocation, data structure manipulation, and garbage collection. The translated nature of the benchmarks make them appear foreign, but the runtime characteristics of the benchmarks are highly representative of many real world web applications.
Curious to know how your browser performs? Give it a spin on the new version of the V8 benchmark suite.
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
