improperly parented modal dialog in nsNntpService

VERIFIED FIXED

Status

MailNews Core
Networking: NNTP
P3
normal
VERIFIED FIXED
18 years ago
9 years ago

People

(Reporter: Dan M, Assigned: Scott MacGregor)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta2+])

(Reporter)

Description

18 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 nsNntpService::CancelMessages().
  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.
(Reporter)

Updated

18 years ago
Blocks: 25684
(Assignee)

Comment 1

18 years ago
re-assigning to me....these bugs are getting nsbeta2 plussed to nominating as such. 
Assignee: sspitzer → mscott
Keywords: nsbeta2

Comment 2

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

Comment 3

18 years ago
Fixed!
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 4

18 years ago
Per scott on verification: code inspection is the only way. I'd suggest getting 
an engineer who is helping you verify bugs to look at them. 
Keywords: verifyme

Comment 5

18 years ago
Could you suggest a way to cause this wanna-be modal-dialog to appear? With that
info, it should be possible to verify that the dialog is properly attached
(parented) by trying to raise the parent and obscure the child (you shouldn't be
able to do this).
Thanks,

Jim
(Assignee)

Comment 6

18 years ago
Sure! For news, try deleting a message (via the menu item) that isn't a news 
article you wrote. That forces you to get a dialog saying you can't delete this 
article I believe. That modal dialog is parented with the mail 3-pane window 
underneath it. 

Comment 7

18 years ago
Verified on Win NT, using build 2000080204 (M17 beta2 branch).
(Reporter)

Comment 8

18 years ago
verified code diff + Jim's testimony above.
Status: RESOLVED → VERIFIED
Keywords: verifyme

Comment 9

18 years ago
Thank you everyone for helping on this bug verification.
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.