28663 - choose app window does not close on exit

Status: RESOLVED WORKSFORME

(Core :: XUL, defect, P5)

Description

[Tanyel Brown]

When there is an unknown file type and the "pick app" window opens, if I close 
the browser window, the "pick app" window remains open and there is no way to 
close it.  It was the build downloaded on 2-20-2000.

Comment 1

[Dawn Endico]

assigning to the browser product

Comment 2

[Dawn Endico]

this time for sure

Comment 3

[Peter Trudelle]

I'm unable to reproduce this using today's Netscape build running on Win98.  
Resolving as wfm, if you're still seeing it, please provide the exact steps and 
information needed to reproduce.

Comment 4

[Tanyel Brown]

Okay.  First, I loaded the browser on my Windows 98 computer with 32 megabytes 
of RAM, using the 2-21-2000 build.  Then I typed the address of a directory on 
one of my local drives.  Mozilla produced a list of files in that directory.  
Then I clicked on a Microsoft Word file in the file list.  The "Unknown File 
Type" box came up.  Then I clicked on the X to close the browser window without 
closing the "Unknown File Type" box.  After the browser window closed, I 
clicked on "Cancel" in the "Unknown File Type" box.  Then it locked up.  This 
happens every time I do it.

Comment 5

[Peter Trudelle]

No doubt related to low memory. reassigning to danm as p3 for m16

Comment 6

[Peter Trudelle]

Mass-moving all M16 non-feature bugs to M17, which we still consider to be 
part of beta2

Comment 7

[Paul MacQuiddy]

spam, open xptoolkit qa contact moving over to jrgm

Comment 8

[Peter Trudelle]

moving to m18

Comment 9

[Peter Trudelle]

mass-moving all bugs to m21 that are not dofood+, or nsbeta2+

Comment 10

[Dan M]

Not a low memory problem, but a problem with modality. This is a facet of the 
"modal windows don't have proper parents" bug 25684. These are seldom easy to 
fix, but generally important.

Comment 11

[Peter Trudelle]

nsbeta3+

Comment 12

[Peter Trudelle]

Is anyone else seeing the lockup that Tanyel describes?  Anything really bad
happening, or is this just a leftover window?

Comment 13

[Dan M]

  So does this bug describe the "pick app" dialog, or the "unknown content type" 
dialog? It seems to begin with one, then move on to the other. I'm going to 
assume it describes the unknown content dialog, which is the only one I'm able to 
make appear with recent builds. (The pick app dialog is supposed to work for 
certain mime types right now, but it doesn't seem to be.)
  Alright yes, there are problems with the unknown content type dialog. It isn't 
modal or dependent -- making it either would solve the specific complaint in this 
bug report (that the dialog remains open after the browser window has been 
closed.) But the dialog remaining open isn't the real problem, it seems to me. In 
my testing, there always seems to be a crash coming at some point after you've 
closed the browser window.
  So, it would be trivial to make this dialog modal or dependent, but then it 
just crashes somewhere else. Something's quite broken here. However, this entire 
dialog is being removed, to be replaced with the pick app dialog (see nsbeta3+ 
bug 47203, which describes ftp downloads specifically, though it's actually 
applicable to all protocols). The new pick app dialog works completely 
differently -- it's supposed to be modal, for one thing. And the background file 
download will be handled differently.
  There are probably other bugs lurking behind that door. But since the dialog 
described in this bug is slated for removal, this bug at least is slated to 
magically disappear. I'm making this bug dependent on that one, reducing its 
priority, and intending to ignore it unless something bad happens.

Comment 14

[leger]

PDT downloading this bug to [nsbeta2-]. 

Comment 15

[Peter Trudelle]

resolving as wfm now that bug 47203 has landed