improperly parented modal dialog in nsMsgProtocol

VERIFIED FIXED

Status

P3
normal
VERIFIED FIXED
19 years ago
10 years ago

People

(Reporter: danm.moz, Assigned: mscott)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta2+])

(Reporter)

Description

19 years ago
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.
  One such place is nsMsgProtocol::OnStopRequest. This may be fairly easy to fix, 
but I'm not quite sure how to proceed. nsMsgProtocol itself is an 
nsIInterfaceRequestor, and so could theoretically be handed an nsIPrompt by the 
caller of SetNotificationCallbacks. (The nsIPrompt is currently not extracted or 
saved, which makes me suspicious that the nsIInterfaceRequestor given won't have 
one.) OnStopRequest also is given an nsIChannel in the parameter list; nsIChannel 
carries another nsIInterfaceRequestor. One or both of these 
nsIInterfaceRequestors wants to be given a chance to cough up an nsIPrompt before 
using the nsINetSupportDialog service.
(Reporter)

Updated

19 years ago
Blocks: 25684
(Assignee)

Comment 1

19 years ago
I believe the rest of these type of bugs are all getting nsbeta2+. Marking this
as such as well (see 44164 for an example nsbeta2+).
Keywords: nsbeta2

Comment 2

19 years ago
Putting on [nsbeta2+] radar for beta2 fix. 
Whiteboard: [nsbeta2+]
(Assignee)

Comment 3

19 years ago
Fixed!
(Assignee)

Comment 4

19 years ago
this time with feeling....fixed!
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED

Comment 5

18 years ago
How I do verify this, Scott?  
(Assignee)

Comment 6

18 years ago
code inspection is the only way. I'd suggest getting an engineer who is helping
you verify bugs to look at them. 

Updated

18 years ago
Keywords: verifyme

Comment 7

18 years ago
Mscott,
Shouldn't there be a specific modal dialog that we could test/verify? When this
bug is not "fixed," we should be able to bring the would be "parent" window on
top of the "modal" dialog, making it impossible to terminate the modal dialog :-(.
Isn't that what this class of bug is about?
If this is correct, how can we induce that dialog?
Thanks,
Jim (I wanted to verify... but had the same question as Lisa) Roskind
(Reporter)

Comment 8

18 years ago
verified code diff
Status: RESOLVED → VERIFIED
Keywords: verifyme
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.