Closed Bug 363345 Opened 18 years ago Closed 17 years ago

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

Categories

(Firefox :: Session Restore, enhancement)

enhancement
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: grin, Unassigned)

References

Details

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.
Please install Firefox and test, otherwise file a bug with debian.
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...)
(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.
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.
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 :-)
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.
(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?
Component: Startup and Profile System → General
QA Contact: startup → general
Summary: [SessionRestore] Popups, changed popup defaults, tabs and problems when restoring large amounts of tabs → Restoring many tabs with security errors can get annoying (have to click through many dialogs)
OS: Linux → All
Hardware: PC → All
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.
Btw, expect this UI to change a lot when bug 327181 is fixed.
Depends on: https-error-pages
Status: UNCONFIRMED → NEW
Component: General → Session Restore
Ever confirmed: true
QA Contact: general → session.restore
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).
Marking as "fixed by bug 327181". Please reopen if you disagree.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.