Closed Bug 45687 Opened 24 years ago Closed 24 years ago

Browser hangs when I add a new mime type

Categories

(SeaMonkey :: Preferences, defect, P1)

x86
Windows NT

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: shrir, Assigned: bugs)

Details

(Whiteboard: [nsbeta3+][nsbeta2-])

Build: 2000071708

When I try to add a new mime type to the prefs|Helper Application menu using the 
"Add" button, after filling in the details, pressing the OK button hangs the 
browser and I cannot seem to get rid of the "Preferences" window at all. I have 
to restart the browser to work again. The new mime type does get saved however.
qa:self, nomnating beta2.
Keywords: nsbeta2
QA Contact: sairuh → shrir
Putting on [nsbeta2-] radar.  Not critical to beta2.  Adding "relnote" keyword 
for PR2 release. 
Keywords: relnote
Whiteboard: [nsbeta2-]
Changing to relnote2 -- please fix this on any other bugs you've marked for the 
PR2 release notes!
Keywords: relnoterelnote2
nominating for nsbeta3
Status: NEW → ASSIGNED
Keywords: nsbeta3
nav triage team: mscott, sounds like a backend problem to us.
Assignee: ben → mscott
Status: ASSIGNED → NEW
Whiteboard: [nsbeta2-] → [nsbeta3+]
there is no back end implementation for this dialog. It's all written in XUL.
Re-assigning back to Ben. 
Assignee: mscott → ben
Putting [nsbeta2-] back in.
Whiteboard: [nsbeta3+] → [nsbeta3+][nsbeta2-]
hang on add seems to have gone away but I cleaned upa  couple of js errors, and 
an assert when removing a type, as well as the problem whereby the 
fileExtensions resources werent being nuked. 
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Build:2000081008m18 windows
This has come back in M18. I see the browser hanging after I fill in the details 
for a new mime type for the first time and press OK. Prefs dialog cannot be 
dismissed at all and the browser window is inaccessible. Reopening.....

FYI; Added acrobat, pdf ,application/pdf and the path to acroreader in the 
dialog.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Priority: P3 → P1
shirang, is the state you end up in where the pref window is defocused but still 
modal? (such that you can click on neither it nor the app window)?

If so that is a separate bug that has been occurring elsewhere. danm might know 
more about it (I'll ask him). 

I noticed it when adding a mime type once, but that was once out of five or six 
times so it seems to be intermittent (Windows 2000)

There was a hang in editing a mime type due to an image not being present. I 
have just now checked in a fix for that. 

The problem you describe sounds like 22658, currently owned by danm ('closing 
some dialogs activates the wrong window').

Status: REOPENED → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → FIXED
>shirang, is the state you end up in where the pref window is defocused but 
>still modal?

Yes..I ended up like that. But this is working(adding new mime type) most of the 
time. Will log a seperate bug when I see it again. VERIFIED(2000082504m18)
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.