Closed
Bug 44166
Opened 25 years ago
Closed 25 years ago
improperly parented modal dialog in nsNNTPProtocol.cpp
Categories
(MailNews Core :: Networking: NNTP, defect, P3)
MailNews Core
Networking: NNTP
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: danm.moz, Assigned: mscott)
References
Details
(Keywords: verifyme, Whiteboard: [nsbeta2+])
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 are nsNNTPProtocol::DoCancel and nsNNTPProtocol::AlertError.
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 1•25 years ago
|
||
re-assignigng to me...these bugs are being nsbeta2 plussed.
Assignee: sspitzer → mscott
Keywords: nsbeta2
mscott - on all of these types of bugs, how do we verify (if possible) in
release builds? If not, I can ask Suresh to verify on a debug build.
Assignee | ||
Comment 4•25 years ago
|
||
Fixed!
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
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
(I was asked to do the verification ...) all uses of the
nsNetSupportDialogService have been replaced, which solves the problem. Before I
call it verfied, though, I'd like warmer fuzzies about the use of m_RunningURL in
nsNNTPProtocol::DoCancel. It's checked before use as if it could be null, but if
it is null, "dialog" is never set and could lead to a null dereference. Other
than that, 'salright.
What dialog is generated by this code? I can find a case to have this dialog
appear. I can then check the modality of this dialog.
I'd like to mark this VERIFIED, but I'll need to know how to verify modal
code..thanks!
QA Contact: lchiang → stephend
Comment 10•24 years ago
|
||
verifying.
but I did notice some code that might need to be fixed in nsNewFolder.cpp, but
that is a seperate bug.
Status: RESOLVED → VERIFIED
Summary: improperly parented modal dialog in nsNNTPProtocol → improperly parented modal dialog in nsNNTPProtocol.cpp
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
•