Some of the top addons in the Chrome Webstore (including AddBlock) still rely on this method. Currently, when running one of these addons as a WebExtension, we throw the following error: `chrome.extension.onRequest is undefined`. This bug is meant to figure out if this is the best way to handle this. For example, rather than throwing an error, we could log a warning saying "This method is deprecated (Please use runtime.onMessage)".

This is something those extensions are going to have to change to maintain Chrome compatibility anyway. I don't think we should waste time implementing workarounds to support deprecated features.

How about just writing a polyfill for these sorts of issues?

I'm not sure what the point would be. Adding the polyfill wouldn't be any easier than just updating the extensions to use sendMessage/onMessage.

The point would be having a single polyfill that we could drop into an existing Chrome extension and never have to touch the existing code (which would be particularly useful if the extension is minified etc). You're right that *if* the author of the Chrome extension cares about making the extension work in some future Chrome version they will eventually have to make that change but there's no reason we shouldn't be able to use those extensions now without waiting for / depending on them (modulo API support and other compatibility issues of course)

I'm not convinced that anyone would be more likely to update an add-on to use a polyfill than to just use a supported version of the API.

This bug is probably the wrong place for this discussion, but (I realize I'm waving my hands a bit here) we could conceivably inject it automatically on AMO for chrome extensions so that things just work.

I don't think that we could. That would require knowing what pages and/or scripts are used in what contexts, which isn't easy to figure out. In any case, it would be much more work than just implementing the APIs with deprecation warnings. We could do it from the browser, but there wouldn't be any benefit to that over just implementing the deprecated APIs.

We definitely don't want to implement the deprecated APIs, even if it's a simple alias (which in this case I believe it is not). I think it's best to advocate with the developers to encourage them to update their extension to use the non-deprecated API, which is actually something that we discussed a day or two ago.

At the very least we should look at getting the linter to parse the add-on, compare with the schema (maybe) and find APIs and flag them as unsupported because of the deprecation. I think working with devrel to reach out to those developers to get them to update should be our first approach. If we find that this is a problem, we could look at doing a polyfill then, but let's see how it goes with outreach first.

(In reply to Andy McKay [:andym] from comment #9) > At the very least we should look at getting the linter to parse the add-on, > compare with the schema (maybe) and find APIs and flag them as unsupported > because of the deprecation. > Yes, we discussed this as well, and said that we should open an issue for the linter for each deprecated method we identify, so that the linter can flag them.

We won't be filing bugs in bugzilla for deprecated methods. Instead, we will be filing a bug against the linter in github.