363345 - Restoring many tabs with security errors can get annoying (have to click through many dialogs)

Status: RESOLVED FIXED

(Firefox :: Session Restore, enhancement)

Description

[peter gervai]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1) Gecko/20061024 Iceweasel/2.0 (Debian-2.0+dfsg-1)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1) Gecko/20061024 Iceweasel/2.0 (Debian-2.0+dfsg-1)

FF 2.0 seems to have changed default behaviour for "Security error: Domain name mismatch" popup, which defaults now to "cancel" (opposite of what it used to be). This have an implication of making my startup time 5 times more, because in the previous version I kept pressing enter zillion times, and eventually it started; now I have to read the popup, click on ok, again and again.

The problem is that I get a popup for http_auth passwords (which is fine), expired ssl certs and ssl domain name mismatches. Since I have 100+ tabs open, starting FF causes some 50+ popups to open, informing me about things I am already well aware of, since I already acknowledged them when I first opened the page, before the session was in fact saved.

First I would have liked to suggest to make it possible to optionally revert to the old default, but I guess some security-oversensitive fellows around may have stomped upon me and feed my remains to wild aardvarks. (No, it is not possible to convince half of the rest of the world to fix their webservers, buy IPs, renew their expired certs. I am no God. I have to work with these, that's fact, not a choice.)

So I have a better suggestion: please implement a switch in the session restore feature which - if selected - would pop up only ONE popup, which would kindly inform the monkey before firefox that if I click on OK then I will get no further warnings about SSL problems (certs, mismatches, god knows what) while the session is being restored [since I already have seen these warnings anyway, and agreed to enter the site since if I would have not the site would not have been saved in the session]. I would press OK for the BigFatWarning, and the session would be restored without popups, except maybe password popups (which may, or may not be missed if there is only one stored password for the given site, and the master password was already given).

It would be so nice to have this feature... but of course it must not be the default, and the user should get the warnings due after utilising this. It would be user friendly. ;-)


Reproducible: Always

Steps to Reproduce:
1. Open sites with expired certs, domain mismatches in 50 tabs, acknowledge every problems with OK
2. Enable session restore
3. Quit firefox
4. Start firefox

Actual Results:  
Lots of popups [same as in step 1], some defaults to cancel [opposite of what was already chosen].

Expected Results:  
No popups, maybe one telling me no further popups.

There is no session restore category in the bugzilla.

Comment 1

[Majken Connor [:Kensie]]

Please install Firefox and test, otherwise file a bug with debian.

Comment 2

[peter gervai]

Sure. They asked to file bugs here, you ask to file bugs there. No problem. :-) 

(I wonder whether you actually _checked_ how _your_ firefox behaves, because I would have guessed this behaviour was not changed in Debian packaging, and I would have guessed that you have answered without actually verifying whether the problem - or let's call it behaviour - exists in FF head, instead of ricocheting th problem because you [or the "official project" somehow dislike Debian, for reasons probably known by both of us, even if by my humble opinion it's just ego play]. If it does not exist in _your_ FF and was _messed_up_ by Debian, I wholeheartedly apologise now. OTOH if it does.... hmm...)

Comment 3

[peter gervai]

Debian bug #406302  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=406302
Thanks.

Comment 4

[Mike Hommey [:glandium]]

(In reply to comment #1)
> Please install Firefox and test, otherwise file a bug with debian.

I know mozillians have grief against Debian and/or GNU with iceweasel, but it would really be better if you actually read the bug report.

FWIW, AFAIK, this is not something we changed.

Comment 5

[Mike Hommey [:glandium]]

And indeed, after testing 1.5.0.9 and 2.0.0.1, I can confirm that the default used to be OK and is now Cancel.

Comment 6

[Mike Hommey [:glandium]]

...which is due to http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&file=domainMismatch.xul&branch=&root=/cvsroot&subdir=mozilla/security/manager/pki/resources/content&command=DIFF_FRAMESET&rev1=1.21&rev2=1.22

which is a fix for bug #213207

Comment 7

[peter gervai]

Walking the referenced bug indeed revealed interesting things.

Bug #213207 was resolved fixed while the commments explicitely mention bug #209299 which should have been fixed _together_ with this one. 

Funny that bug #209299 was closed as duplicate to bug #205677, which was in turn closed as worksforme (partly because it was not a duplicate, and partly because it worked for someone but not others).

So basically my bug is closely related to 209299 which was unfairly closed without  processing and in my opinion should be reopened.

Or to copy here as well: the default should not have changed without a means to skip them all. That's what I just said above. *sigh*

PS: PLEASE do not mark this a duplicate of a closed but unfixed bug. Thanks :-)

Comment 8

[Majken Connor [:Kensie]]

It has nothing to do with animosity. There are many bugs filed all the time and we ask *all* users to reproduce the issue in a clean install of our unmodified product before viewing the bug as valid. As you saw in your own bug tracking, not everyone can see the same issues. Being a windows user myself I could have followed your steps to reproduce and gotten a different result than you would have. Asking you to verify it yourself gives a higher chance that the bug will be seen as valid and not worksforme.

Mike - thanks for the confirmation, that's all that was necessary. I'll cc some appropriate people.

Comment 9

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #0)
> So I have a better suggestion: please implement a switch in the session
> restore feature which - if selected - would pop up only ONE popup, which would
> kindly inform the monkey before firefox that if I click on OK then I will get
> no further warnings about SSL problems (certs, mismatches, god knows what)
> while the session is being restored [since I already have seen these warnings
> anyway, and agreed to enter the site since if I would have not the site would
> not have been saved in the session]. I would press OK for the BigFatWarning,
> and the session would be restored without popups, except maybe password popups 
> (which may, or may not be missed if there is only one stored password for the
> given site, and the master password was already given).

There's no way to ensure that the warnings you get when restart are restore the session are the same warnings you got when you first visited the pages, and giving the users the choice to blindly say "ignore all security warnings for the rest of this session" is dangerous. I understand that having to click through 50 dialogs to restore the session is problematic, but it sounds to me like your scenario is fairly abnormal (why are you connecting to so many sites with misconfigured certs?).

Perhaps we should have a "accept this specific domain mismatch for this session" option. Would that solve your problem?

Comment 10

[Jesse Ruderman]

Maybe SessionStore should remember your "ignore for session" choices in security dialogs?  That way, if the warnings are the same as the ones you got (and chose to ignore) during the saved session, they won't appear upon restoring the tabs.

Comment 11

[Jesse Ruderman]

Btw, expect this UI to change a lot when bug 327181 is fixed.

Comment 12

[Kai Engert (:KaiE:)]

This bug should be addressed with the landing of bug 327181 this early morning.

When you open a link in a web page, and the site uses a bad cert, you should now get an error page.

You might want to have a look at tomorrow's nightly build, and if you agree, please mark this bug fixed.

(I think the landing of bug 327181 was too late in the morning, so today's nightly builds might not yet have this change).

Comment 13

[Kai Engert (:KaiE:)]

Marking as "fixed by bug 327181".

Please reopen if you disagree.