Either webRequest should offer an asynchronous API or nativeMessaging should offer a synchronous API
Reported by
jon.jwil...@gmail.com,
Jul 5 2016
|
||||
Issue descriptionChrome Version : 50.0.2661.94 (Developer Build) (64-bit) https://developer.chrome.com/extensions/nativeMessaging https://developer.chrome.com/extensions/webRequest Imagine one wants to implement webRequest filtering using native.so or native.exe. Currently, this can not be done without hacks because of the following two facts: 1. webRequest is synchronous. 2. nativeMessaging is async-ONLY. That is a problematic API. In code: chrome.webRequest.onBeforeRequest.addListener( function(details) { let cancel = askNativeCodeWhatToDo(details.url); // why not? return { cancel: cancel } }, { urls: ["*://*.youtube.com/*"]}, ["blocking"]); Either nativeMessaging should offer a synchronous API, or webRequest should have an asynchronous API, or both.
,
Jul 12 2016
,
Jul 12 2016
,
May 15 2017
Also, there are use cases for adding asynchronous webRequest that do not involve nativeMessaging. For example, to make "cancel" dependent on a network request, one requires synchronous web requests (which impacts end user experience considerably).
,
Oct 19 2017
Just to show that we're not the only one needing this, the implementation of FireFox onBeforeRequest does support asynchronous calls (https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/webRequest/onBeforeRequest). onBeforeRequest can return a promise. Perhaps something to consider for chromium as well, since so many methods are asynchronous. I can think of many use cases that need this.
,
Oct 19
Issue has not been modified or commented on in the last 365 days, please re-open or file a new bug if this is still an issue. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot |
||||
►
Sign in to add a comment |
||||
Comment 1 by jon.jwil...@gmail.com
, Jul 5 20161.0 KB
1.0 KB Download