This bug will take care of implementing the network.continueWithAuth command.

Before implementing this, I was looking at what DevTools show for a basic authentication flow, eg when you get a prompt and submit the correct credentials.

Firefox DevTools show only one request with status 200 and the final response.
Chrome DevTools show 2 requests, the first failing, with no response ; the second one with status 200 and the final response.
Since the behavior is inconsistent, I would like to check the expected events before going further.

Looking at the fetch spec, it seems that when we reach the auth prompt, we should run another fetch, and reuse its response as the response of the first fetch:

Set response to the result of running HTTP-network-or-cache fetch given fetchParams and true.
(from https://fetch.spec.whatwg.org/#http-network-or-cache-fetch)

So in terms of BiDi events, if we imagine a fetch on a URL with www-authenticate headers, it means we would get first:

• beforeRequestSent for the initial request
• responseStarted for the initial request
• authRequired for the initial request

At this point we imagine that we either have an intercept catching this and use continueWithAuth, or that the credentials are provided manually. So based on the fetch spec, we start a new fetch with the credentials set in the request headers, so we should now get:

• beforeRequestSent for the request with credentials
• responseStarted for the request with credentials
• responseCompleted for the request with credentials

And finally

• responseCompleted for the initial request (which should have the same response content as the new request)

James: does this sound right to you?

Hmm, so this is fun. The way that BiDi is currently integrated into fetch means that afaict for the request with auth you get a beforeRequestSent and a responseStarted, but you only get a single responseCompleted for both requests, because we only run the "main fetch" algorithm once (the request with credentials calls directly into HTTP-network-or-cahce-fetch). That does seem like it might be problematically invariant violating, and we can likely fix it if it's a problem.

Depends on D195673

Depends on D195675

Hi Olivia,

I'm having an issue on Android when trying to resume an authentication request.
BiDi can intercept requests right before the auth prompt is displayed, and then if we use the continueWithAuth command with action=default, the idea is that the browser should do the default behavior, meaning showing the auth prompt.

Technically, we use a wrapper in devtools to do the forwarding: https://searchfox.org/mozilla-central/rev/dc5027f02e5ea1d6b56cfbd10f4d3a0830762115/devtools/shared/network-observer/NetworkAuthListener.sys.mjs#62-69

First we get the prompt, and then we call prompt.asyncPromptAuth on it. On GeckoView side, I saw that we are reaching AuthHandler:callDelegate, but then it only seems to call onAuthPrompt in GeckoSession.java which returns null. We never go into what seems to be the real code showing a prompt in BasicGeckoViewPrompt.

Do you have an idea about what could be wrong here?

Hi Julian,

Thanks for looking at GeckoView too!

We never go into what seems to be the real code showing a prompt in BasicGeckoViewPrompt.

Is this happening in automation? If that is the case, it looks like onAuthPrompt isn't implemented in the test runner activity. GeckoView example activity code isn't shared with the test runner activity. So, if this is in automation, we will need to add an implementation in the test runner for automation too.

I also think to fully implement the prompt for WebDriver in the test runner, GVE and the other apps, we might also need to add some logic to the JavaScript side. I'm not sure if this one is a special case or not. For example, adding an auth prompt response. Here are the list of prompt names. I'm guessing this one might be under the asyncPromptAuth name. We will also need to add some functionality/data to it and what it can return. This patch might be a useful outline of all the pieces too, if we need to go in that direction.

Thanks Olivia, that's really helpful!

Yes this issue happens on automation, when running wdspec tests (failing job on treeherder).

I will use your suggestions to try to fix this in Bug 1870263.

https://hg.mozilla.org/mozilla-central/rev/47c47a8b2b33
https://hg.mozilla.org/mozilla-central/rev/8b75870e1359
https://hg.mozilla.org/mozilla-central/rev/1a413f0496a4