Email from blizzard: "Hey, I don't suppose that you would want to rework the "mismatched name" dialog as well, would you? --Chris" mpt, spec on!
Priority: -- → P2
Target Milestone: --- → Future
Version: unspecified → 2.1
Status: NEW → ASSIGNED
Component: Client Library → Browser-General
Product: PSM → Browser
Target Milestone: Future → mozilla0.9.4
Version: 2.1 → other
Please don't future my bugs. Thanks.
Copy and paste from bug 92410 (consistency is gooood), with changed explanation: +-----------------------------------------------------+ |:::::::::::::::::::::::::::::::::::::::::::::::::::::| +-----------------------------------------------------+ | . There is a problem with the security | | /!\ certificate for "server1.ideasuite.com". | [cropped, w. line break] | """ Are you sure you want to continue? | | | | The certificate belongs to the wrong server | | ("www.ideasuite.com"). | | | | ( View _Certificate ) | | | | [ ] _Accept this certificate permanently | | | | [?] ( Cancel ) (( Continue )) | +-----------------------------------------------------+
Summary: Mismatched name dialog is horked → Mismatched name alert is horked
Whiteboard: testcase needed
I object to the component being wrongly assigned. The PSM team is the module owner. We track our module according to our own guidelines. The dialog lives in the PSM code, therefore the component should be set accordingly. Because of check in restrictions in the security module, we have to do the check in. Therefore we mush be able to track the amount of work we will be able to do and manage what gets in what release.
back to PSM
Component: Browser-General → Client Library
Product: Browser → PSM
Target Milestone: mozilla0.9.4 → 2.1
Version: other → 2.0
Stephane, this bug is not assigned to one of your staff so you don't have the right to change milestones out from underneath the owner. This is a bug owned by a non-Netscape contributor. It doesn't matter that you have to check it in - the owner of the bug sets the schedule for when he/she thinks it is going to be done.
A question on the UI spec: "[ ] _Accept this certificate permanently" seems like the wrong thing in this case since (unlike bug 92410) this alert is not about the certificate itself being unacceptable. It is rather about whether the certificate should be accepted for this site. What exactly would that checkbox do, and should it even exist?
To answer my own question, perhaps what is meant is "Always accept this certificate for this site". If that's the case, maybe the dialog in bug 92410 should use the wording "Always accept this certificate"? Does that seem reasonable? And do we have the backend to implement it?
I don't think we have backend to support this. I mentioned it, and the inconsistent wording to mpt the other day and he suggested I should make all checkboxes use the same wording. I can't implement the checkbox in this dialog unless the backend is there though.
Re: blizzard's comments above: Understood. I was wrong to change the target. Please leave the product and component assigned to PSM. Bug owner: guidance about which PSM target corresponds to a specific mozilla target can be obtained from us. Thanks.
Move to future. Won't have time to fix these for 2.1
Target Milestone: 2.1 → Future
Stephane, please DO NOT change the Target Milestone on bugs that are not assigned to you. _You_ may not have time to fix this for 2.1 bug Haakan has indicated that he does. It is impolite and against Bugzilla good practices to change the TM of other people's bugs. This is the second time you've made such a change to some one else's bug and this is final request/warning that you stop doing this.
my apologies, I was using the change multiple bug feature, a little carelessly in this case. Changing it back.
Target Milestone: Future → 2.1
Assignee: hwaara → ssaux
Status: ASSIGNED → NEW
QA Contact: ckritzer → bsharma
Mass reassign ssaux bugs to nobody
Assignee: ssaux → nobody
Mass change "Future" target milestone to "--" on bugs that now are assigned to nobody. Those targets reflected the prioritization of past PSM management. Many of these should be marked invalid or wontfix, I think.
Target Milestone: Future → ---
Adding the requested testcase.
Whiteboard: testcase needed → [kerh-ehz]
FYI, I mean to include this bug in the fixing of bug 99411.
tested w/ FF3 on wXP. w/ browser.xul.error_pages.enabled = false, I get: Alert [x] /!\ bla.kuix.de uses an invalid security certificate. The certificate is only valid for kuix.de (Error code: ssl_error_bad_cert_domain) [ OK ] It's just a dialog, and the error is fatal. If you use xul error pages you get something else: Secure Connection Failed bla.kuix.de uses an invalid security certificate. The certificate is only valid for kuix.de (Error code: ssl_error_bad_cert_domain) * This could be a problem with the server's configuration, or it could be someone trying to impersonate the server. * If you have connected to this server successfully in the past, the error may be temporary, and you can try again later. Or you can add an exception… You should not add an exception if you are using an internet connection that you do not trust completely or if you are not used to seeing a warning for this server. Sanity check: 1. this bug is assigned to nobody. I am not stepping on nobody's toes.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.