1698991 - Presented with two VPN proxy logins instead of one

Status: RESOLVED FIXED

(Toolkit :: Password Manager, defect, P2)

Description

[Arthur K. (he/him)]

Attachment: dual-login-prompt-windows.png

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

Steps to reproduce:

I just upgraded to 78.0 RC1 build 2 from 86.0.1 stable today and when I launch FF I am now presented with two login prompts.

Actual results:

I am now presented with two login prompts to log into my VPN provider. One is the classic login window and what now appears to be an updated login window that appear up at the top. I had seen this updated login prompt appear a few times (since FF 85.x) but never simultaneously.

Expected results:

One prompt window to log into the VPN provider but not both or whatever this new prompt window is.

Comment 1

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

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.

Comment 2

[Arthur K. (he/him)]

Error console throwing this error:

Prompter: internal dialogs not available in this context. Falling back to window prompt. Prompter.jsm:1033

set modalType resource://gre/modules/Prompter.jsm:1033
ModalPrompter resource://gre/modules/Prompter.jsm:989
pickPrompter resource://gre/modules/Prompter.jsm:44
asyncPromptAuth resource://gre/modules/Prompter.jsm:718
promptAuthInternal resource://gre/modules/LoginManagerAuthPrompter.jsm:723
_doAsyncPrompt resource://gre/modules/LoginManagerAuthPrompter.jsm:203
InterpretGeneratorResume self-hosted:1480
AsyncFunctionNext self-hosted:690

Comment 3

[Arthur K. (he/him)]

With a secondary error (guessing this is related to the second prompt windows up top):

NetworkError when attempting to fetch resource. Prompter.jsm:1215

openWindowPrompt resource://gre/modules/Prompter.jsm:1215
openPrompt resource://gre/modules/Prompter.jsm:1071
openPromptAsync resource://gre/modules/Prompter.jsm:1247
nsIPrompt_promptUsernameAndPassword resource://gre/modules/Prompter.jsm:1512
promptAuth resource://gre/modules/Prompter.jsm:1663
asyncPromptAuth resource://gre/modules/Prompter.jsm:719
promptAuthInternal resource://gre/modules/LoginManagerAuthPrompter.jsm:723
_doAsyncPrompt resource://gre/modules/LoginManagerAuthPrompter.jsm:203
InterpretGeneratorResume self-hosted:1480
AsyncFunctionNext self-hosted:690)

Comment 4

[Arthur K. (he/him)]

So while entering credentials into one of the two login boxes will work, it eventually prompts you to log into the other box as well and doesn't prompt afterword. Gonna be a lot of users cursing at the monitor from this issue I bet. I don't have FF setup to save my VPN password in so it doesn't prompt me so I have not tested that scenario yet. I always enter credentials manually.

Comment 5

[Dimi Lee [ooo 16.04 - 21.04］]

Hi paul,
Do you think this is related to Bug 613785? Looks like one is tab prompt and the other is content prompt?

Comment 6

[Paul Zühlcke [:pbz]]

I assume it's a regression of Bug 1684469. We have a queuing mechanism for auth prompts so that we don't show multiple prompts for the same site and realm. However, in this case there is a mix of window and tab level prompts, which are in two separate queues.
Ideally we wouldn't show window prompts at all. It seems that there is a callsite which doesn't pass a browsingContext parent window so we show the window prompt as a fallback. To fix this we should ensure we always pass a valid parent, if possible.

Comment 7

[Paul Zühlcke [:pbz]]

Actually, let's leave this on affected for 88 until we've assessed the severity.

Comment 8

[Sam Foster [:sfoster] (he/him)]

Its pretty unclear what the user should do here. The "workaround" is to click buttons until the right thing happens, so I'm calling this S2.

Comment 9

[Paul Zühlcke [:pbz]]

On browser startup there seems to be a proxy auth prompt which doesn't have a parent (no browser or window). The call goes via a legacy interface in nsIWindowWatcher: https://searchfox.org/mozilla-central/rev/6309f663e7396e957138704f7ae7254c92f52f43/toolkit/components/windowwatcher/nsWindowWatcher.cpp#1428
It looks it comes from here: https://searchfox.org/mozilla-central/rev/6309f663e7396e957138704f7ae7254c92f52f43/dom/ipc/BrowserParent.cpp#3258-3259
mFrameElement could be null. Maybe somebody from the DOM team could help to find out why we don't get a parent there. It might also be a call for a chrome network request. In that case we can't possibly get a browser to show something on tab level.

If we can't always get a browser, we could do special handling for the following two cases:

1. A window auth prompt is open and a tab prompt arrives.
   Check if the window prompt has the same hashKey as the newly opened tab prompt. If the hash key matches, merge the request with the window prompt.

2. Tab prompts are open and a window prompt arrives
   Check if a tab-level prompt in the currently selected tab has a matching hashKey. If the hash key matches, merge with the tab-level prompt.
   If the new request does not have a parent window associated, use the most recent one.

Side-note: Getting both, a tab prompt and a window prompt, to show up isn't such a common case for me. Most of the time I get a window auth prompt with an intact parent relationship. This causes the main browser window, the parent, to enter modal state and prevents any tab prompts from appearing. The issue only occurs when I get a standalone window auth prompt. I assume we never get a parent for the initial auth prompt, but Prompter.jsm can sometimes fallback to the active window: https://searchfox.org/mozilla-central/rev/6309f663e7396e957138704f7ae7254c92f52f43/toolkit/components/prompts/src/Prompter.jsm#1218

Comment 10

[Paul Zühlcke [:pbz]]

For a quick fix we could change proxy auth prompts to always use window prompts. This would regress a little bit on UX, but proxy auth is more of an edge case than basic auth triggered by websites. Also I'd assume most proxies do not require authentication for every site visit.

Comment 11

[Paul Zühlcke [:pbz]]

Attachment: Bug 1698991 - Merge tab level proxy auth prompts with window prompts with matching auth-realm. r=dimi!

Comment 12

[Paul Zühlcke [:pbz]]

After some further discussion it looks like we have two options here to avoid duplicate prompts:

a) Switch auth prompts back to be window prompts only (like we had it before Bug 613785)
b) Change the merging logic so we don't spawn tab prompts if we have a window prompt open (for a matching auth realm). That's the WIP patch attached.

I prefer option (b) since we will still show tab prompts whenever it's suitable. I've observed two kinds of proxy auth prompts. When a new browser window is created and the user hasn't authenticated to the proxy yet, we show a window prompt (there is probably no tab associated at this point). The other case is showing a tab prompt, which is triggered by a page load. In that case we have the browser / tab relationship and we don't have to fall back to window prompts.

A problem with window prompts is that we will block any page loads until the window prompt is handled by the user. For multi-window use cases or for cases where we show a standalone prompt window, because we couldn't find a parent window, this can be confusing. Tabs can appear to be not loading and users might not associate that with a prompt, which could be in a different or even minimized window.

If we wanted to avoid window prompts completely, but can't get a target tab from the caller, we could also consider trying to find a suitable tab. That could be the selected tab in the most recent window.

Comment 13

[Paul Zühlcke [:pbz]]

:sfoster, thanks for the quick chat on Matrix last week. You mentioned that you wanted to discuss this with the team so we can decide on a strategy here. Leaving a NI for that.

Comment 14

[Sam Foster [:sfoster] (he/him)]

(In reply to Paul Zühlcke [:pbz] from comment #12)

After some further discussion it looks like we have two options here to avoid duplicate prompts:

a) Switch auth prompts back to be window prompts only (like we had it before Bug 613785)
b) Change the merging logic so we don't spawn tab prompts if we have a window prompt open (for a matching auth realm). That's the WIP patch attached.

I prefer option (b) since we will still show tab prompts whenever it's suitable.

Agreed. :dimi and I discussed and b) looks like the better approach. Most of the time, a proxy auth request would be expected to block browsing in that window. If we use tab modal, we could end up in a situation where we have tab-modal prompts for this same request in multiple tabs, then have to go back through and dismiss them all when the user does finally authenticate.

Comment 15

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/eb595dec6591
Merge tab level proxy auth prompts with window prompts with matching auth-realm. r=dimi

Comment 16

[Ryan VanderMeulen [:RyanVM]]

This missed the 88.0rc1 build. I'm thinking it'd probably benefit from some bake time, so probably better to just let it ride the 89 train at this point. Feel free to scream if you feel strongly otherwise.

Comment 17

[Andreea Pavel [:apavel]]

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

Comment 19

[Arthur K. (he/him)]

Installed 89.0 RC1 on my home machine and this seems fixed there. Only one VPN login prompt appeared.