Can you explain why you believe you need asynchronous handling? This API choice is by design to prevent mistakes and to highlight the critical flow these extensions play. What functionality needs the asynchronous behaviour?

Hello, 

We have designed an extension. In that onBeforeRequest we are performing below steps:
1. send few information to our server
2. based on server response take appropriate action

In above scenario, synchronous behaviour is delaying the end user browsing performance. Thats why we request you to provide asynchronous handle on onBeforeRequest.

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This functionality is needed whenever you need to make an asynchronous operation to determine if the request has to be cancelled or to compute the redirectUrl.

Firefox does solve the issue by awaiting for any promise returned by the onBeforeRequest handler (see here: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/webRequest/onBeforeRequest).

We're working on an extension that enables our image resizing SAAS to our users in their development environment. Our servers cannot get the master images from their local/enterprise environment, so we need to:
- load the master image (we use an image tag with crossOrigin set to "anonymous" to go around any CORS limitations and be compatible with how our servers can request images without any CORS limitation) => asynchronous
- extract an ImageBitmap instance with the correct transformation => asynchronous
- use a WebWorker with an OffscreenCanvas to compute the data url (it's pretty costly and using a Canvas is very very slow when multiple images are loaded simultaneously) => asynchronous

Only then are we able to provide the computed data URL as the redirect URL.

We have a working prototype in Firefox save from the WebWorker part (no 2d context for OffscreenCanvas in Firefox).

Right now, the only "solution" we have for Chrome is to use a native host that creates a local webserver that we redirect to synchronously from onBeforeRequest. We then have to provide native binaries for windows, macos and linux with installers. Not to mention signing everything with corporate dev accounts to remove windows and macos security warnings.

As an added bonus, our proxy is coded in NodeJS for portability so we have to use NEXE to create our binaries which is another level of insanity on its own.

It is incredibly heavy handed and requires a ton of tedious work (both technical and administrative).

Chrome has all the functionalities we need save from a promise-aware onBeforeRequest.

As far as I can tell, onAuthRequired provides an asyncBlocking option. Is there any reason why onBeforeRequest does not?

I opened the very same issue on the Edge Bug Tracker. Here it is for reference: https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/19681660/