1.) Visit the above secure in-house site, then click on Secure Popup in the lower left of the page. What happens: I get a warning that I am entering a secure site. What is expected: That there should be no warning, as with Nav. 4.7X.

I would like to extend the requested behaviour and describe some require consequences. The requested case is: https page -> click on https link that opens a new window -> no warning shown The idea behind this request is: If a user is currently surfing a secure site, when clicking on a link, no warning should be shown unless the security mode changes. That of course means, that we also revert the behaviour when you surf from a https page to a http page in a new window. Currently, we don't show a warning, because unsecure is the default for a new window. A fix for this bug would as a consequence introduce a warning, when surfing from https to http in a new window. To summarize: An opening window, triggered by clicking a link, should inherit the security state of the initial window. It should warn if their is a security change. It should not warn if the new window uses the same security state. In addition, the security state is also defining the shown lock icon. An opening window should initially show the same lock icon state as the originating window. Any objections? However, before we work on that bug, we should make an additional decision. A link can not only open a new window. It can also load a new page in an already open second window. But what should happen in that case? When clicking a link in window A, that opens the new page in an already open window B, this will cause window B to come to front. From the perspective of the user, this is not much different from the "open new window" case. He clicks a link and sees a link to load in a new window. It is just that the web designed has chosen to not open a new window, but to reuse an already previously opened window. To make this more understandable, let's introduce the terms "surfing continuity across windows" and "window continuity". Right now, without having worked on this bug, we have "window consistency". Every window will warn whenever the security state changes within that window. We do not have "surfing continuity across windows" currently. When you click a link that opens the page in a different window, the state of the other window defines what warning will be shown. The easy part of this bug is to implement "surfing continuity across windows" when a new window gets opened. We can inherit the previous state as the initial state for the new window. The difficult decision is, what should happen when clicking a link that opens something in an existing different window. For that kind of link, we can not have both "window consistency" and "surfing continuity across windows" at the same time. Example: - window A shows https - window B shows http - user clicks a link in window A, that opens https in window B If we want surfing consistency, we would not show a warning, because the user nagivates from https to https. But on the other hand, the state of window B would change, and we would not warn the user about that. The user might be surprised that the mode of window B changes without a warning shown. If we think window consistency is more consistent thatn surfing consistency, we would show a warning, because the mode of window B changes. I wonder if there is a way around this warning dilemma. Would it help to rephrase the warnings? Right now our warnings say "you are leaving a secure site" or "you are entering a secure site". I wonder if it would solve the problem, if the warning message would explicitly make a statement about the window, like: "The contents shown in this window are being loaded from a secure site" and "The contents shown in this window are no longer using security".

A couple of comments. 1. I agree with kaie about the need to assume the secure status on a new window if that new window is loaded or opened from annother secure page. The lock icon behavior should also be consistent with this assumption. (This change will elminate a momentary unlocked status of the icon on a newly opened or loaded page from another secure page. The lock will be locked from the beginning. This is desirable from users point of view.) 2. About the warning when a secure link is loaded onto another window which has been using non-SSL connection up to that point. Here, I like kaie's new suggestion to change the current dialogs to refer specifically to a window having a secure content or losing it. I think we have been too vague by using the phrase,"you're now entering a secure site.", etc. The current dialog makes it sound as if the whole browser is entering or leaving a secure site. The use of the word "window" makes it clear that such remarks always apply to a window context not to the entire browser context.

CC'ing Sean for ideas on improved wordings.

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

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

In my opinion the warnings/lack of warnings should reflect "window continuity", as at present (i.e. not "surfing continuity" in the case that a link from window A targets already-open window B), but in the case of a NEW window the initial security state should be inherited from the targeting window. On this basis, navigating in an open window from a secure page to (say) about:mozilla should trigger a warning. However, if there really is a transition from about:blank when a new window is opened, then any warning (if the targeted page is secure) should be suppressed. Cf. bug 270890 comment #1 and bug 270890 comment #4. Window means window or tab throughout. With that caveat, the Summary says it exactly.

To clarify further: When a new window is opened, we have a choice of initial security state. The current behaviour is to choose insecure (the same as about:blank) always. In my opinion, the resolution of the present bug should be that new windows inherit their initial security state from the targeting window. If there is no targeting window, we should maintain the present choice. Non-new windows would be entirely unaffected by such a resolution. What about windows launched from the Bookmarks sidebar, or menu? Would these all act like insecure targeting windows (i.e. the same as no targeting window)? What about linking from one secure site to a DIFFERENT one, or from a secure IMAP message to a secure site? What is the current behaviour?

(In reply to comment #6) > In my opinion the warnings/lack of warnings should reflect "window > continuity", as at present (i.e. not "surfing continuity" in the > case that a link from window A targets already-open window B), but > in the case of a NEW window the initial security state should be > inherited from the targeting window. We seem agreed on what should happen with a new window, but I'm not sure about the situation with links targeting an existing window. For example, suppose a link within a site opens a new window, and either at that point or later on, one enters a secure area of the site. Later on, a page still in the secure area might send you back to the original window and at the same time back to the insecure area. But because the original window wasn't in a secure state, no message is popped up that you're leaving the secure area. Hence if you're not careful, you might inadvertently think you're still in the secure area when you're not. (In reply to comment #7) > What about linking from one secure site to a DIFFERENT one, or from > a secure IMAP message to a secure site? What is the current > behaviour? In 2005070211, if from here I enter an https URL unrelated to this one in the address bar, no security warning appears. No idea if it's the same when following a link.

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

Oh dear, yet another bug that should be filed for all platforms but wasn't.

changing obsolete psm* target to --- (unspecified)

All of these insecure -> secure, etc. prompts were removed.