1773321 - HTTP Basic Authentication not working when starting (when there's a saved password and you use a primary password)

Status: RESOLVED DUPLICATE of bug 1761886

(Toolkit :: Password Manager, defect)

Description

[Christophe Meessen]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:101.0) Gecko/20100101 Firefox/101.0

Steps to reproduce:

I have some open pages that uses basic authentication, some pinned and restart firefox so that all the pages are automatically reopened at startup.

I also have a password protecting access to the stored passwords.

Actual results:

When I start firefox, it ask for my password, and then opens all pages except the one requiring the basic authentication. I see the ping pong point forever and the page is not show or the dialog asking for the password.

If I click on the cross to stop trying to open the page and click on the reload button, nothing happens. It should show me the dialog asking me for the login credentials.

The only way to access the page is to request access to a totally new window. Once I logged in using the new window, and I click the cross on the per-opened window, it will load the page.

Expected results:

In version prior to 100, when firefox started and there were web pages requiring basic authentication per-opened, firefox would show the dialog requesting the passwords. I could then login and display the page directly.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Christophe Meessen]

Here is more feedback on the bug as I gained further experience with it.

When firefox is running and I open a web page using basic authentication, a dialog is shown asking for the user name and password. It id prefilled with stored user name and password. This works well.

When firefox is started and there a pre-opened pages, if one of them uses basic authentication, firefox fails to show the dialog to give login credentials. It spins forever. If I stop the page loading (clicking the cross) and ask to reload the page, the dialog is still not shown and firefox spins forever on this page. Other pages open without problem.

It doesn't make a difference if the pre-opened page is pinned or not.

While opening the pages is blocked, I can open a new tab to access the site and then the dialog will be shown. Once the credentials are given, I can connect to the site. But the pro-opened pages are still spinning.

If I then stop them and reload them, then it will open. I guess it is because an authentication cookie is found. I didn't check. It's beyond my competence.

Comment 3

[R. Martinho Fernandes [:rmf]]

DOM: Web Authentication is for the WebAuthn spec; this is HTTP basic auth, which I believe belongs to Firefox: Security? Let me know if I'm wrong.

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:serg, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 5

[Christophe Meessen]

Update report with version 102.0.1 (snap Ubuntu 22.04).

For conciseness, lets call A the site with basic authentication (https).

Now when I start Firefox and have a pinned and normal tab on site A initially opened. I see the bouncing point (left right) as small icon in both tabs.
When I click on the normal tab to display it, the prefilled dialog for authentication is displayed. If I click to authenticate, the small icon changes to the site A small icon and I'm in the site. But the pinned tab keeps its bouncing point. Clicking on this tab displays a blank page. Clicking on the X cross to stop the loading and click to reload the page loads the page with success. In this case, the problem is that the pinned page is not automatically loaded once I authenticated through the normal tab.

When I start Firefox with a pinned tab to site A and a normal tab to site A and I click on the pinned tab to display the page, I don't see the dialog. Clicking the X cross and reloading the page has no effect.

In Firefox versions prior to 100, when I started Firefox with tabs to sites requiring basic authentication, Firefox would automatically display the page with the dialog for authentication. This was a little bit of a nuisance and it's good this has been removed. It is a nice feature that authentication is postponed to when the page is displayed by the user. It is because I keep many tabs open for convenience and restart my computer every morning.

Comment 6

[Daniel Veditz [:dveditz]]

I get different results depending on conditions. On the site I tried I had to clear the cache before shutting down to get anything like what you described: otherwise session restore would simply show me the cached content and not ask for authentication. Of course some people clear their cache automatically when they shut down, and some sites will tell the browser not to cache their pages.

If my active tab when I quit was the non-pinned version of the site requiring auth then I'd get the auth dialog on that tab. If I was on some other site's tab then after putting in my primary password I get yanked to the pinned tab where there's an auth login. If I was on a page requiring auth when I shut down then I just get the auth dialog on that page and don't get yanked anywhere. The "other" page usually stays blank as you say, and needs to be stopped and reloaded after auth has been submitted. I suspect the subsequent connections are waiting for the first to complete the auth request and then don't get resumed. But the saved-and-locked passwords certainly have something to do with it, because I don't have the same problem if I don't have a saved password for the site, and I don't have the problem if I don't use a primary password.

This might turn out to be a front end problem after all, but we might have better luck starting with the networking folks.

Comment 7

[Christophe Meessen]

With version 103.0.2 (64 bits), the behavior changed a bit.

A normal tab (not pinned) is now working as expected. When the tab is clicked, the prefilled dialog requesting user name and password is shown. When validated, the page is loaded.

The pinned tab is still not working. It still need a normal tab to be shown the login dialog requesting the credentials. Once validated through the normal tab and logged in, I need to click the cross of the pinned tab to make it stop trying to load the page. When I then reload the page, the page is shown since I'm already logged in with the normal tab.

Comment 8

[Ed Guloien [:edgul]]

I am getting similar behaviour to :dveditz with 103.0.2.
Only occurs when using primary password and two tabs where 1 tab is pinned and my previously active tab is the non-pinned tab:
Upon restart, prompt for primary password appears (for non-pinned tab). After password population and login of non-pinned tab, accessing the pinned tab does not trigger either the page auth dialog.

Multi non-pinned tabs works fine.
Pinned and non-pinned when previously active window is pinned tab or non-auth site works fine.
Individual tabs, pinned or not work fine.

Will look a bit deeper into networking specific stuff soon...

Comment 9

[Valentin Gosu [:valentin] (he/him)]

I think there is some mismatch between the networking stack attempting to show the basic auth prompt, and the UI not being there (or ready).
It'll be a bit difficult to write an automated test for this since it requires restarting the browser. We might be able to do it with a marionette test such as this

Comment 10

[Christophe Meessen]

Since I've installed 104.0.2, I have seen a regression.

Before, displaying a pre-open tab on a site using basic authentication would display the prefilled login dialog. I could then login. Then, when reloading the pinned tab, I could login as well.

Now the login dialog isn't shown anymore on pre-open tabs. It doesn't make a difference if the tab is pinned or not.

I have to open a fresh new tab to the site to see the prefilled login dialog. When logged in, the pre-open tabs, pinned or not, do load the page as expected.

The current state is even more annoying as before.

Comment 11

[Valentin Gosu [:valentin] (he/him)]

I think someone with knowledge of the password manager should take a look at this - the fact that the primary password UI is blocking this means it might not be necko.

Comment 12

[Christophe Meessen]

On my side (Ubuntu snap) the problem has been fixed today with release 105.0. If this is confirmed by other users, the bug report may be closed.

Thank you very much to everybody who helped solving this issue.

Comment 13

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:serg, could you have a look please?

For more information, please visit auto_nag documentation.