Use counter: https://www.chromestatus.com/metrics/feature/timeline/popularity/949

That is a bit concerning. Is this event and event handler attribute implemented anywhere else?

Sorry, not following. What's concerning?

The usage, around 0.4%, is much higher than most things that I'd consider easy removals.

However, since this is an event, it's possible that the numbers would look different if we measure how often the event is fired *and* an event listener is invoked. That's probably a smaller number.

Also, is it possible that most code listening for the typechange event also listens for the change event? If so, it's possible that removal is less risky than  if all of the 0.4% were hard failures.

It's possible, but would be strange to listen to both events. It seems like step one would be to add a deprecation message and see if usage drops over time.

In http://www.chromium.org/blink/removing-features we have "If you are unsure of when a feature could be removed, or would like to discourage usage, you may deprecate a feature without a removal deadline. This is strongly discouraged and will require significant justification."

The reason that I'd discourage this is that it generally doesn't seem like deprecation messages are an effective way of influencing the usage. My guess is that as usage drops, fewer and fewer people see the messages, and so usage doesn't decrease linearly. If we could cut it in half every year, then getting from 0.4% to ~0.01% is still about 5 years.

In a situation like this, anything we can do to understand the current usage is helpful. Should the combination of the string 'navigator.connection' and 'typechange' capture anything trying to use this API? I looked for the combination of those strings in HTTP Archive and there were only 80 hits:
https://bigquery.cloud.google.com:443/savedquery/762219082167:15130fc89b7c4a0f99011e18105ffebc

It's possible that the use counter is overcounting, perhaps due to trackers that traverse everything on the navigator object for fingerprinting purposes.

Are there other ways to depend on this API that would be missed by that query?

Changing to assigned to get this out of my triage queue :-)