Closed
Bug 44161
Opened 24 years ago
Closed 24 years ago
improperly parented modal dialogs in nsSmtpProtocol.cpp
Categories
(MailNews Core :: Composition, defect, P3)
MailNews Core
Composition
Tracking
(Not tracked)
VERIFIED
FIXED
M18
People
(Reporter: danm.moz, Assigned: mscott)
References
Details
(Keywords: embed, Whiteboard: [nsbeta3+] fix in hand)
nsNetSupportDialog should only be used as a backup plan if no other nsIPrompt interface is available. It has been used in dozens of places because of its seductive convenience. But it's flawed, creating modal windows that don't behave correctly; the cause of various blanket bugs like 25684 and 39439 (both currently considered nsbeta2+). This problem can only be fixed by trying much harder to find a proper window to be the modal dialog's parent. nsNetSupportDialog should be relegated to providing backup when herculean efforts to locate the actual parent window fail for some reason. As an example, the cookie service has been taught to use a proper parent window for its dialog by laboriously storing a reference to that window's nsIPrompt in nsHTTPChannel, from which it can be extracted and passed around while processing notification events, punting to nsNetSupportDialog only when no other choice is available. That same sort of thing needs to be done in many more places. Two such places happen in nsSmtpProtocol.cpp: nsExplainErrorDetails and nsSmtpProtocol::OnLogonRedirectionError. Happy recipients of this bug would spread the happiness most widely if they would start using a good nsIPrompt window. The "modal windows don't behave nicely" bugs are being made dependent on this bug and its siblings, and will eventually be closed as "as fixed as they're going to get" once these have all been considered.
Assignee | ||
Comment 2•24 years ago
|
||
I believe these bugs are supposed to be nsbeta2. See 44164 for an example.
Status: NEW → ASSIGNED
Assignee | ||
Comment 3•24 years ago
|
||
triaging.
Keywords: correctness,
nsbeta3
Target Milestone: --- → M18
Comment 5•24 years ago
|
||
Because of the use of nsCommonDialogs, or the use of the nsIPrompt service, this component can not be used for embedding. Adding the embedding keyword. How To Bring Up A Modal Dialog: You need to know what window you want to have modality against. This will be a nsIDOMWindow. Using a magic "hidden" window breaks modality and embedding application may not have this hack. One you have the parent DOMWindow, you simply: nsCOMPtr<nsIPrompt> prompter; aDOMWinow->GetPrompt(getter_AddRefs(prompter)); if (prompter) prompter-> Any other way that you try to bring up a dialog may not work in an embedding application. To reiterate, do not use the nsICommonDialogs interface -or- a nsIPrompt service if you want your component in a non-seamonkey app. I don't have a DOMWindow?! If you don't have a DOMWindow, you need to get one. Just about every place I saw that used the hidden window, could have used the real parent window with some work. There really is no place in the code where we should be displaying a modal dialog without knowing what parent window we are modal against. If you find a case where you don't have a top level window, lets talk.
Keywords: embed
Assignee | ||
Updated•24 years ago
|
Whiteboard: [nsbeta3+] → [nsbeta3+] fix in hand
Assignee | ||
Comment 6•24 years ago
|
||
Fix checked in for the window parenting problems in the smtp protocol.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Comment 7•24 years ago
|
||
verifying this bug
Updated•24 years ago
|
Status: RESOLVED → VERIFIED
Comment 8•24 years ago
|
||
nsIPrompt is being used now
Updated•20 years ago
|
Product: MailNews → Core
Updated•16 years ago
|
Product: Core → MailNews Core
You need to log in
before you can comment on or make changes to this bug.
Description
•