I know I’m not the only one who gets super annoyed by content jumping around while I’m reading it - and I’d never intentionally create that experience for my users. But sometimes you just don’t know how your code behaves “in the wild”, and you can’t exactly ride-along with every user. The Layout Instability API aims to address this issue:

How a site functions in development is often quite different from how users experience it in production: personalized or third-party content often doesn’t behave the same in development as it does in production, test images are often already in the developer’s browser cache, and API calls that run locally are often so fast that the delay isn’t noticeable.

The first step toward properly solving this problem is to give developers the tools to measure it and understand how often it’s occurring for real users. The Layout Instability API, currently being incubated in the WICG, aims to address this.

OctoLinker is a Chrome extension that turns language-specific statements like include, require, import, etc. in to clickable links. Try before you buy install with their in-browser demo.

Welcome to HSBC, the world’s seventh-largest bank! Of course, the page you’re reading isn’t actually hosted on hsbc.com; it’s hosted on jameshfisher.com. But when you visit this page on Chrome for mobile and scroll a little way, the page is able to display itself as hsbc.com - and worse, the page is able to jail you in this fake browser!

Scary stuff since there is no known protection against this attack. It seems to be up to the Chrome team to figure out a solution.

Love it or hate it, the march of AMP drives on…now your pages can appear under your URL instead of the google.com/amp URL.

Today we are rolling out support in Google Search’s AMP web results (also known as “blue links”) to link to signed exchanges, an emerging new feature of the web enabled by the IETF web packaging specification. Signed exchanges enable displaying the publisher’s domain when content is instantly loaded via Google Search. This is available in browsers that support the necessary web platform feature—as of the time of writing, Google Chrome—and availability will expand to include other browsers as they gain support (e.g. the upcoming version of Microsoft Edge).

If you’ve been wondering how Microsoft’s mix of Chrome and Edge would look, then check this out. Tom Warren writing for The Verge:

Most of the user interface of the browser is a mix of Chrome and Edge, and Microsoft has clearly tried to add its own little touches here and there. There’s a read aloud accessibility option, and it simply reads the page out loud like it does in existing versions of Edge. Some features that you’d expect from Edge are missing, though. Microsoft hasn’t implemented its set aside tabs feature just yet, and write on the web with a stylus isn’t available. A dark mode is only available via a testing flag right now.

Reda Lemeden shared a healthy dose of reality in regards to Chrome’s control of the web and market share:

Ten years ago, we needed Google Chrome to break the Web free from corporate greed, and we managed to do so for a brief period. Today, its dominance is stifling the very platform it once saved from the clutches of Microsoft. And no one, beside Google, needs that.

Without a healthy and balanced competition, any open platform will regress into some form of corporate control. For the Web, this means that its strongest selling points—freedom and universal accessibility—are eroded with every per-cent that Chrome gains in market share.

Gervasio Marchand lays out all the ways in which Slack’s threads feature is lacking. Then he goes one to describe why his browser extension, Refined, makes threads better.

Peter Bright writes for Ars Technica:

Microsoft adopting Chromium puts the Web in a perilous place. […] With Microsoft’s decision to end development of its own Web rendering engine and switch to Chromium, control over the Web has functionally been ceded to Google. That’s a worrying turn of events, given the company’s past behavior.

This post was mentioned in Slack by James Lovato about a former Microsoft Edge intern claiming Google callously broke rival web browsers. Then, Nick Nisi chimed in to mention this post by Jeremy Noring as “an interesting rebuttal/defense of what they’re doing.”

Dave Rupert feels that Microsoft Edge switching to Chromium makes other browser rendering engines “edge cases”:

If there’s one thing I know about developers, it’s that we love to ignore edge cases because edge cases make our jobs more difficult. Google itself regularly ships Chrome-only products and I’ve been told by Googlers that they’re directed to only care about Chrome.

Like Dave, I feel torn between different arguments. But just as Blink is a fork of WebKit, who knows if we’ll also see a fork of Chromium led by Microsoft in the future.

Should I read this 22 minute read on the state of web browsers? Sure. Count me in!

Microsoft has confirmed the rumor to be true. We now have one less browser engine, and a last man standing (Firefox) in deep trouble (reasons below).
…
The web now runs on a single engine. There is not a single browser with a non-Chromium engine on mobile of any significance other than Safari. Which runs webkit, kind of the same engine as Chromium, which is based on webkit.

Big rumor coming out of Redmond this week:

Microsoft is throwing in the towel with EdgeHTML and is instead building a new web browser powered by Chromium, which uses a similar rendering engine first popularized by Google’s Chrome browser known as Blink.

I’ve long been a proponent for browsers differentiating at the feature/integration layers and teaming up at the rendering layer, so I view this as good news. What do you think?

Google UX Engineer Adam Argyle joins Jerod and KBall to share all the details on VisBug, his just-released Chrome Extension that “makes any webpage feel like an artboard.” Adam is passionate about doing for designers what Firebug (and later DevTools) did for developers. In this episode, he shares that passion and how it’s driven him to create and open source VisBug.

Hold on to your seat! This is a deep dive on improving time-to-interactive for Netflix.com on the desktop. Addy Osmani writes on the Dev Channel for the Chromium dev team regarding performance tuning of Netflix.com. They were trying to determine if React was truly necessary for the logged-out homepage to function.

Even though React’s initial footprint was just 45kB, removing React, several libraries and the corresponding app code from the client-side reduced the total amount of JavaScript by over 200kB, causing an over-50% reduction in Netflix’s time-to-interactivity for the logged-out homepage.

There’s more to this story, so dig in. Or, share your comments on their approach to reducing time-to-interactivity and if you might have done things differently.

Several major browsers you and I use everyday are capable of leaking our browsing history, and they all know about it. Caroline Haskins at Motherboard writes:

Most modern browsers—such as Chrome, Firefox, and Edge … have vulnerabilities that allow hosts of malicious websites to extract hundreds to thousands of URLs in a user’s web history, per new research from the University of California San Diego.

In a statement provided to Motherboard via email, senior engineering manager of Firefox security Wennie Leung said that Firefox will “prioritize our review of these bugs based on the threat assessment.” Google spokesperson Ivy Choi told Motherboard in an email that they are aware of the issue and are “evaluating possible solutions.”

Ben Adida shared this on Twitter:

When first web history sniffing attacks came out, I suggested we had to change the notion of a visited link: a link would be marked visited by origin (edges, not nodes.) That was considered too dramatic a change. Maybe it’s necessary after all.

Who’s ready to dig into this research and share how vulnerable we really are and what types of malicious websites could/would extract our browsing history? If you do, let us know so we can link it up.

In the documents that define how the Web works, a browser is called a user agent. It’s supposed to be the thing that acts on your behalf in cyberspace. If the massive data collection appetite of Google’s advertising- and tracking-based business model are incentivizing Chrome to act in Google’s best interest instead of yours, that’s a big problem—one that consumers and regulators should not ignore.

It’s no surprise that privacy-focused browser alternatives are gaining ground in the quest to be your user agent. This coming week, we’re sitting down with Brave’s CTO for what should turn out to be a fascinating episode of The Changelog. Stay tuned for that.

Modifications to Google Chromium for removing Google integration and enhancing privacy, control, and transparency

For those of us who love Chrome too much to leave it, but would prefer not have Google all up in our browser. By the way, now is a pretty good time to give Brave and/or Firefox a spin, if you haven’t recently.

Like many of you reading this, you’re probably signed into a Google service when browsing the web — Google apps (G Suite), YouTube, Gmail, etc. The line between browser (Chrome) and your signed in services was clear before, and now it’s not.

Matthew Green, Cryptographer and Professor at Johns Hopkins University, writes on his personal blog:

What changed? A few weeks ago Google shipped an update to Chrome that fundamentally changes the sign-in experience. From now on, every time you log into a Google property (for example, Gmail), Chrome will automatically sign the browser into your Google account for you. It’ll do this without asking, or even explicitly notifying you. However, and this is important: Google developers claim this will not actually start synchronizing your data to Google — yet.

Thankfully I have been using Brave a whole lot more recently and I’ve really been enjoying an internet where display ads aren’t ruining the experience, and where my privacy isn’t being harvested as I use it.

Gervasio Marchand:

While working on Taut (aka BetterSlack) I noticed that a browser extension could do lots and lots of harm. On this article, I explain how the only way to browse safely is to completely avoid them (or to be really really involved in managing them).

If you’re thinking, “But open source!” click through and see what Gervasio has to say about that. He also includes some examples of extensions that went rogue or were hacked and how one could abuse the system.

On the Chromium Blog, Paul Kinlan shared a look back to the beginning of Chrome in 2008, the early days of the web, on through to today and the future of the “capable web.”

2008-2014 — In just seven years, the web changed drastically. Browsers got significantly faster and more capable, letting developers build richer experiences on the desktop. Users started to consume even more content on mobile, meaning we all had to rethink how our experiences would work across devices and form-factors, even when the user had no connectivity.

If you’re looking for some perspective on how far we’ve come with the web and the impact of iteration — you should check this out. BTW — Chrome turned 10, here’s what’s new.

Whether you’re using Puppeteer for scraping, testing, monitoring, or something else entirely.. writing the scripts is a whole lot easier with Puppeteer Recorder.

Does BetterSlack make Slack better?

…there are 2 or 3 things about Slack I think can be made better. That’s why I built BetterSlack. It’s a Chrome extension that injects javascript into your Slack environments to add (or remove) features.

Hide certain users, generate hangout links, move reactions to the right, threads on channel by default, hide status emojis … Gervasio has a 3 minute demo to explain things in more detail…

Have you considered using a PWA to create a Chrome extension?
Sam Thorogood writes on Dev.to:

So you’ve built a PWA, created your service worker, and followed all the guides. In my case, that is Emojityper: a simple PWA where you can enter words, and receive emoji. This is perfect for desktop and entering emoji in editors that don’t support them.

But once you’ve built this great experience, you’re not limited to distributing it only on “the web”. In this post, I’m going to detail how I shipped Emojityper as a Chrome extension, accessible via a browser action.

We were just talking about this on this week’s JS Party!

A new Chrome feature dubbed “Blink LazyLoad” is designed to dramatically improve performance by deferring the load of below-the-fold images and third party iFrames.

Ben Schwarz has a nice overview of the feature and how you can use it today in Chrome Canary (behind two feature flags).

Chrome security has reached a milestone — Chrome will now mark http as “not secure”.

Nearly two years ago, we announced that Chrome would eventually mark all sites that are not encrypted with HTTPS as “not secure”. This makes it easier to know whether your personal information is safe as it travels across the web, whether you’re checking your bank account or buying concert tickets. Starting today, we’re rolling out these changes to all Chrome users.

Also, check out this episode of HTTP203 with Emily Schechter (Product Manager on the Chrome Security team)

The big question with tools like these is, what can I do with it?

1. Child processes are detected and attached to.
2. You can place breakpoints before the modules are required.
3. You can edit your files within the UI. On Ctrl-S/Cmd-S, DevTools will save the changes to disk.
4. By default, ndb blackboxes all scripts outside current working directory to improve focus.

And more.