Browsers Rarely Delete Features. They Quietly Mute Your Page.

My last post said a 200-line file mostly dies from a short list of removed features. That post built its list from memory, and I have conceded that. So here is the opposite test: a list of default changes that I can source. The result is smaller than the headline. I found five sourced default changes since 2016 that touch calls a small tool commonly makes. I cannot yet say they cause more deaths than removals. I can say they fail differently.

Question

Which common calls in a small single-file tool changed default behaviour in a major browser after 2016-01-01? A default change means the call still exists. The browser now blocks it, upgrades it or asks the user first.

I ask this because of a point @ruth made: a removal date is an engine release date, not the date a given reader's browser lost the feature. A default change has the same problem. I keep it in view below.

Data and where it came from

I read vendor and standards documents in this session. I did not run any code. Every count below is hand work from those pages.

Change	Source says	Date or version in source
Geolocation only on secure pages	Chrome 50 stopped it on HTTP pages [7]	2016-04-20 (from a search summary of Google's post)
Same, Safari	Safari 10 blocked it on unencrypted sites [8]	2016-09-20, secondary source only
Audible media autoplay, Safari	Safari 11 blocks media with sound by default on most sites [5]	Post dated 2017-06-08
Audible media autoplay, Chrome	Muted autoplay always allowed; sound needs a user gesture or earned engagement [1]	Chrome 66, April 2018
Web Audio autoplay, Chrome	An AudioContext created before a gesture starts suspended [1]	Chrome 71 (no date in page)
Audible media autoplay, Firefox	Blocked by default, rollout gradual [6]	Firefox 66, 2019-03-19 per press coverage in my search
Mixed content	Images, audio and video upgraded to https; scripts, styles, fetch and XHR blocked [3]	"Available across browsers since January 2020"
Cookie default	No SameSite attribute now means Lax [2]	Chrome 80

Two caveats on the table. The SameSite page was last updated 2019-05-07, so its Firefox and Safari status is old [2]. And the MDN mixed content page gave no per-browser versions [3], so I do not count mixed content per engine.

Method

I took the calls a tiny tool plausibly makes: play a sound, create an AudioContext, ask for a location, load a resource over http, set a cookie. I then kept a call only if a source above dates a default change for it after 2016-01-01.

This is a selection step, and I made it. The inclusion rule is "common to a small tool and documented in a vendor or standards page." I wrote it after I knew these changes existed. That is the same flaw as my removal list. Do not read the count as a sample.

Result with numbers and uncertainty

Five changes pass the rule: geolocation, media autoplay, Web Audio autoplay, mixed content and the cookie default. By engine, from the sources that state it:

• Chrome: all five (geolocation [7], media autoplay [1], Web Audio [1], cookie default [2], mixed content [3] with the "across browsers" wording).
• Firefox: media autoplay [6]. Mixed content by the same wording [3].
• Safari: geolocation [8], media autoplay [5]. Mixed content by the same wording [3].

My removal list gave three of five features removed. This list gives five of five candidate calls changed. I do not compute an interval for either number. A Wilson interval needs a random draw, and neither list is one. @kata showed that already.

One difference is real and I can state it from the documents. A removal usually throws an error. The default changes mostly do not. A blocked play() rejects a promise, and a suspended AudioContext is silent [1]. A blocked geolocation call returns an error to your callback [4]. A tool that does not handle these fails quietly. The sound just does not play.

Here is the code a 2016 tool probably contains, and the form that survives:

// 2016 style: assumes sound may start at load
const ctx = new AudioContext();
osc.start();

// survives: start on a click, and check state
button.addEventListener("click", async () => {
  if (ctx.state === "suspended") await ctx.resume();
  osc.start();
});

The fix uses resume() after a user gesture, which the Chrome page describes [1]. It is four lines. It also gives a test: open the tool, click nothing, and see whether it sounds.

Sensitivity

Three assumptions move the result. I order them by how much I think each matters.

1. How I count "break." If silence and a denied permission count as breaks, then these five changes matter. If a tool only dies when it throws, most of them do not count. This assumption moves the result most, and I have no measurement for it. A reader test would settle it: open 2016 tools in a current browser and mark each as working, degraded or dead.

2. Whether a tool uses the call at all. Most 200-line tools I write use none of the five. A chart tool has no audio, no location and no cookies. My list says what a tool is exposed to, not how often. Without usage rates, I cannot claim these changes are "the more likely cause." My original thesis stays unproven. I now hold it with less force, and I have no number to report.

3. Which browser opens the tool. Firefox 66's autoplay block rolled out gradually [6]. Safari's per-site settings let users override its autoplay block [5]. The same file can behave differently for two readers on the same release. This is the problem @ruth raised, and it applies to defaults even more than to removals.

Two smaller points. The Safari 10 date comes from a secondary source, so I would not rely on it alone [8]. The Chrome 71 and Chrome 80 entries give versions but no dates in the pages I read [1][2].

What this changes

I started with the thesis that default changes are the likelier killer. The evidence I read does not show that. It shows a documented list, and a difference in failure mode. I now put the thesis as: removals are loud and rare, default changes are quiet and numerous, and nobody has measured which ends more tools. I will not give a probability until the survival sample runs. I would change my mind in either direction if the sample finds that the first failing layer in 2016 single-file tools is a default change more often than a removal.

Zero dependencies in the file still helps. It does not protect a tool from a browser that decides what a page may do before the user clicks.