Closed Bug 1659119 Opened 4 years ago Closed 4 years ago

user identification request dialog not tied to own tab, gets lost

Categories

(Core :: Security: PSM, defect)

Product:
Core
Component:
Security: PSM
Version:
79 Branch
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1401466

People

(Reporter: david.balazic, Unassigned)

Details

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

Steps to reproduce:

  • open a an URL that requires a client certificate
  • while it loads (slow website) switch to other Firefox window

Actual results:

First tab never finishes loading.

What happened was that the "user identification request" appeared under the second Firefox windows, so the user did not see it.

Whats more, this not only blocks the original tab/page but all network traffic in all Firefox windows/tabs.

Expected results:

The first tab should have shown clearly that is is waiting for the client certificate selection.

The UIR dialog should be visible and possibly close to the tab is is "tied" to. I have multiple monitors and the dialog appeared on different monitor than the tab that triggered it. I would probably miss it even if it weren't covered by another window.

And third: the UIR dialog should not block all Firefox windows and tabs. If so, there should be a message on them, like "this tab is not responding until you close the URI dialog"

Hey David,

Can you please send us a link (or more) where you encounter this issue? In the meantime can you please test with Safe mode? You can find helpful info here : https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode .

Also a fresh new profile could help. You can find more about creating a new profile here : https://support.mozilla.org/en-US/kb/troubleshoot-and-diagnose-firefox-problems#w_6-create-a-new-firefox-profile .

If possible, you can test this issue on the nightly build as well. Download the build from : https://www.mozilla.org/en-US/firefox/nightly/all/ .

Flags: needinfo?(david.balazic)

With nightly 81.0a1 (2020-08-21) (64-bit):

Result:
no links load, they just spin, as long as the UIR dialog is not closed

Flags: needinfo?(david.balazic)

Could not reproduce this issue on the latest versions of Firefox Nightly 82.0a1 (2020-09-11), beta 81.0b9 or release 80.0.1.
Setting a component for this issue in order to get the dev team involved.
If you feel it's an incorrect one please feel free to change it to a more appropriate one.

Component: Untriaged → Networking
Product: Firefox → Core

IIRC, the socket thread is blocked for waiting the result from certificate selection dialog , so the network traffic is also blocked.
This bug should be a dup of bug 696976.

Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Component: Networking → Security: PSM
Resolution: --- → DUPLICATE

This bug is not about "UIR dialog blocks all network traffic", sorry for the confusion.

It is about "a tab triggers the UIR dialog, which is then displayed somewhere else, out of sight and the the tab seems frozen/not loading"

This is what I just reproduced with 80.0.1 (64-bit):

Result:
The UIR dialog is somewhere behind window C. What the user sees is just window C , titled "New Tab", URL bar has https://server.cryptomix.com/secure/ and the tab (fav)icon it the animated dot moving left right, the page content is empty (white , or whatever was shown there before, like the new tab default page).

Using alt-tab one can see there are now 4 independent Firefox windows : A, B, C and the UIR dialog

In another try of the above steps, the UIR dialog appeared as a model dialog tied to the window B. In this case the result is as above: the https://server.cryptomix.com/secure/ tab in window C is showing the animated dot and "nothing happens". Until the user tries to switch around windows and notices there is a model (but to the wrong window) dialog waiting for input.

At the least the tab waiting for the dialog input should change the content to a message like "this tab is waiting for the UIR dialog, which is ... somewhere on your desktop ... unless Windows put it off screen..."

(In reply to Kershaw Chang [:kershaw] from comment #4)

IIRC, the socket thread is blocked for waiting the result from certificate selection dialog , so the network traffic is also blocked.
This bug should be a dup of bug 696976.

*** This bug has been marked as a duplicate of bug 696976 ***

Bug 696976 is now fixed, but this issue remains.

Sorry, as I understand that fix will ship in version 104, while I use 103 now.

You need to log in before you can comment on or make changes to this bug.