Eventually, once user apps began tying themselves into Chrome, the browser immediately became more vulnerable to crashing. It's not hard to understand why: if you inject code into a running application, there's no reason to expect that it's going to handle it gracefully. Google says that folks running apps that inject code into Chrome are 15% more likely to experience crashes.
We've reached a time where the internet is used for more than just killing the time. We rely on it, so Google wants to make sure that we're not going to have crashes impede our browsing. This coming April, with Chrome 66, the company will begin weening people off solutions that require code injection.
With Chrome 66, users will be given a message after a crash that explained to them what happened, and then suggests to them to either remove, or update the software. In the case where an update is all that's needed, it's likely because the software vendor moved onto other techniques, such as relying on extensions instead of direct injection.
Impacted users will begin seeing messages like these in the near-future
A couple of months later, in July, Chrome 68 will drop, and it will begin rejecting code injections, but there's a caveat. If code injection is somehow required for the browser to work, after its initial crash, it will restart and then allow the injection to take place. Again, messages will tip the user off to what the issue is, how to fix it, and why it'll be even more of a problem in the future, once Chrome 72 launches.
We're really looking to the future now. In January 2019, Chrome 72 will block code injection 100% of the time. That gives software vendors, such as those producing anti-virus products, plenty of time to get work done on alternative solutions, such as using a browser extension instead. Google notes that Microsoft-signed code, accessibility software, and IME software will be unaffected by these changes. The company also suggests developers opt to use the beta version of Chrome, to make for more efficient and effective testing. That's not a bad idea, because if your software solution is responsible for crashing someone's browser, that customer will inevitably seek out alternatives.