44320 - Cannot reach a new secure site on first try

Status: VERIFIED FIXED

(Core Graveyard :: Security: UI, defect, P3)

Description

[John Unruh]

1.) Visit a secure site you have never been to before with the present profile.
2.) Click past the two "New Web Site Cert" dialog boxes.
What happen: Mozilla stalls. Restarting Mozilla and then visiting the same site 
is successful.

Comment 1

[John Unruh]

This worksforme with Win32, build 71020, but still happens with the Linux build 
#71020. Nominating for msbeta2.

Comment 2

[Jay Patel [:jay]]

Putting on [nsbeta2+] radar for beta2 fix. 

Comment 3

[Javier Delgadillo]

I just tried this with last night's daily build of Mozilla and the PSM build 
from 2 nights ago.  Are you still seeing this behavior?  If so, update your 
builds and try again.

Comment 4

[John Unruh]

Still happening with the Linux Seamonkey 71308 build.

Comment 5

[Javier Delgadillo]

Could you at least try on a different machine.  To make sure it's not the 
machine that's causing the problem.  Also what version/build of PSM are you 
using.

Comment 6

[John Unruh]

Marking worksforme. This seems to be a timing issue, since it works when I am 
logged into a linux machine directly. In any case, a workaround is to just click 
on the link again. Also, this would only happen when going to a site with an 
untrusted CA for the first time - a fairly rare occurence.

Comment 7

[John Unruh]

Verified.

Comment 8

[John Unruh]

Reopening. This is still happening on Linux. After clicking through 2 "new web 
site cert" dialog boxes and ending up at the same page, the trick is to click on 
the link a second time, but this should not be necessary.

Comment 9

[leger]

Putting on [nsbeta2-] radar.

Comment 10

[Javier Delgadillo]

John, 

Is this still happening?  I tried this today on NT and worked.  (I remember you 
saying that it happened on all platforms, so I'm wondering if it still happens 
on Linux as well.)

Comment 11

[John Unruh]

This still happens with linux, although the circumstances are quite rare. I have 
to go to an untrusted https site, such as a new cert server and click through 
two CA acceptance dialog boxes. With 4.7x, the windows appear faster, but if I 
take my time clicking through them, I can get a "A network error occurred while 
Netscape was receiving data. Try connecting again." It could be that this bug is 
really that there is no warning when a connection cannot be made, and is a 
duplicate of bug 33772 - No warning when connection is not possible. 

Comment 12

[Javier Delgadillo]

With a Linux box, goto https://javi.red.iplanet.com:8080/

(You will also get an unexpected name dialog since the cert on the server is for 
javi.mcom.com)

Comment 13

[John Unruh]

I can reach it on the first try, but I have to be fast on clicking through the 
dialog boxes. The oldmonk site seems slow enough so that I can't reach it on the 
first try - https://oldmonk.red.iplanet.com:3003/DirUserEnroll.html. Any 
thoughts on making this bug a dupe of bug 33772 ?

Comment 14

[Javier Delgadillo]

This is not a dupe of bug 33772.  This is a dupe of the bug where SSL 
connections time-out if you let the SSL dialogs sit around for too long.

(I thought there was such a bug, but I can't find the number.)

Comment 15

[John Unruh]

Adding nelsonb's comments, and changing url, and changing OS to all.
"Today, when user dialogs are required during an SSL handshake, either because
something's wrong with the server cert/chain or because the user has to 
select a cert for client auth, the SSL handshake is stalled while the user
dialogs are presented.  When the user dialogs are finished, the handshake 
resumes from the spot where it stalled, but often by that time, either the
server or the browser has timed-out on the connection, resulting in failure.

Microsoft's Internet Explorer (MSIE) handles such situations differently.  
When it has to present user dialogs, it silently terminates the SSL handshake
and the TCP connection to the server.  When the user dialog finishes, it 
establishes a new TCP connection and starts a new SSL handshake from scratch.  
Consequently, MSIE users never (er, very seldom) experience these timeout
failures.  I believe this is a superior way to handle these dialogs.

I propose that Mozilla and PSM change to use this abort-and-try-again 
technique, rather than the existing stall-and-continue technique.  I'd guess
this is not a small change, because I suspect it involves some communication
between Mozilla and PSM about terminating and restarting the connection over
which the request is to be sent.  But I believe it would be worth the effort
in terms of improved user perception."

Comment 16

[John Unruh]

Since this is nsbeta3+, setting priority to P2

Comment 17

[Peter Trudelle]

PDT thinks this is P3, due to perceived difficulty to reproduce, and expected 
rarity. Could reconsider if data shows otherwise. P3

Comment 18

[Javier Delgadillo]

New target milestone.

Comment 19

[David P. Drinan]

PSM 2.0 is now part of the mozilla and commercial builds and has fixed alot of 
UI and ssl bugs that were in PSM 1.X. I'm doing a mass setting of bugs to 
be FIXED. If you believe that I've closed a bug in error, please re-open it. 
Thanks.

Comment 20

[John Unruh]

Verified.

Comment 21

[John Unruh]

Mass changing Security:Crypto to PSM

Comment 22

[John Unruh]

Mass changing Security:Crypto to PSM