Closed Bug 44171 Opened 25 years ago Closed 25 years ago

improperly parented modal dialog in bookmarks

Categories

(SeaMonkey :: Bookmarks & History, defect, P3)

defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: danm.moz, Assigned: danm.moz)

References

Details

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 nsBookmarksService::OnStopRequest. 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. Taking this bug myself since it's fairly clear where the right nsIPrompt should come from.
OS: Mac System 8.5 → All
Hardware: Macintosh → All
Blocks: 25684
I've changed the dialog in question (it's the one that alerts you changes in the content of a bookmarked page) to use the window encoded in the channel before defaulting to the broken global service. This would solve the problem of bug 25684 if the channel had been given a window when it was set up. It wasn't. This portion of Very Large Bug 25684 has been fixed. But a user wouldn't notice. I probably need to write up another dozen bugs complaining that channels often don't carry windows.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
dan talking to dan, marking VERIFIED (rubber stamp). thanks for the details though, those are important.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.