Closed Bug 1826196 Opened 1 year ago Closed 4 months ago

Implement "network.continueWithAuth" command


(Remote Protocol :: WebDriver BiDi, task, P2)



(firefox122 fixed)

122 Branch
Tracking Status
firefox122 --- fixed


(Reporter: whimboo, Assigned: jdescottes)


(Blocks 4 open bugs, )


(Whiteboard: [webdriver:m9], [wptsync upstream])


(3 files)

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

Priority: P1 → P2
Blocks: 1830875
Whiteboard: [webdriver:m7] → [webdriver:m8]
Blocks: 1845345
No longer blocks: 1826198
Depends on: 1826198
Whiteboard: [webdriver:m8] → [webdriver:m9]

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.

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?

Flags: needinfo?(james)

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.

Flags: needinfo?(james)
Assignee: nobody → jdescottes
Depends on: 1870032
Attachment #9367897 - Attachment description: Bug 1826196 - [bidi] Add wdspec tests for network.continueWithAuth → Bug 1826196 - [wdspec] Add wdspec tests for network.continueWithAuth

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:

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 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?

Flags: needinfo?(ohall)
Blocks: 1870263

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.

Flags: needinfo?(ohall)

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.

Pushed by
[remote] Add no such request error r=webdriver-reviewers,whimboo
[bidi] Add network.continueWithAuth command r=webdriver-reviewers,whimboo
[wdspec] Add wdspec tests for network.continueWithAuth r=webdriver-reviewers,whimboo
Failed to create upstream wpt PR due to merge conflicts. This requires fixup from a wpt sync admin.
Flags: needinfo?(james)
Flags: needinfo?(aborovova)
Whiteboard: [webdriver:m9] → [webdriver:m9], [wptsync upstream error]
Created web-platform-tests PR for changes under testing/web-platform/tests
Whiteboard: [webdriver:m9], [wptsync upstream error] → [webdriver:m9], [wptsync upstream]
Flags: needinfo?(james)
Flags: needinfo?(aborovova)
Closed: 4 months ago
Resolution: --- → FIXED
Target Milestone: --- → 122 Branch
Upstream PR merged by moz-wptsync-bot
Regressions: 1870816
You need to log in before you can comment on or make changes to this bug.