I don't have an exact regression range, but it seems that recently (within the past few days? week?) I will see both a modal alert (popup on win32, sheet on OSX) describing certificate errors as well as the netError-like page in the browser. I've attached a screenshot.

I should note that I'll get this once per session, and then not again for any site.

I confirm what Mike is describing, on Mac and Windows. It's hard to reproduce it though - and it does seem pretty recent. Have there been changes lately to how we determine whether we have a docshell or not? I don't think this should block, but it will look sort of buggy to our users.

The discussion in bug 433420 suggests this issue could come from the favicon that gets loaded over the insecure connection. Because the favicon is not being displayed in the browser window (and there is no way to render html in the favicon area...) we fall back to reporting the error as a dialog.

I can't shake the feeling though, that this is a recent regression - I went months after the introduction of error pages without ever seeing this - it feels like it started post beta 5. Did we land changes to the favicon code or the SSL error handling code in that time?

Use the zipped cert db in bug 426867 with ssltunnel, making 8889 be the SSL port and 8888 being the proxied port, while running Mochitests, and I recall being able to consistently reproduce this loading <https://localhost:8889>, if I remember the steps I took correctly.

To all of my knowledge it happens only upon the first SSL error within the same session. It doesn't happen afterward anymore.

Suggestion: Never open a dialog window, but if there really isn't a content area to display the error, open a page or new tab, focus on it and display the error as usual. The window really shouldn't be anymore. Would that be a possible solution?

i've hit this once. and since i'm responsible for the <a> marker, i was wondering about it. if someone can trigger this in a windows build, instead of dismissing the dialog, please attach a debugger and catch me on irc, let's try to find enough information from stack traces and live objects to figure it out.

I'm getting this problem - or one like it - every time I run mozilla on one of our sites. The site is a webmail server; when I check for new emails, 3 out of 5 times I'll get "Secure Connection Failed webmail.etc.etc uses an invalid security certificate." - even tho I've allowed the exception, gotten the certificate, confirmed it, AND told Mozilla to remember the exception. I'm running Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1.

I am getting a propably related problem on Mac OS X 10.5 except that I never get the nice new ssl error page but only the error sheet. Plus I cannot add security exceptions. I am able to download the security certificate from the 'show certificate' dialog but there is _no_ way of adding an exception! I am getting really annoyed about this since I simply cannot work with firefox like that! Does anyone have an idea what this could be? I have searched the web extensively already! Thanks

(In reply to comment #11) > I am getting a propably related problem on Mac OS X 10.5 except that I never > get the nice new ssl error page but only the error sheet. Plus I cannot add > security exceptions. I am able to download the security certificate from the > 'show certificate' dialog but there is _no_ way of adding an exception! If you never get the error page, this sounds like either a different bug, or perhaps that you have XUL error pages turned off. To check: - go to about:config - check the value for browser.xul.error_pages.enabled - it should be true If it is set to true and the behaviour persists, please file a new bug for us to track down the issue.

Unfortunately the error_pages.enabled is set to true. I have filed a new bug as requested: bug 450146! Thank you so far!

Also of interest is bug 453442, which seems to suggest that at least one reason for this behavior is the /favicon.ico loading.

I've attached a patch in bug 453442 which should resolve this one as well, I believe. If that does indeed fix things, I'll resolve this one as well.

This should now be fixed, after the checkin to 453442. Can someone on this bug confirm?

-> VERIFIED with patched Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1b2pre) Gecko/20081021 Minefield/3.1b2pre (corporate page on which this bug was consistently reproduced)