1889897 - Implement asyncBlocking support for webRequest.onAuthRequired

Status: RESOLVED FIXED

(WebExtensions :: Request Handling, enhancement, P2)

Description

[Luca Greco [:rpl] [:luca] [:lgreco]]

While working on Bug 1820569 we noticed that webRequest.onAuthRequest is also the only webRequest API that is expected to support an "asyncBlocking" extra in addition to "blocking" (which is the extra more commonly used and supported by all other webRequest API events).

This bugzilla issue is tracking following up to Bug 1820569 with the additional changes needed to support the "asyncBlocking" extra listener option.

The following are a few parts of the webRequest docs from Chrome where the asyncBlocking option is briefly described:

• https://developer.chrome.com/docs/extensions/reference/api/webRequest#event-onAuthRequired
• https://developer.chrome.com/docs/extensions/reference/api/webRequest#handle-auth

Comment 1

[Rob Wu [:robwu]]

asyncBlocking is also documented here:

• https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/webRequest/onAuthRequired
• https://github.com/w3c/webextensions/issues/490

Since addListener was effectively no-op when asyncBlocking was used in Firefox, we could consider behavior such as ignoring promised return values when asyncBlocking is used. I'll check with Chrome to see what API they would prefer.

Comment 2

[Luca Greco [:rpl] [:luca] [:lgreco]]

Attachment: Bug 1889897 - Implement asyncBlocking support for webRequest.onAuthRequired. r?robwu!

Comment 3

[Rob Wu [:robwu]]

I asked Chrome about their desired design for Promise support in webRequest.onAuthRequired. Although I recommended making it part of "blocking", they are leaning towards making this part of a new extraInfoSpec key (e.g. asyncBlockingPromise), as seen at https://github.com/w3c/webextensions/issues/490#issuecomment-2061176472

In any case, it is obvious that Promise as a return value is not supported with asyncBlocking.

We currently do not register any listener when asyncBlocking is passed, regardless of whether blocking is present. I wondered whether we should support, ignore or throw when asyncBlocking and blocking are present.

I audited all public extensions on AMO that uses asyncBlocking, and did not find any extension that uses both at the same time. Probably because Chrome already crashes the whole extension process when blocking and asyncBlocking are used together (https://issues.chromium.org/issues/41455878). Most commonly I saw conditionals, to use "blocking" in Firefox and asyncBlocking in Chrome. I also encountered a few examples that used asyncBlocking unconditionally - these extensions were blindly ported from Chrome and did not actually work in Firefox.
... so it does not really matter to existing extensions whether we keep the existing behavior (ignore when asyncBlocking+blocking is used, with an error logged in the parent), throw synchronously, or accept blocking + asyncBlocking.

Since asyncBlocking is primarily for Chrome compatibility, I would lean towards making asyncBlocking and blocking mutually exclusive, so that asyncBlocking implies non-Promise callback, and blocking implies no callback. Mutual exclusiveness can be enforced through schema validation.

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/49cfa095a80b
Implement asyncBlocking support for webRequest.onAuthRequired. r=robwu

Comment 5

[Serban Stanca [:SerbanS]]

Backed out for causing xpcshell failures in test_ext_webRequest_auth.js.

• Backout link
• Push with failures
• Failure Log

Comment 6

[Luca Greco [:rpl] [:luca] [:lgreco]]

I just looked into the failure hit when running on a debug build and updated the patch (by applying a small tweak to the specific test case).

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/a4cc38165107
Implement asyncBlocking support for webRequest.onAuthRequired. r=robwu

Comment 8

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/a4cc38165107

Comment 9

[Rob Wu [:robwu]]

MDN currently claims that asyncBlocking/asyncCallback is only supported in Chrome. Let's also mention that it is supported in Firefox 128+ for compatibility. If not obvious yet, mention that the use of asyncBlocking is mutually exclusive with "blocking". And that the use of "asyncBlocking" implies that the result should be passed via a call to asyncCallback, and not via a return value.

Comment 10

[rbloor]

MDN content changes are ready for review asyncBlocking in webRequest.onAuthRequired #34137