When browsing a secure site that has a javascript open new window call, mozilla will warn you that you are visiting an unsecured site, even when the stuff in the popup window is also encrypted. To test this, make sure that you have the ssl for mozilla installed and working and that you have mozilla set to warn you when you go between secure and unsecure sites. Visit https://mozilla:thing@www.gcctech.com/test/popup.html I'm not sure which category this bug actually belongs in. I'm filing in javascript engine, although my guess is that the warning is being generated before the javascript engin has any say about it at all.

*** Bug 58180 has been marked as a duplicate of this bug. ***

Confirming. Changing component to crypto. Also note that the lock is now unlocked.

This is now in-house test #6 at https://junruh.mcom.com/mix.html

I can't access the in house url given. Is dns or server down right now junruh? I hadn't noticed the lock icon before. I changed the test case on my server a bit so that it enables the status bar in the popup window. This is interesting because you can see that the popup window lock is locked indicating that the popup window is secure, but the parent window gets its lock unlocked. Interesting.

You can't access the in-house url, because it is in-house, behind a firewall. Can you keep your page available for a while so that everyone can reach it?

That would explain it. I have some other mozilla test cases at that location, so it should be up until the bug is fixed.

I didn't see a warning. What preference needs to be set in order to get this bug to show up?

You have to use Netscape 6, and have the prefs turned on in Security Manager, Applications.

If you have all of the preferences turned on and the content of the pop-up comes from an SSL site, then this is the right behavior. One of the preferences is "Warn me whenever going to a site that uses encryption." It's a new window going to an SSL site, so you will get the warning. Is there more of usability issue, then?

The warning that you are entering an secure site is just fine. The problem is when you are on one secure page and you visit another. You get a warning that you are leaving the secure site when you aren't.

OK, guess I should've read the bug report more closely.

I see this also on a NorthWest Airlines page, in some javascript that does not use a popup, but simply submits a form. I point this out just to show that it's not javascript popups specifically that seem to cause this problem, but javascript in general. Visit: https://flynwa.mstrav.com/pub/Agent.dll?qscr=logi&lmde=35&ussl=1 enter gibberish for the "Member ID" and "Password". Hit "Sign in to WorldWeb Reservations". You will get a warning about visiting an insecure page. The javascript for the "Sign in..." link is function SubmitLogin() { var f=document.SignIn; f.wdth.value=screen.width; f.hght.value=screen.height; f.submit(); } and the form itself is <FORM METHOD=POST NAME="SignIn" ACTION="/pub/Agent.dll"> so there's nothing at all insecure here, but I still see the "Visiting an insecure page" warning when I click it, followed by the "Visiting a secure page" warning.

Can we up the severity on this a bit? It must impact the usability of a lot of 'serious' secure web applications.

*** Bug 62088 has been marked as a duplicate of this bug. ***

*** Bug 63095 has been marked as a duplicate of this bug. ***

nsbeta1

*** Bug 60918 has been marked as a duplicate of this bug. ***

I'm seeing slightly different behavior now on 2001032614. When I visit the reporter's page and click on the JavaScript popup, the new window opens up and gives the correct warning (that I'm going to a secure page). But the padlock icon in the original window becomes red and broken, and the padlock in the popup window is unlocked.

Setting milestone.

nsSecureBrowserUI is getting OnStateChange notifications for "javascript:openNewWindow('https://www.gcctech.com/test/popup1.html','popup',400 ,400)" Since the channel associated with the OnStateChange's request doesn't return an nsITransitSecurityInfo, nsSecureBrowserUI treats this as insecure content. There are three possibilities: 1) The docloader shouldn't be giving us these OnStateChange notifications, since it isn't actually loading any content into the document. 2) javascript: content is always as secure as the containing document, so nsSecureBrowserUI should ignore OnStateChange notifications for javascript: url's. 3) The javascript channel needs to implement returning an appropriate nsITransitSecurityInfo.

Confirmed with today's builds. The behavior is still not right. -> P1 (unless someone can demonstrate that this is an edge condition)

Can reproduce with linux n6 build ID 2001061808

whiteboard PDT for PSM.

PDT+ as per Steve Elmeer 6/20/2001

What's your current status on this bug?

This works for me with the latest builds. My guess is that this was fixed when I check in some changes for 82156 last week. I'm marking this bug fixed.

Verified.

whiteboard -> checked in ; verified