Chromium Blog: javascript

Chrome 76 Beta: dark mode, payments, new PWA features and more

Thursday, June 13, 2019

ChromeStatus.com Dark mode

prefers-color-scheme@media (prefers-color-scheme: dark) { body { color: white; background-color: black; } }Hello Darkness, My Old Friend Payments APIhasEnrolledInstrument()canMakePayment()languageCodedetailsPromisePaymentRequest.show()PaymentRequestEventchangePaymentMethod()PaymentRequestpaymentmethodchangePaymentRequest—ignore-certificate-errorsWeb Payments Updates Improvements for Progressive Web Apps Install Progressive Web Apps on the desktop with easeinstall button to the omnibox

installability criteria Control the Add to Home Screen mini-infobar

Progressive Web App installability criteriabeforeinstallpromptpreventDefault()promote installation of your PWA Updating WebAPKs more frequentlyWebAPKChrome will check the manifest more frequently Other features in this release Animation.updatePlaybackRateAdds Animation.updatePlaybackRate() Async clipboard: read and write imagesprogrammatic copying and pasting of imagesnavigator.clipboard.read()navigator.clipboard.write() Escape key is not a user activationno longer treated as a user activation Fetch Metadatanew HTTP request header<img>XSS leaks<img> form.requestSubmit()Adds the form.requestSubmit() functionsubmit ImageCapture support for focusDistance constraintprovides an interface Implement Animation.pendingthe pending attribute IndexedDB transaction explicit commit API calla commit() function to IDBTransactioncommit() JavaScriptDateTimeFormat dateStyle and timeStyle dateStyletimeStyleIntl.DateTimeFormatformatToParts()resolveOptions()Locale sensitive BigInt.prototype.toLocaleString and allow Intl.NumberFormat format/formatToParts to take BigInt.Changes BigInt.prototype.toLocaleString()Intl.NumberFormat.prototype.format()formatToParts()BigInt Media capabilities in workersEnables the Media Capabilities API in all types of workersMediaStream Promise.allSettledAdds Promise.allSettled() Simpler reading methods for Blob interfacethree new methods to the Blob interfacetext()arrayBuffer()stream() WebRTCRTCSctpTransportExposes information about the SCTP transportmax-message-sizemaxRTCRtpSender.setStreamschanging the association betweenRTCRtpSenderRTCRtpSender.replaceTrack()RTCRtpTransceiver.setCodecPreferences()setCodecPreferences() white-space: break-spaceswhite-space:break-spacesTrimming and Positioning rules Removals Remove feature policy: lazyloadlazyload feature policy<iframe><img>loading-frame-default-eagerloading<iframe> allow Remove outputs from MediaStreamAudioDestinationNodeMediaStreamAudioDestinationNodehas been removed Remove insecure usage of DeviceMotionEventnow restricts the API Remove insecure usage of DeviceOrientationEvent Chromium has been showing deprecation warnings since 2015 whenever the API is used in a non-secure browsing context. Chrome now restricts the API to secure browsing contexts. This change brings Chromium’s implementation in line with the privacy and security recommendations in the specification, and is aligned with the effort to deprecate powerful features on insecure origins.

Debugging Websites in Chrome for iOS

Monday, March 25, 2019

Debugging web pages displayed in Chrome for iOS has always required building the project from source because the release version of WKWebView does not support Safari Remote Debugging. To help bridge the gap of missing developer support, we added the chrome://inspect page in M73 to locally view JavaScript logs. While building Chrome for iOS from source is still the best way to fully debug web pages, we hope that this tool will make it easier to troubleshoot some problems. Background 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.)

Posted by Mike Dougherty, Chrome Engineer on iOS

The Future of JavaScript – take a peek today!

Friday, February 10, 2012

Harmonydev channel

Lexical scoping. Now "let" is the new "var" – traditional "var" declarations are complemented with "let" and "const". Both are properly block-scoped bindings, eliminating a common source of errors and weird behaviour. Function declarations are now officially allowed in local scope as well, and also obey lexical scoping. (Note: Lexical scoping is only available in ES strict mode.)

Collections. Efficient maps and sets will make your life easier. Any value can be used as a key or element, including objects. No surprises, no more need to abuse objects as dictionaries. (Caveat: Iteration over collections is not yet specified.)

Weak maps. A special kind of map for which the garbage collector determines when a key is no longer reachable, so that the key-value pair can be removed from the map automatically. This goes a long way towards avoiding memory leaks in long-lived tables and relieves the developer from worrying about stale entries.

Proxies. A proxy simulates a JavaScript object or function, and can customize just about any aspect of their behaviour that you can imagine. This is a real power feature, that takes reflection to a new level and can be used to implement various advanced abstractions and interfaces.

a lot moreExperimental JavaScript featuresfeedbackPosted by Andreas Rossberg and Michael Starzinger, Software Engineers

V8 Benchmark Suite Updated

Thursday, October 7, 2010

The V8 benchmark suite contains a number of pure JavaScript benchmarks that capture the areas in which a JavaScript engine has to perform well to support the well-structured, maintainable, and high-performance web applications of tomorrow. These benchmarks have been useful for us when optimizing the V8 JavaScript engine and we have found that making them run faster leads to better performance for many of the web applications we enjoy using every day.
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.
Posted by Kasper Lund, Software Engineer

Does Your Browser Behave?

Thursday, March 11, 2010

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

Mar	APR	May
	14
2020	2021	2022

Chromium Blog

Chrome 76 Beta: dark mode, payments, new PWA features and more

Debugging Websites in Chrome for iOS

The Future of JavaScript – take a peek today!

V8 Benchmark Suite Updated

Does Your Browser Behave?

Labels

Archive

Feed