sorry: the given URL is in german and you need to have an account to see the error. Mozilla version: Windows NT4 SP6, Nightly 20020212 Steps to reproduce: 1. Login to freemail.web.de 2. click on any link in the navigation frame Scenario description: - the whole site is secure (ssl) - the links in the nav-frame have the form <a href="/online/....?si=..." target="content">MyText</a> Actual result: 1. you get the ssl warning about "leaving a page that uses encryption" 2. you get the ssl warning about "loading a page that uses encryption" 3. the new content frame is loaded Expected result: only step 3: the new content frame is loaded

concretion: steps to reproduce: 2. you have to click on any link in the nav-frame which doesn't leave the freemail-area of this portal: i.e. any link with blue background-color

This is a Security bug.

Amar, please assign SSL bugs to the PSM product.

cc kaie

Steps to reproduce: 1. you certainly have to login at https://freemail.web.de/ (http://freemail.web.de/ exists, too)

I noticed the same behviour on this page (Linux, Build 2002030621). Even more strange: When having two sessions open, one encrypted, one unencrypted, you flip from the encrypted one to the unencrypted one and do an activity there the warning pops up also....although this page was never ever encrypted.... Cheers Axel

I can reproduce what you see. The links on this site also trigger a JavaScript action. That might be the cause of this bug. <td class="nav" bgcolor="#CCD4E6" OnClick="javascript:parent.content.location.href='/online/logic/action.htm?si=nd5Q.16LLPk.1swli7.N***&rv_do_newsms=yes';">&nbsp;<a href="/online/logic/action.htm?si=nd5Q.16LLPk.1swli7.N***&rv_do_newsms=yes" target="content">SMS</a></td> We should find somebody who understand JS or DOM better than me, we need to understand what that kind of events that OnClick action will trigger.

according to SELFHTML (http://selfhtml.teamone.de/javascript/objekte/frames.htm) this JavaScript just sets the location of the frame content. But I don't see why this is used, because the link just does the same. Why should anybody load a new URL in a frame with a link AND JavaScript?? Kai is right, the JavaScript is the problem! If you turn of JavaScript for the Navigator in the preferences completely, you don't get the warnings anymore!! Is this a bug of PSM or of Javasript in Mozilla (or both/the combination)??

changed summary. additionally I found that the same problem exists, if a onClick-action is used with a submit-input in a from. Example: - goto https://freemail.web.de/ - login - read an eMail - click the button "Löschen" (german: delete) expected result: - eMail is deleted and next eMail displayed WITHOUT ssl-warnings actual result: - you get an ssl-warnung for leaving and one for requesting a secure-page The submit-button is generated with the following html-code: <input TYPE="SUBMIT" NAME="rv_do_delmsg" VALUE="L&ouml;schen" onclick="document.msgform.rv_js.value='yes';document.msgform.submit()" >

cc brendan for comments on javascript. asigning it to Kai.

I saw that the JS links and the HREF links are different. The urls used in the JS code are missing the trailing slash /. When JS is turned on, the page without / is requested, and this causes a http 302 redirect to the URL with trailing slash. By tracing the security OnStateChange events, I know the reason why we see multiple alerts in the JS case When the first request is finished, all that happened was receiving the 302 answer, causing the redirect. I bet this transaction must have happened over https, because that's what the used URL indicates. However, when the requests finishes, and the security code tries to obtain the security info from the channel, no security info is available, and the code assumes this was an insecure request. We need to analyze this more, but I don't think it's caused by JS.

Sorry Kai: I don't see any differences in the link-URLs: this is the Linke for "Neu -> E-Mail" (added link-breaks for better comparison of the URLs) <td class="nav" height="17" bgcolor="#CCD4E6" OnClick="javascript:parent.content.location.href=' /online/logic/action.htm?si=o9NS.16NBxu.3QlsnG.3X**&rv_do_newmail=yes ';">&nbsp;<a href=" /online/logic/action.htm?si=o9NS.16NBxu.3QlsnG.3X**&rv_do_newmail=yes " target="content">E-Mail</a></td> looks perfectly identical for me. Besides, where should the missing trailing slash / be placed? As far as I know there is no trailing slash after a parameter-list

> Sorry Kai: I don't see any differences in the link-URLs: Obviously the various links are different. I can confirm what you see for the "E-Mail" link. But when you look at the source for the "Ordner" link, you see what I reported in my previous comment: <td class="nav" bgcolor="#CCD4E6" OnClick="javascript:parent.content.location.href=' /online/ordner?si=ocdi.16NEdi.64K3t.f**** ';">&nbsp;<a href=" /online/ordner/?si=ocdi.16NEdi.64K3t.f**** " target="content">Ordner</a></td> The difference is a "/" before the "?". In that case, when the JS links gets loaded, one gets redirected to the URL with "/". My previous comment still stands. I looked at the "E-Mail" link you mentioned. While here both links are identical, the web server sends a redirect 302, too. I still believe the problem is that our code does not see security information for that redirection request, although it should.

with Mozilla 1.0rc1 this error is gone for me. BUT! Clicking on the "Ordner"-Link the first time (and only the first time) produces a warning pop-up that I have requested a secure document, that contains some insecure data. The security symbol is broken afterwards. There are no insecure elements (at least I can't see them in the Page Info nor the Page Source) and Mozilla up to 0.9.9, Netscape 4.7x and IE 5.5 don't complain about it. AND When you click the "Löschen" (that is delete) while reading a mail, this doen't delete the mail. You are simply switching to the next mail. With Netscape 4.7x and Mozilla 0.9.9 this worked, although Mozilla 0.9.9 produced the two warnings when pressing this button. Here's the HTML-source for the delete button while reading the mail: <form NAME="msgform2" ACTION="https://freemailng0201.web.de/online/logic/action.htm" METHOD="POST"> <input type="hidden" name="rv_post" value="yes" > <input TYPE="HIDDEN" NAME="rv_js" VALUE="" > <input TYPE="HIDDEN" NAME="rv_do_mvmsg" VALUE="" > <input TYPE="HIDDEN" NAME="rv_mid" VALUE="190111612" > (...) <input TYPE="SUBMIT" NAME="rv_do_delmsg" VALUE="L&ouml;schen" onclick="document.msgform.rv_js.value='yes';document.msgform.submit()" > If I'm not very mistaken the JavaScript should set the hidden member rv_js to yes and then submit.

I have broken the problem down to a simple test case. The problem is: That site uses a table cell, that has two different actions defined. One for the "onclick" of the table cell, and one for clicking the linked text. There is a simple test case at: https://www.kuix.de/misc/test21/ The problem is that clicking on the text triggers two page loading events. The freemail web site (as the testcase) link both to the same destination URL. When you click, the first load starts, but gets immediately canceled by loading the second URLs. This sucks (both the website and our behaviour). The real cause for the duplicate warning is: Whenever loading of some secure page content stops, we try to extract the security/crypto information from the channel. However, when that loading gets interrupted too early, there is nothing to extract, and the false assumption is made that no security was used (that means, we try to be more clever, but not only looking at a https prefix, we look at the real content). I see two possible fixes for this bug. First, Mozilla could be clever enough to detect that scenario, and only start loading for one event. One the other hand, because JavaScript is involved, you could do really weird things with delays and stuff, and actually I guess this is not a viable solution. So, I recommend the second approach: I would like to fix this case together with bug 140836. In that other bug, we will ignore it, when a document gets loaded, that did not result in any data to be shown on the screen. I already did some tests, and I have a patch (not yet attached) that allows one to browser that page with JavaScript enabled and without seeing warnings. *** This bug has been marked as a duplicate of 140836 ***

Verified dupe.