User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:86.0) Gecko/20100101 Firefox/86.0

Steps to reproduce:

1. Go to a site with basic authentication (.htaccess password protection)
2. Log in
3. "Inspect" any element (open dev tools)

Actual results:

I am prompted for username and password.

Expected results:

Do not prompt. Credentials already given to access site. Obviously in storage.

The Bugbug bot thinks this bug should belong to the 'Toolkit::Password Manager' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

I don't know why but I can reproduce this issue in my environment ONLY when "lastpass" addon is enabled. Also the two authentication dialogs look different.

Hi Tobias,
Do you also install "lastpass", if yes, could you help check if this can be reproduced after disabling it?
If no, could you help check if you can reproduce this issue in the safe mode?
Also, it would be great if you can attach the result of about:support, thanks

Hi Dimi Lee :)

I reproduced the error in a secondary profile (Two profiles open at the same time, #1 had downloads running...). This is about:support from profile 2 in private and safe mode. Same error occurs.

Additional note:
I only tried this with one server. It currently even promts twice - once for http: and then a second time after instantly redirecting to https:, but that's an issue I understand. However, even after those two prompts, a third one opens again for "Inspect element".

Sincerely,
Tobias

I can only reproduce this bug with lastpass is installed, I can't reproduce this issue with a fresh profile in my environment. So this is somehow different from what Tobias has encountered.

In my test, after opening the inspector, devtools code sent a request to the same URL as the first one, which triggered the second auth prompt. I didn't dig into why that was happening, so I'm not sure if that is expected.
In necko, after receiving the request, it didn't add Authorization header even if we've filled in the credential in the first prompt. So the authentication dialog prompted again after receiving response from the server.

(In reply to Tobias H from comment #4)

I reproduced the error in a secondary profile (Two profiles open at the same time, #1 had downloads running...). This is about:support from profile 2 in private and safe mode. Same error occurs.

Hi Tobias, Thank you for the information.
I think i'll handover to devtool team first because they might know why opening inspector triggers another request. If that is expected, maybe necko team can help find out why the second request doesn't have the Authorization header.

Looks like a duplicate of Bug 1675581

Hi Tobias, is it possible to share a website where we can reproduce the issue?

I'm guessing that htaccess also protects stylesheets on your website, and that the inspector tries to fetch the stylesheet in order to parse its CSS text.
But this means we can't reproduce with a basic htaccess example.

Thanks!

Looks like a duplicate of Bug 1675581
It does.

is it possible to share a website where we can reproduce the issue?
I cannot share the website I experience this on; it's a corporate test page that needs to stay private.

Maybe matt from Bug 1675581 will provide an example. If I can share something else I will love to help.

In order to fix this, we need to move the sourcemap resolution to the DevTools server and create the requests using the correct principal. This is a sizeable change in the way we handle source maps, but it would make the sourcemap feature work more predictably.

One of the issues here is that we initially had the worker feature on the server, but we moved it to the client when addressing performance issues. It is not clear now if the performance issues were related to the fact that the feature was on the server, and when discussing with :ochameau, there's nothing which by design should lead to performance issues if we decide to move this back to the server. But hopefully we are not overlooking anything here.

Will put this back to triage to decide if we want to bump this as P2 or to organize it in scope of a bigger project around source maps.