Hello.

A simple service to summarize search and news snippets.

This post discusses the challenges web developers face due to the constantly evolving web platform. It highlights the difficulty in keeping up with changes, browser inconsistencies, and the lack of clear documentation. It then outlines the efforts made to address these issues, focusing on improving communication about the web platform, enhancing compatibility and interoperability across browsers (Compat 2021, Interop 2022), and investing in better documentation like MDN's Browser Compat Data. These initiatives aim to create a more stable and predictable web development experience, fostering innovation.

The Chrome and Web Developer Relations team is significantly expanding in 2022. Open roles span program management, Chrome extensions, CSS, rendering, DevTools, web performance, the Privacy Sandbox, and web ecosystem. The team is seeking program managers, developer relations engineers, technical writers, and infrastructure specialists to contribute to various initiatives, including Chrome Dev Summit, Google I/O, web.dev, and improving the overall web platform.

I sincerely apologize to the Safari team for misrepresenting their compatibility score in our Chrome Dev Summit presentation. Due to a combination of personal circumstances, a reliance on outdated Safari Tech Preview data from wpt.fyi, and the rush leading up to the event, we displayed an incorrect improvement score (64 => 85 instead of 64 => 92). This was my mistake, and I take full responsibility. While we attempted to rectify the situation, it was too late to change the presentation. Our intent was never malicious, but rather to highlight the collaborative effort to improve web compatibility. I've learned valuable lessons from this experience: triple-check data, consult with relevant engineers, focus on stable release data, and communicate with browser teams transparently. Going forward, we'll prioritize broad browser support and emphasize the user experience in stable releases.

The pace of change in web development, particularly with APIs and browser updates, is overwhelming. The constant deprecation and breaking changes cause friction and highlight a lack of empathy for developers struggling to keep up. While frequent updates are important, the current model, exemplified by Chrome, feels too aggressive. This blog post will explore this tension, examining whether we've pushed developers too far, and discuss strategies for a more sustainable pace of change. It will also touch on platform-specific resources like web.dev and the challenge of balancing innovation with support for the broader developer community.

With Chrome nearing version 100, there's a concern about whether user agent checks relying on "Chrome 10" will break. Analysis of HTTP Archive data suggests this is unlikely, with most instances of "Chrome 10" in JavaScript code being comments or workarounds rather than version checks. While client-side checks seem safe, server-side checks remain a concern, highlighting the need for User Agent Client Hints. If you know of tools that might be affected by the Chrome 100 user agent change, please get in touch.

We've been using surveys like the MDN Developer Needs Survey and our own quarterly surveys to understand web developer challenges and prioritize our efforts. These surveys highlighted issues like web compatibility, testing, and documentation, leading to improvements like our Web Compat initiative and increased focus on MDN documentation. While valuable, these surveys don't offer granular feedback on specific projects or proposals. Direct feedback is essential, but our current approach is informal and inconsistent. To address this, we've partnered with C SPACE to create the Web Developer Insights Community – a dedicated group of ~1000 web developers who'll provide direct feedback to our questions. This community allows open communication among developers while limiting Chrome team influence. We're excited about this new channel for gathering actionable developer insights and encourage you to join if you're interested.

I'm starting to think about Chrome Dev Summit 2022. Top of mind is everyone's safety with the ongoing pandemic and how to make the event as inclusive as possible. I really value the connections and hallway track of in-person events, but also the reach of online. I loved the CDS 2020 workshops and office hours, and believe we should expand on those. Content-wise, I want to focus on what makes the web amazing, showcasing great experiences, and exploring key technologies like Core Web Vitals, Privacy Sandbox, PWAs, and Project Fugu. Also, more content alongside talks, please! And maybe shorter, more impactful online presentations?

I'm excited to announce that I'm starting "Office Hours" to connect directly with web developers. Following a successful run at Chrome Dev Summit, I'm opening my calendar for anyone to schedule a meeting with me. I'm happy to discuss anything from JavaScript, CSS, and performance to career advice. I'm especially eager to connect with developers in underrepresented regions. Book a meeting and let's chat!

The MDN Browser Compatibility Report 2020 surveyed web developers to identify pain points in cross-browser compatibility. Layout and styling issues, especially with Flexbox and Grid, topped the list, along with challenges related to viewport units, scrolling on mobile, and achieving consistent form styling. Internet Explorer and Safari were frequently cited as problematic browsers. While JavaScript was initially flagged as a concern, interviews revealed that transpilers like Babel largely mitigate core language issues, shifting the focus to browser APIs and their inconsistencies. The report highlighted ongoing efforts to improve compatibility, including fixes for Flexbox and Grid in Chromium and WebKit, the transition to Chromium-based Edge, and a commitment to enhancing MDN's browser compatibility data.

I created a shortcut for iOS that lets you view the source code of web pages in Safari and Chrome. It's a workaround for the lack of a built-in view-source feature on these mobile browsers. The shortcut shares the URL to a third-party website I built which then displays the source code. Because it uses a third-party site, it won't reflect the current state of the page if you are logged in or have specific cookies set. Hopefully, Safari and Chrome will eventually bring back a native view-source option.

For years, I thought bookmarklets weren't supported on Chrome for Android. Turns out, they are! You just need to access your bookmarks through the address bar, not the Bookmarks menu. This method retains the page context, allowing your bookmarklets to execute JavaScript properly. This opens up new possibilities for customizing web pages on Android.

Just saw that Scroll To Text Fragment is launching in Chrome 81! This feature lets you link to specific text within a page, which is awesome. I created a bookmarklet that grabs your selected text and generates a link using the new :~:text= fragment identifier. Drag the "Find in page" link to your bookmarks bar to try it out. The bookmarklet currently selects whole words, but I'm planning on adding some logic to handle partial word selections better. You can also easily modify the bookmarklet to copy the generated link to the clipboard instead of opening a new window.

Celebrating my 10th anniversary at Google working on Chrome and leading a Developer Relations team. As we plan for the next few years, I'm reflecting on how we can improve Developer Satisfaction. Inspired by recent feedback on Apple's developer relations, I'm curious to hear your thoughts on what a web browser developer relations team should prioritize. What can we do more of? Less of? How can we best support you and your team? Share your opinions, especially broad strategic ideas.

I'm looking for a Developer Advocate to join the Chrome team and help us improve web privacy. We have many ongoing and upcoming projects within the Privacy Sandbox initiative. This role will focus on advocating for cross-browser privacy solutions, working with external developers, and ensuring our internal teams prioritize user and developer needs. This will involve explaining potentially disruptive changes (like the SameSite cookie attribute update) and helping developers adapt.

Chrome 81 finally fixes a long-standing bug where images taken in portrait mode on phones were displayed in landscape. Now, images will respect the orientation from the EXIF data by default, unless overridden with the CSS attribute image-orientation: none. Check out the demo!

The File Web Share Target API is a new, powerful feature in Chrome Canary that allows web apps to receive files (like images) shared from other apps, much like native apps. This post details how I implemented this API on my blog, enabling direct image uploads from my Android camera app. The process involves declaring support for file sharing in your web app manifest and handling the incoming file data in a service worker. The API uses a progressive approach, leveraging standard form POST requests, making integration relatively simple. This feature significantly enhances web app integration with the host operating system, closing the gap between web and native apps.

I recently noticed Twitter has adopted the Well-Known URL for Changing Passwords, which is a simple yet effective way to improve user experience. This spec allows browsers to offer a UI for quick password resets without navigating complex site structures, simply by checking a well-known URL. This sparked an idea: could we expand this concept to other common user actions? Imagine well-known locations for managing GDPR consent, browser permissions, account details, or mailing list subscriptions. It's a powerful concept that could simplify many online interactions, and I've even raised an issue with Chrome to explore implementation.

The Web Share Target API is now available as an origin trial in Chrome, bridging the gap between web and native apps. Previously, only native apps could register as share targets, limiting the web's ability to seamlessly integrate with system-level sharing functionalities. This new API empowers installed web apps to receive shared content, opening up exciting possibilities for web developers. The API's potential is highlighted by Twitter's early adoption and my own experimentation with a custom manifest.json file. While file support is still pending, the future looks bright for effortless content sharing between web and native environments.

I've encountered a bug in Chrome on Android where MediaRecorder, using Canvas.captureStream(), fails to encode video from large canvas elements (e.g., 1280x720). While the process works on desktop Chrome, on Android, the recording stops abruptly at unpredictable points, likely due to limitations in the MediaRecorder API's encoding capabilities. A smaller canvas (640x480) works fine, suggesting resolution-based limitations. I've reported this as Chrome bug 897727 and created a demo to illustrate the issue.

The Page Lifecycle API introduces lifecycle states to the web, giving developers control over how their web apps respond to browser actions like tab unloading and backgrounding. This addresses the historical lack of lifecycle management on the web, which has hindered resource optimization, especially on low-powered devices. The API defines system-initiated states for hidden or inactive tabs, allowing browsers to limit resource consumption. Developers gain control through new APIs and events, enabling them to save state before the browser reclaims resources, such as memory, battery, and network. This collaboration between developers and browsers ultimately improves the user experience by increasing web page reliability and responsiveness.

In Chrome 68, the Add to Homescreen banner will no longer automatically appear, even if the site meets the criteria. Instead, developers have control over prompting users. Listen for the beforeinstallprompt event, then present a custom button or UI element to trigger installation when appropriate. This change aims to reduce annoying prompts and give developers more control over the user experience. While potentially impacting install rates initially, it empowers developers to prompt users strategically. Chrome is exploring ambient badging as a less intrusive way to indicate installability.

I explored the Ambient Light Sensor API, a new feature available in PWAs. It lets developers access ambient light levels in lux units, useful for various applications like smart home lighting control or adjusting app brightness based on environmental conditions. The API is built on the Generic Sensor API, which also supports other sensors like gyroscopes and magnetometers. I previously discussed the Generic Sensor API at Chrome Dev Summit 2016, and it's now available in Edge and Chrome (behind a flag).

Share Target API is now in Chrome breaking down one of the last silos of native platforms

Use onappinstalled to detect when a progressive web app is installed.

A simple bookmarklet that will performance trace the current page and open in an hosted devtools instance

How should Web and Chrome Developer Relations work?

This little doozey hit me, so I'm documenting incase anyone else has the same issue

I'm excited to share the latest addition to the Shape Detection API: the Text Detection API! This API allows you to detect text within images in real-time, right in the browser. It's still experimental and currently works on Chrome Canary for Android, but it opens up amazing possibilities. Imagine real-time translation, assistive technologies for parsing image content, or even grabbing URLs from slides at conferences. I've built a demo where the API detects text, draws a box around it, and reads it aloud when clicked. Check out the code and demo to experiment yourself. I can't wait to see what you build with this!

I'm excited about the new experimental Shape Detection API in Chrome Canary! It provides a simple JavaScript API for face and barcode detection, leveraging underlying hardware for performance. This opens up new possibilities for web apps, from faster face detection and profile picture cropping to real-time tagging and optimized facial recognition. While currently only available in Chrome for Android (desktop support coming soon), I've shared a demo on JSBin. I also discuss strategies for progressive enhancement to ensure broader compatibility, including server-side detection, client-side JavaScript libraries, and the potential of Web Assembly. This API has the potential to revolutionize object detection performance on the web, and I'm particularly keen to see its impact on barcode scanning apps like my own QR Snapper.

I needed to figure out how to monitor events on an element (like when a field is autofilled) and Chrome DevTools has a monitorEvents function, but Firefox doesn't. Since I couldn't find an equivalent in Firefox DevTools, I created my own JavaScript function that iterates through an element's properties, finds event listeners (e.g., "onclick"), extracts the event name (e.g., "click"), and attaches a console logger to each event. The code snippet and a corresponding gist are provided.

I'm excited to share a new, simple API for sharing on the web called navigator.share! It's available in Chrome Dev Channel on Android and allows websites to connect with native apps for sharing. This is a step towards a better inter-app communication system, simplifying sharing and potentially extending to other app interactions. You can try it now on my blog by clicking the share button. I've updated my blog to use it, falling back to my existing solution if the API isn't available. Check out the ChromeStatus page and other linked resources for more information and give us feedback!

Tired of typing in usernames and passwords? So are your users. Autofill helps, but the Credential Management API gives developers more control. It lets you securely store and retrieve user credentials, simplifying logins with just a couple of taps. This Chrome-only API allows access to a PasswordCredential object, rather than raw passwords. It works with other improvements like proper autofill fields (email, username, new-password, current-password) and offers a potential future where landing and login pages are obsolete. Imagine a web where users stay logged in seamlessly, only re-authenticating when necessary. This post covers how to implement the API, including a demo and sample code. Plus, explore how it might combine with the Web Payment Request API to streamline e-commerce.

This post revisits the UX issues that contributed to the demise of Web Intents. We never adequately addressed the wide array of potential actions and data types, leading to a generic and confusing user experience. Handling data return from a long-running operation in another app proved problematic, especially if the initiating app closed. The lack of an explicit API for expecting returned data, similar to Android's startActivityForResult, further hindered the development of intuitive UI affordances. The open nature of Web Intents resulted in a proliferation of schemas and protocols, making standardization difficult. Users were forced to choose an app for every action, and developers lacked control over how apps launched, leading to inconsistent experiences. Finally, the absence of reliable fallbacks for unsupported intents eroded developer confidence and potentially left users stranded. In short, a combination of UX shortcomings ultimately led to Web Intents' downfall.

Deep App Links: Changes have come to Chrome and this is my summary of what's happened, why and how to manage the change

When you share a link from Chrome, you can also get a screenshot using a couple of Intent Extras

A weekly run-down for Feb

TIL: Use eye dropper directly on the web page.

TL;DR It's a long story; I learnt a lot.

Maybe? :)

Installing Chrome for Android directly onto an emulator isn't possible, as it's only available via the Play Store. However, you can install the Chromium Test Shell, an open-source, functional version of Chromium without Chrome's usual interface. Although it lacks features like bookmarking and sync, it supports remote debugging. Find recent builds online and install them via adb. I've even created a script to automate downloading, extracting, and installing the latest Chromium Test Shell build, available on GitHub.

Chrome Dev and Canary (18+) now support Web Intents! Currently, intent registration is done via the Chrome apps manifest (not the intent tag) to allow the user agent to determine available services (including those on the local network or external native apps). The manifest entry specifies the supported action, data types, title, and path. Client-side code remains the same. Future support for declaring capabilities directly through HTML with the Intent tag is planned.

Hey everyone, I've been playing with the dev channel of Chrome and discovered something huge: background pages for web apps! This means your web app can now run even when the browser is closed, or even after system start-up. It's crazy powerful. You enable this by adding the "background" permission to your app manifest and then using a simple window.open() call with a special third parameter. The background page's state can be toggled with window.close(). Communication between the background page and your app is done using SharedWorkers. Oh, and Appmator now supports this too!

My first year at Google has been an incredible journey. It's been a whirlwind of experiences, from joining the company after selling my Twitter web-app to working alongside industry experts like Chris Messina and Tim Bray. I started as a Developer Programs Engineer for iGoogle and Google Chrome in London, and later transitioned to a Developer Advocate role. My first month at the Mountain View campus was an intense learning experience. I've traveled extensively, presented at various events (including Google Developer Days in Munich, Moscow, and Prague), and contributed to the launch of the Chrome Web Store. I'm excited to see what the future holds, including speaking at Google IO and working with more developers outside of London.

In this post, I address the question of how to detect Chrome Extension updates. While there isn't a single API call for this, we can achieve it using the Management API's onInstalled event, which fires upon both installation and updates. By maintaining a record of installed extensions and their versions, we can compare the version in the onInstalled callback with our existing record, identify updates, and notify the user when an update occurs.

This blog post introduces Omni Launch, a Chrome extension I built that lets you quickly launch installed web apps directly from the URL bar. Just type "go", followed by a TAB or SPACE, and then the app name. The extension searches your installed apps and provides suggestions as you type. I also explained the development process, which only took about 20 minutes, including setting up the manifest, hooking up event listeners for omnibox input changes and selections, and using the Management API to fetch and launch apps. The code is available on GitHub.

In a previous post, I demonstrated how to create a custom App Launcher using the Management API and Override Pages framework. However, this approach didn't allow users to retain their custom NTP and utilize webstore apps concurrently. Thus, I developed "Quick Launch," a browser action extension that addresses this issue. The extension reuses much of the NTP tutorial's code but utilizes the 'browser_action' in the manifest, enabling a popup.html to display installed apps upon clicking the extension's icon. The popup.html dynamically generates a list of installed apps using the Management API and displays them with their icons. The source code is available on GitHub.

This blog post demonstrates how to create a Chrome extension that replaces the new tab page with an app launcher. The extension uses the Chrome Management API to retrieve a list of installed apps, displays their icons and names, and enables launching apps by clicking on their icons.

In appmator, I wanted to avoid traditional web elements like 'Save As' buttons. Instead, I implemented a drag-to-desktop feature using Chrome's drag-and-drop functionality. By setting a 'DownloadURL' with a data URI or regular URL on the 'dragstart' event, users can drag data directly to their desktop. This method bypasses the need for a save button. The code example demonstrates how to use the dataTransfer.setData() method with the DownloadURL type. It leverages the JSZip library to generate ZIP files as data URIs for dragging. This approach is Chrome-specific and has no feature detection available.

I'd love a Chrome Extension that converts times and dates to my local timezone. It gets confusing seeing times like 12pm PST when it's actually 8pm where I am. A simple conversion would be incredibly helpful!

This post concludes the "Buzz This" Chrome Extension series by demonstrating how to add context menus. Context menus provide a powerful way to interact with users, letting them "Buzz" specific content like images or selected text, rather than the entire page. This is achieved by adding "contextMenus" to the permissions in the manifest file and then using chrome.contextMenus.create() in the background.html file. The create() method takes an object that defines the context menu's title, contexts (e.g., "page", "selection", "image", "link"), and an onclick event handler. The click handler determines the context of the click (selected text, image, link) and constructs the Buzz API URL accordingly. The code for the extension is available on GitHub.

In this follow-up tutorial, we enhance the "Post to Buzz" Chrome Extension by adding a share count to the browser action button. This involves making cross-domain requests to the Buzz API's buzzCounter endpoint. We've updated the manifest file to include necessary permissions and added code to background.html to handle tab changes and URL updates. The code retrieves the Buzz count for the current URL and displays it on the browser action button, providing users with real-time feedback on share activity. This subtle update enhances the user experience and provides valuable context within the extension.

This tutorial provides a step-by-step guide to building a basic Chrome extension for posting to Google Buzz. We start by setting up the manifest file with the extension's name, version, and browser action details like the icon and tooltip. Then, we introduce a background page to handle the extension's logic, adding an event listener to detect clicks on the browser action button. Initially, we demonstrate how to display the current URL, and then extend the functionality to open a new tab directed to Google Buzz, pre-filled with the current URL for posting. The tutorial concludes by adding the 'tabs' permission to the manifest for enabling tab creation. Future enhancements will include fetching Buzz stats for the current URL, demonstrating cross-domain requests and browser_action interaction.

I've created a simple Chrome extension that lets you post the current page to Google Buzz and see its popularity. In upcoming posts, I'll use this example to demonstrate how easy it is to build Chrome Extensions and add cool features, like using Browser Actions, the Tabs API, Cross Domain Requests, and the Context Menu API. Check out the extension and its code on the Chrome Web Store and Github.