XGxg15·Dec 19, 2018
More in-depth discussion about the rationale and design process behind the intervention: https://github.com/WICG/interventions/issues/21
In Google Chrome to stop back-button hijackingWICG
interventions
Web Development2016–2018
WICG / interventions · Archived
interventions
A place for browsers and web developers to collaborate on user agent interventions.
9Distinct people
10Mentions
0Explicit recommenders
176GitHub stars
What to know before exploring
What it is
A place for browsers and web developers to collaborate on user agent interventions.
GitHub
Where it is used
No documented product use has been verified yet.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by month10 dated mentions
Observed mentions: 2016-12-29 21:40:38 UTC to 2018-12-19 10:06:38 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| Dec 2016 | 2016-12-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 1 | 1 | 0 |
| Jan 2017 | 2017-01-01 00:00:00 UTC | 2017-02-01 00:00:00 UTC | 1 | 0 | 1 |
| Feb 2017 | 2017-02-01 00:00:00 UTC | 2017-03-01 00:00:00 UTC | 0 | 0 | 0 |
| Mar 2017 | 2017-03-01 00:00:00 UTC | 2017-04-01 00:00:00 UTC | 1 | 0 | 1 |
| Apr 2017 | 2017-04-01 00:00:00 UTC | 2017-05-01 00:00:00 UTC | 0 | 0 | 0 |
| May 2017 | 2017-05-01 00:00:00 UTC | 2017-06-01 00:00:00 UTC | 1 | 0 | 1 |
| Jun 2017 | 2017-06-01 00:00:00 UTC | 2017-07-01 00:00:00 UTC | 0 | 0 | 0 |
| Jul 2017 | 2017-07-01 00:00:00 UTC | 2017-08-01 00:00:00 UTC | 1 | 0 | 1 |
| Aug 2017 | 2017-08-01 00:00:00 UTC | 2017-09-01 00:00:00 UTC | 1 | 0 | 1 |
| Sep 2017 | 2017-09-01 00:00:00 UTC | 2017-10-01 00:00:00 UTC | 0 | 0 | 0 |
| Oct 2017 | 2017-10-01 00:00:00 UTC | 2017-11-01 00:00:00 UTC | 1 | 0 | 1 |
| Nov 2017 | 2017-11-01 00:00:00 UTC | 2017-12-01 00:00:00 UTC | 2 | 0 | 2 |
| Dec 2017 | 2017-12-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 0 | 0 | 0 |
| Jan 2018 | 2018-01-01 00:00:00 UTC | 2018-02-01 00:00:00 UTC | 0 | 0 | 0 |
| Feb 2018 | 2018-02-01 00:00:00 UTC | 2018-03-01 00:00:00 UTC | 0 | 0 | 0 |
| Mar 2018 | 2018-03-01 00:00:00 UTC | 2018-04-01 00:00:00 UTC | 0 | 0 | 0 |
| Apr 2018 | 2018-04-01 00:00:00 UTC | 2018-05-01 00:00:00 UTC | 0 | 0 | 0 |
| May 2018 | 2018-05-01 00:00:00 UTC | 2018-06-01 00:00:00 UTC | 0 | 0 | 0 |
| Jun 2018 | 2018-06-01 00:00:00 UTC | 2018-07-01 00:00:00 UTC | 0 | 0 | 0 |
| Jul 2018 | 2018-07-01 00:00:00 UTC | 2018-08-01 00:00:00 UTC | 0 | 0 | 0 |
| Aug 2018 | 2018-08-01 00:00:00 UTC | 2018-09-01 00:00:00 UTC | 0 | 0 | 0 |
| Sep 2018 | 2018-09-01 00:00:00 UTC | 2018-10-01 00:00:00 UTC | 0 | 0 | 0 |
| Oct 2018 | 2018-10-01 00:00:00 UTC | 2018-11-01 00:00:00 UTC | 0 | 0 | 0 |
| Nov 2018 | 2018-11-01 00:00:00 UTC | 2018-12-01 00:00:00 UTC | 0 | 0 | 0 |
| Dec 2018 | 2018-12-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 1 | 0 | 1 |
What Hacker News says
10 sourcesThe web is the only platform aside from perhaps some assembly languages that is that stable and that ubiquitous. Websites have always been a "write and forget" deal; there never was supposed to be any feedback loop of developers fixing breaking changes. This is why old websites from 1998 still work in your browser.
This is why there are piles and piles of cruft within browsers and web standards for making sure old behavior that folks may rely on continues to work.
The commitment to stability on the web is astounding; I don't see anyone changing that any time soon. Google should not be breaking things just for its users; because its users are affected when they break things too.
That's the problem with Javascript. When Javascript breaks, it's not the developers who get the error, it's users, who have no idea what it means and no way to fix
Read the rest
it. This is not the case with e.g. compiled languages; there's no extremely strict guarantee your code will still compile on a new release.
That said, Google did push this through the right channels (https://github.com/WICG/interventions/issues/35 , https://github.com/w3c/touch-events/issues/74 , https://github.com/WICG/interventions/issues/18 ) and it seemed like browser vendors were in agreement that this wouldn't be a problem. This is something that does happen; browser vendors "unship" or break functionality after discussing it sometimes.
So while I'm not convinced Chrome stepped out of line here, breaking sites absolutely is not putting users first.
> there ought to be an open discussion about timeframes and impact before a change happens
There was. In fact, there's a whole GitHub project dedicated to discussing proposed interventions like these: https://github.com/WICG/interventions
All interventions also get posted on the blink-dev mailing list before they are implemented: https://groups.google.com/a/chromium.org/forum/#!forum/blink...
In Chrome breaks the WebA couple of relevant discussions from Chrome devs:
https://bugs.chromium.org/p/chromium/issues/detail?id=740961
https://github.com/WICG/interventions/issues/49
In Ask HN: Why is no one talking about the rampant abuse of the Web Push API?this was considered, long discussion here https://github.com/WICG/interventions/issues/18
In Passive event listenersOr you could do some kind of middle-ground like what Chrome is planning, where the user can only be prompted to enable notifications after they've reached some specific level of engagement with the site they're using: https://github.com/WICG/interventions/issues/49#issuecomment...
In Apple’s refusal to support Progressive Web Apps is a detriment to the webI had filed an intervention to prevent websites from disabling the paste functionality in password fields - https://github.com/WICG/interventions/issues/41
In Let them paste passwords(Author of the post and Microsoft Edge team member here.)
This is actually an active area of discussion for browser vendors, and we're all experimenting with "interventions" that are designed to benefit users at the expense of web developers. Our most recent efforts can be browsed at https://github.com/wicg/interventions , and you can see things in there like "passive-by-default" event listeners, timer throttling for background tabs and cross-origin iframes, requiring user intent for vibration, etc.
Not all of these efforts have been popular with web developers, and some of them may even need to be rolled back. But browser vendors are indeed trying to address this problem! :) You'll note that Chrome, Firefox, Edge, and WebKit representatives are all involved in this effort.
In Scrolling on the web: A primerSeems like Edge also plans to do this: https://github.com/WICG/interventions/issues/34
In Chrome will aggressively throttle background tabsChrome document.write intervention preventing users from logging off sites
2 points · Open discussion